From e85bb9b8c3bd1a7d093c43f4894b9fb0d457ccbe Mon Sep 17 00:00:00 2001 From: Namilsk Date: Thu, 1 Oct 2026 22:26:54 +0300 Subject: [PATCH] chore(docs): started minimal documentation --- doc/HOW_WORKS_ROUTING.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/HOW_WORKS_ROUTING.md diff --git a/doc/HOW_WORKS_ROUTING.md b/doc/HOW_WORKS_ROUTING.md new file mode 100644 index 0000000..2e70e19 --- /dev/null +++ b/doc/HOW_WORKS_ROUTING.md @@ -0,0 +1,12 @@ +# Basic NSC routing principles + +NSC implements its own DNS server, which resolves domains according to the configured routing policies. + +The current sniffing-based routing flow works as follows: + +* The user enters a domain in their browser, for example `http://reg.i2p`. +* The NSC FakeDNS server responds with an address from the [RFC 2544](https://www.rfc-editor.org/info/rfc2544/) benchmarking address space (`198.18.0.0/15`) and stores the corresponding `domain:IP` mapping. +* When the application attempts to connect to the assigned IP address, NSC intercepts the connection and looks up the original domain using the stored mapping. +* NSC then establishes a connection to the appropriate overlay network proxy (mostly SOCKS) and forwards the intercepted traffic through it. Supported interception backends include TPROXY and eBPF. +* Responses from the overlay network are forwarded back to the original application as if it were communicating directly with the resolved address. +