Skip to content

Commit e1ac281

Browse files
committed
More README updates
Signed-off-by: Alexey Cluster <cluster@cluster.wtf>
1 parent 4e31b51 commit e1ac281

1 file changed

Lines changed: 3 additions & 1 deletion

File tree

README.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,7 @@ What started as a quick-and-dirty solution just for personal use has grown into
2323
* **Cross-Platform and Lightweight**
2424
Available as binaries for Linux, Windows, and Mac, as well as tiny multi-arch Docker images (amd64, arm64, arm/v7, arm/v6, 386, ppc64le, s390x). The images are extremely small and suitable even for embedded routers like MikroTik.
2525
* **Cross-compile ready**
26-
Easily portable and compilable on Linux, macOS, and Windows (MSYS2/MinGW, with automatic fallback to poll()).
26+
Easily portable and compilable on Linux, macOS, and Windows (MSYS2/MinGW, with automatic fallback to `poll()`).
2727
* **Very low dependency footprint**
2828
No huge libraries or frameworks.
2929
* **Android Client Coming Soon?**
@@ -304,6 +304,8 @@ This allows the remote obfuscator to recognize which static mapping (and which l
304304
* Peer A’s obfuscator sees a packet coming from `5.6.7.8:8888`.
305305
* It checks its static bindings (`127.0.0.1:5555:7777`) and knows to deliver the packet to the local WireGuard instance on port `5555`.
306306

307+
Packets sent from Peer B to Peer A follow the exact same steps, but in the reverse order.
308+
307309
#### Summary
308310

309311
With static bindings, each obfuscator knows in advance how to forward packets between the server and local WireGuard, regardless of which peer initiates the connection. This enables fully bidirectional, peer-to-peer WireGuard tunnels—*even if both sides can initiate connections at any time.*

0 commit comments

Comments
 (0)