بخش ۴: انتخاب node‌ها

هر node در WaterWall یک کار مشخص انجام می‌دهد و با کنار هم گذاشتن آن‌ها یک chain می‌سازید. پیش از نوشتن config، مشخص کنید با چه نوع ترافیکی کار می‌کنید و کدام سمت مالک socket یا interface است.

جدول‌های زیر راهنمای انتخاب‌اند، نه فهرست کامل. اگر به node تخصصی نیاز دارید، همه‌ی node‌ها را ببینید و پیش از قراردادن آن در chain، صفحه‌ی مرجع همان node را بخوانید.

رایج‌ترین شکل chain چنین است:

entry adapter -> middle transforms -> exit adapter

برای TCP:

TcpListener -> MuxClient -> VlessClient -> TlsClient -> TcpConnector

برای packet‌ها:

UdpStatelessSocket -> WireGuardDevice -> TunDevice

adapter‌های ورودی و خروجی

adapter‌ها WaterWall را به دنیای بیرون متصل می‌کنند.

adapter‌های ورودی رایج:

node	کاربرد
`TcpListener`	پذیرفتن اتصال‌های TCP ورودی.
`UdpListener`	پذیرفتن ترافیک UDP همراه با state جداگانه برای هر peer.
`TcpUdpListener`	listener ترکیبی TCP/UDP.
`TunDevice`	خواندن و نوشتن IP packet‌ها از طریق interface نوع TUN.
`RawSocket`	کار با raw IP packet‌ها.
`UdpStatelessSocket`	bind کردن یک socket نوع UDP بدون state اتصال به‌ازای هر peer.

adapter‌های خروجی رایج:

node	کاربرد
`TcpConnector`	بازکردن اتصال‌های TCP خروجی.
`UdpConnector`	فرستادن ترافیک UDP به یک یا چند مقصد.
`TcpUdpConnector`	connector ترکیبی TCP/UDP.
`UdpStatelessSocket`	فرستادن datagram‌های UDP با استفاده از routing context.

listener‌ها معمولاً ابتدای chain stream و connector‌ها معمولاً انتهای آن قرار می‌گیرند. adapter‌های packet بسته به توپولوژی می‌توانند در هر یک از دو سمت باشند.

node‌های transform

node‌های transform در میانه‌ی chain قرار می‌گیرند و شیوه‌ی حمل داده را تغییر می‌دهند.

transform‌های جفت و node‌های انتقال رایج:

سمت client	سمت server	کاربرد
`MuxClient`	`MuxServer`	multiplex کردن چند line منطقی روی تعداد کمتری اتصال transport.
`EncryptionClient`	`EncryptionServer`	رمزنگاری AEAD روی payload‌های frame شده.
`ObfuscatorClient`	`ObfuscatorServer`	اعمال obfuscation سبک XOR همسان؛ این کار رمزنگاری نیست.
`TlsClient`	`TlsServer`	استفاده از TLS واقعی روی wire.
`HttpClient`	`HttpServer`	حمل payload از طریق HTTP/1.1، HTTP/2 یا جریان‌های مبتنی بر WebSocket.
`VlessClient`	`VlessServer`	framing سمت client و server پروتکل VLESS.
`TrojanClient`	`TrojanServer`	framing سمت client و server به سبک Trojan.
`RealityClient`	`RealityServer`	رفتار سمت client و server به سبک Reality.
`Socks5Client`	`Socks5Server`	اتصال به SOCKS5 یا ارائه‌ی سرویس SOCKS5.
`HeaderClient`	`HeaderServer`	حمل metadata پورت WaterWall یا اطلاعات قابل‌اعتماد IPv4 PROXY protocol.
`Bgp4Client`	`Bgp4Server`	استفاده از framing stream شبیه BGP؛ این node‌ها مسیریابی BGP را پیاده‌سازی نمی‌کنند.
`ReverseClient`	`ReverseServer`	ساخت تونل reverse، وقتی سمت server امکان پذیرفتن اتصال ورودی مستقیم را ندارد.
`ConnectionFisherClient`	`ConnectionFisherServer`	امتحان‌کردن هم‌زمان چند مسیر و نگه‌داشتن اولین مسیری که peer آن را تأیید می‌کند.
`HalfDuplexClient`	`HalfDuplexServer`	جداکردن upload و download در دو جهت مستقل.
`KeepAliveClient`	`KeepAliveServer`	افزودن heartbeat برای تشخیص مسیرهای قطع‌شده.
`TcpOverUdpClient`	`TcpOverUdpServer`	حمل یک stream روی مسیر UDP حفظ‌کننده‌ی مرز packet با KCP.
`UdpOverTcpClient`	`UdpOverTcpServer`	حفظ مرز datagram‌های UDP-style روی یک انتقال stream.

