Zdrojový port klienta versus naslouchající port serveru ve VPN toku
Porovnejte dvě čísla portů v jednom tunelu: pevný naslouchající port serveru a efemérní zdroj klienta a také překlad routeru mezi nimi.
Ve stejné konverzaci se objevují dvě čísla a ani jedno není špatné. Protokol serveru ukazuje naslouchající port, který nabízí službu, notebook ukazuje socket, který odeslal datagram, a router mezi nimi může druhý z nich při cestě ven přepsat. Užitečnější je porovnat konce konverzace než samotné číslice. Následující srovnání drží naslouchající port, klientský socket a přeložený zdroj oddělené, protože odpovídají na různé otázky.
Dvě čísla, která popisují protilehlé konce
Nakonfigurovaný port serveru je cíl, na který klient volá. Určuje ho politika, objevuje se v profilu a musí být na straně serveru otevřený. Zdrojový port klienta se volí lokálně, obvykle z efemérního rozsahu, a existuje proto, aby odpověď měla kam dorazit. Může se změnit při každém opětovném připojení a nic v návrhu nezávisí na tom, že zůstane stabilní.
Router mezi nimi může tento zdroj přepsat do svého vlastního 'NAT' mapování. Proto číslo pozorované na serveru často nemá žádný vztah k tomu, které si notebook vybral.
Kde se číslo zdroje cestou ven mění
Vezměte vymyšlený příklad s IPv4: klient za překládajícím routerem, server s jedním 'UDP' naslouchajícím portem a jediný datagram, který projde oběma. Tabulka pojmenovává každý koncový bod a co se s ním děje, místo aby přehrávala paket ve třech bodech pozorování.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
Cíl je v každém řádku stejný a mění se jen identita zdroje. Požadavky UDP NAT rozlišují vnitřní adresu a port od vnějšího mapování, což je přesně rozdíl mezi druhým a třetím řádkem. Router může zdrojový port klienta zachovat, nebo zvolit jiný; zachování není něco, co by aplikace měla předpokládat.
Přečtěte tři koncové body ze samotných hostitelů
Výpisy níže pocházejí ze tří různých strojů a společně ukazují celou konverzaci. Spusťte první na serveru, druhý na klientovi a třetí tam, kde mapování existuje. Jediný řádek protokolu nikdy neukáže všechny tři.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194První výpis dokazuje, že server je vázán na port služby, a ukazuje, který proces jej vlastní. Druhý ukazuje lokální socket klienta a cíl, na který volal. Třetí ukazuje mapování, které router vytvořil, a to je jediné místo, kde se přeložený zdroj objevuje. Přečtěte je v tomto pořadí a dvě čísla přestanou vypadat protichůdně.
Co opětovné připojení mění a co ne
Některé routery zachovají zdrojový port klienta, když je volný, jiné přidělí pokaždé jiný. Obě chování jsou normální a aplikace, která vyžaduje první, se na druhém zlomí. Změna mapování po opětovném připojení nebo přepnutí sítě není chyba serveru: klient otevře nový socket, router přidělí, co má, a server vidí nový zdroj na stejném naslouchajícím portu. Chybou by bylo očekávat, že server přijme provoz adresovaný na libovolný klientský port.
Komunitní klienti OpenVPN toto chování získávají pomocí nobind, což nechá operační systém zvolit lokální port; vzdálený port stále pochází z profilu. Explicitní svázání je vědomá volba, ne požadavek protokolu. Server nadále nabízí jeden koncový bod, zatímco klienti si volí vlastní lokální identity.
Označte vrstvy v záznamu odděleně
Uvnitř tunelu probíhá druhá konverzace s vlastními porty. Požadavek HTTPS nesený tunelem má cíl TCP 443, zatímco vnější šifrované spojení používá UDP 1194, takže změna vnějšího zdrojového portu na vnitřní službě nic nemění.
I ve vnější vrstvě záleží na protokolu. UDP 1194 a TCP 1194 jsou různé koncové body a 'TCP' naslouchající port nikdy nepřijme UDP datagram jen proto, že číslo souhlasí. Při dokumentaci nasazení označte naslouchající port serveru, klientský socket a přeložený zdroj jako tři odlišné věci a ke každému přidejte transport.
Pak nechte politiku následovat role. Server otevře zamýšlený transport na svém naslouchajícím portu a stále ověřuje protistranu; firewall klienta propustí odpovědi na jeho vlastní odchozí výměnu, aniž by zveřejnil příchozí službu. Bezstavový filtr potřebuje výslovně zapsaný zpětný směr, a to je praktický důvod, proč na rozlišení záleží i mimo úhledné diagramy.