node‌های جفت باید با همتای درست خود در سمت مقابل کار کنند. برای مثال، در هر دو سمت یک تونل رمزنگاری‌شده از EncryptionClient استفاده نکنید.

node‌های کمکی

node‌های کمکی برای اعمال policy، تست و debug به کار می‌روند:

node	کاربرد
`Router`	فرستادن اتصال به مقصدهای متفاوت بر اساس مبدأ، مقصد، پروتکل، domain یا credential‌ها.
`SniffRouter`	مسیریابی بر اساس metadata به‌دست‌آمده از sniff کردن ترافیک.
`Bridge`	اتصال دو بخش جداگانه‌ی chain که در یک فایل config تعریف شده‌اند.
`AuthenticationClient` / `AuthenticationServer`	همگام‌سازی و ارائه‌ی داده‌ی کاربران احرازشده برای node‌های مشارکت‌کننده؛ این مسیر کنترل است، نه forward کردن عادی داده.
`SoftIpLimiter`	محدودکردن source IP‌هایی که می‌توانند از هویت اولیه‌ی یکسان VLESS یا Trojan استفاده کنند.
`SpeedLimit`	محدودکردن throughput.
`BlackHole`	دورریختن ترافیک یا پایان‌دادن عمدی به یک مسیر.
`LoggerTunnel`	ثبت payload یا رویدادهای ترافیک برای debug.
`Disturber`	شبیه‌سازی packet loss، خرابی داده یا تأخیر برای تست.
`JunkDatagramSender`	فرستادن noise تولیدشده پیش از ترافیک واقعی روی یک مسیر حفظ‌کننده‌ی datagram.
`TesterClient` / `TesterServer`	تولید و اعتبارسنجی ترافیک تست.
`SpeedTestClient` / `SpeedTestServer`	اجرای تست‌های متمرکز بر throughput.

با این node‌ها می‌توانید رفتار chain را تغییر دهید، بدون اینکه adapter‌های ورودی و خروجی را عوض کنید.

شاخه‌های router

Router بر اساس rule‌ها یک شاخه را انتخاب می‌کند. این node منتظر نخستین payload در جهت upstream می‌ماند، rule‌ها را به‌ترتیب بررسی می‌کند و اتصال را به مقصد نخستین rule منطبق می‌فرستد. اگر هیچ rule‌ای منطبق نباشد، مقدار next سطح اول به‌عنوان مسیر پیش‌فرض استفاده می‌شود.

نمای مفهومی:

TcpListener -> Router
                 |-- rule: TLS domain match -> premium-path
                 |-- rule: SSH port match    -> ssh-path
                 `-- default next            -> direct-path

نمونه:

{
  "name": "route-by-domain-or-port",
  "type": "Router",
  "settings": {
    "sniffing": [
      "http1",
      "tls"
    ],
    "rules": [
      {
        "destination-domain": [
          "*.example.org"
        ],
        "target": "premium-path"
      },
      {
        "destination-port": 22,
        "target": "ssh-path"
      }
    ]
  },
  "next": "direct-path"
}

هر target نام node دیگری در همان فایل config است. یک rule می‌تواند چند شرط را با هم ترکیب کند؛ شرط‌های داخل یک rule با عملگر منطقی AND سنجیده می‌شوند و مقادیر داخل هر شرط معمولاً گزینه‌های جایگزین یکدیگرند.

وقتی یک listener باید ترافیک را به چند chain شاخه‌ای بفرستد، از Router استفاده کنید.

node‌های packet

node‌های packet به‌جای stream‌های عادی TCP با IP packet‌ها یا datagram‌های شبیه packet کار می‌کنند.

node‌های packet رایج:

node	کاربرد
`TunDevice`	ساخت یا استفاده از interface نوع TUN برای IP packet‌ها.
`RawSocket`	فرستادن و دریافت raw IP packet‌ها.
`WireGuardDevice`	پیاده‌سازی رمزنگاری WireGuard و مدیریت peer درون chain WaterWall.
`IpOverrider`	override کردن آدرس مبدأ یا مقصد packet.
`IpManipulator`	اعمال تغییرات سطح packet برای مسیریابی ویژه یا سناریوهای تست.
`PingClient` / `PingServer`	حمل IPv4 در Echo request‌های جفت‌شده و مصرف Echo reply دقیق به‌عنوان تأیید.
`PacketSender` / `PacketReceiver`	ابزارهای کمکی برای تست و bootstrap ترافیک packet.

chain packet با chain اتصال TCP یکسان نیست. برخی مسیرهای packet از packet line سطح worker استفاده می‌کنند که در طول پردازش تعداد زیادی packet زنده می‌ماند. config packet را با این فرض نسازید که هر packet مانند یک اتصال TCP معمولی line را ایجاد و نابود می‌کند.

bridge‌های packet، stream و اتصال

گاهی لازم است ترافیک را بین مدل‌های packet، stream و اتصال تبدیل کنید. node‌های bridge این کار را انجام می‌دهند.

node	مرز یا نقش
`ConnectionToPackets`	از اتصال دارای destination context به packet‌های خام IPv4 TCP/UDP.
`PacketsToConnection`	از packet‌های خام IPv4 به line‌های اتصال عادی TCP/UDP در WaterWall.
`PacketsToStream`	از سمت packet به سمت stream.
`StreamToPackets`	از سمت stream به سمت packet.
`PacketSplitStream`	node کمکی ویژه‌ی packet line برای شاخه‌های نام‌دار upload و بازگشت.

PacketsToStream و StreamToPackets یک جفت framing هستند. این دو در حال حاضر فقط IPv4 را پشتیبانی می‌کنند، header سفارشی طول اضافه نمی‌کنند، packet‌های خام IPv4 را در stream می‌نویسند و مرز packet‌ها را از فیلد total length در IPv4 بازیابی می‌کنند.

ConnectionToPackets و PacketsToConnection یک flow bridge می‌سازند. این دو با stack داخلی lwIP در همان process، line‌های عادی TCP/UDP WaterWall را به raw packet‌های IPv4 و برعکس تبدیل می‌کنند. ConnectionToPackets به یک source-ipv4 مجازی تنظیم‌شده نیاز دارد، فقط IPv4 را پشتیبانی می‌کند و برای آن آدرس به مسیر بازگشت نیاز دارد. PacketSplitStream تخصصی‌تر است: خودش packet‌ها را frame یا تبدیل نمی‌کند، بلکه یک چیدمان packet line را به شاخه‌های نام‌دار upload و بازگشت تقسیم می‌کند.

شکل پایه‌ی انتقال packet روی stream میان دو server:

server A: TunDevice -> PacketsToStream -> TlsClient -> TcpConnector
server B: TcpListener -> TlsServer -> StreamToPackets -> TunDevice

در نمای کلی بالا استفاده از node‌های TLS اختیاری است، اما در استفاده‌ی واقعی معمولاً اطراف مسیر stream، رمزنگاری، authentication یا camouflage اضافه می‌شود.

WireGuard درون WaterWall

WireGuardDevice رمزنگاری WireGuard و state مربوط به peer را مدیریت می‌کند، اما خودش socket نوع UDP را باز نمی‌کند و interface نوع WireGuard در سیستم‌عامل نمی‌سازد.

توپولوژی معمول چنین است:

UdpStatelessSocket -> WireGuardDevice -> TunDevice

UdpStatelessSocket فقط در ابتدای chain مجاز است. آن را پیش از WireGuardDevice قرار دهید؛ این socket نمی‌تواند پس از WireGuard باشد. solver لایه همچنان مشخص می‌کند کدام سمت مجاور packet‌های L3 و کدام سمت انتقال L4 را حمل می‌کند.

تقسیم وظایف:

node	مسئولیت
`TunDevice`	interface مربوط به IP packet‌های داخلی.
`WireGuardDevice`	handshake، رمزنگاری، state مربوط به peer، مسیریابی allowed IP و keepalive در WireGuard.
`UdpStatelessSocket`	socket بیرونی UDP برای فرستادن و دریافت packet‌های WireGuard.

این تفکیک مهم است: آدرس و پورت bind مربوط به UDP را روی UdpStatelessSocket و key‌ها و peer‌های WireGuard را روی WireGuardDevice تنظیم کنید.

راهنمای عملی انتخاب node

برای یک TCP forward ساده:

TcpListener -> TcpConnector

برای تونل رمزنگاری‌شده‌ی TCP میان دو server:

client side: TcpListener -> EncryptionClient -> TcpConnector
server side: TcpListener -> EncryptionServer -> TcpConnector

برای multiplex کردن تعداد زیادی stream روی یک مسیر انتقال:

client side: TcpListener -> MuxClient -> TcpConnector
server side: TcpListener -> MuxServer -> TcpConnector

برای VLESS روی TLS:

TcpListener -> MuxClient -> VlessClient -> TlsClient -> TcpConnector

برای انتقال ترافیک packet روی یک stream:

packet side A: TunDevice -> PacketsToStream -> TcpConnector
packet side B: TcpListener -> StreamToPackets -> TunDevice

برای یک مسیر IPv4 و بدون نیاز به root، از SOCKS CONNECT به packet:

شاخه‌ی application محلی: TcpListener -> Socks5Server -> ConnectionToPackets -> Bridge A
شاخه‌ی UDP محلی:          UdpStatelessSocket -> WireGuardDevice -> Bridge B
سمت راه‌دور:               UdpStatelessSocket -> WireGuardDevice -> PacketsToConnection -> TcpUdpConnector

Bridge A و Bridge B را به هم pair کنید تا شاخه‌ی connection-to-packet به سمت packet وایرگارد وصل شود. هر UdpStatelessSocket در ابتدای chain خودش می‌ماند.

Socks5Server مقصد درخواستی را برای ConnectionToPackets فراهم می‌کند. source-ipv4 آن را به‌صورت یک آدرس مجازی یکتا تنظیم کنید که peer راه‌دور آن را می‌پذیرد و مسیر بازگشت به آن را دارد. این یک flow bridge در userspace است و جای capture کردن ترافیک دلخواه host را نمی‌گیرد؛ هر زمان به interface packet در سطح سیستم‌عامل نیاز دارید، از TunDevice استفاده کنید.

برای WireGuard:

UdpStatelessSocket -> WireGuardDevice -> TunDevice

پس از انتخاب شکل کلی chain، صفحه‌ی مرجع تک‌تک node‌های به‌کاررفته را بخوانید. object مربوط به settings در هر node متفاوت است و نسخه‌های جدید WaterWall اغلب پیش از آنکه آموزش‌های قدیمی به‌روزرسانی شوند، فیلدهای تازه‌ای اضافه می‌کنند.

adapter‌های ورودی و خروجی​

node‌های transform​

node‌های کمکی​

شاخه‌های router​

node‌های packet​

bridge‌های packet، stream و اتصال​

WireGuard درون WaterWall​

راهنمای عملی انتخاب node​