NAT rozhoduje, kterou zdrojovou adresu váš VPN server skutečně uvidí

Představujete si, že VPN server čte adresu vašeho notebooku z paketu a zapisuje ji do logu. Čte to, co do vnější hlavičky vložil poslední NAT skok, což je na telefonu použitém jako přístupový bod často adresa sdílená se stovkami dalších účastníků. Vlastní adresa vašeho stroje 192.168.x.x přes internet v této hlavičce nikdy nepřejde a adresu tunelu přidělí server až poté, co je spojení navázáno. Když se tedy log serveru a ip addr na notebooku rozcházejí, ani jedno není špatně; popisují různé vrstvy jedné relace.

Tři adresy a v logu je jen jedna

Zmatek vzniká tím, že se tři adresy sloučí v jednu. Každá má jiného vlastníka, žije v jiné hlavičce a k serveru se dostává jinou cestou.

V okamžiku připojení není znám jen prostřední řádek. Server jej zapisuje do své tabulky protějších uzlů, do stavového souboru nebo do logu toků podle démona: WireGuard mu říká koncový bod, stavový soubor OpenVPN jej označuje jako Real Address a strongSwan jej hlásí jako vzdáleného hostitele IKE_SA. Tato hodnota se obnovuje při každém paketu z jiného zdroje, takže se mění, aniž by kdokoli cokoli restartoval.

Spodní řádek je to, co lidé chybně čtou jako tvrzení o identitě. Označuje místo v konfiguraci serveru, ne osobu, protože jej server vybral ze svého vlastního fondu. Dva uživatelé mohou v různých dnech dostat stejnou adresu tunelu a jeden může mít dvě takové adresy ze dvou zařízení.

Proč se zaznamenaný tuple mění, zatímco tunel zůstává aktivní

Překlad adres je tabulka s časovačem, ne trvalá vazba. Domácí router drží své UDP mapování ještě chvíli po posledním paketu, brána operátora recykluje porty podle vlastního plánu a telefon, který přejde z Wi-Fi na LTE, se vrátí s úplně jiným zdrojem. Výchozí hodnoty conntracku v Linuxu jsou zde užitečným měřítkem: nf_conntrack_udp_timeout je 30 sekund a varianta pro streamování 120, takže tichý tunel může ztratit mapování dávno předtím, než si toho uživatel všimne.

Tunel přežívá proto, že protokol ověřuje protější uzel, ne adresu. WireGuard je po handshake bezstavový, takže každý ověřený paket aktualizuje uložený koncový bod a převázání se spraví dalším paketem; proto existuje persistent-keepalive = 25, aby udržel mapování teplé v době nečinnosti. --float v OpenVPN dělá totéž a umožňuje ověřenému klientovi pokračovat z nové adresy a portu. U sestavení 2.4 a 2.5, kde je float ve výchozím nastavení vypnutý, převázání resetuje relaci a klient se znovu připojí.

IPsec se tam dostane s více pohyblivými díly. IKEv2 rozpozná překlad porovnáním hashů zdroje a cíle v užitečném zatížení pro detekci NAT, přejde na zapouzdření do UDP 4500 a sleduje keepalive k novému tupleu. Když jsou keepalive blokovány, SA zůstává na papíře aktivní, zatímco provoz v jednom směru tiše ustane.

Co server může připsat a co ne

Mýtus, který stojí za to zabít, je, že vás překlad skryje před operátorem. Mění označení, ne pozorování. Brána za operátorovým NAT vidí prostor 100.64.0.0/10 nebo jednu veřejnou adresu sdílenou mnoha účastníky, a přesto dokáže tok spojit se subjektem certifikátu, veřejným klíčem WireGuardu, přidělenou adresou tunelu, počítadly bajtů a časovým oknem. Nic z toho nepotřebuje vaši LAN adresu.

Omezení jdou i opačným směrem. Sdílená adresa v logu ukazuje na bránu, ne na domácnost; dvě relace ze stejné přeložené adresy na různých portech jsou různá zařízení; stejná adresa ve dvou různých dnech mohou být dva nesouvisející účastníci, pokud byl port recyklován. Server, který zaznamenává jen klíče protějších uzlů, je bez databáze účtů nedokáže přiřadit zákazníkovi, a server, který zaznamenává jen adresy, nerozliší notebook od telefonu za stejným routerem.

Porovnejte oba konce místo hádání

Chcete-li zjistit, co se stalo, zachyťte stejné spojení na obou koncích ve stejný okamžik a porovnejte tuple, ne adresu. Na klientovi, před jakýmkoli překladem:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

Pak si přečtěte záznam překladu na routeru nebo bráně CGNAT a to, co nakonec dorazí na server:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

Tři vzorce vysvětlují většinu neshod. Zdrojový port na serveru se liší od místního portu, zatímco cíl odpovídá: běžný překlad portů. Zdrojová adresa na serveru patří do bloku ISP, který není váš: nejméně jedna další vrstva NAT. Pakety se po době nečinnosti zastaví a obnoví s novým portem: mapování vypršelo, ne porucha směrování. Pokud jsou časová razítka od sebe více než sekundu nebo dvě, porovnáváte dva různé pokusy.

Kde rozdíl láme věci

Výpadky, které vypadají jako závady serveru, obvykle začínají tady. Přístupové pravidlo přikované k vaší domácí adrese přestane fungovat po změně lease od ISP. Pravidlo fail2ban odpovídající přeložené adrese zablokuje všechny účastníky za touto bránou najednou. Protějšek site-to-site s pevnou vzdálenou adresou přestane obnovovat klíče po změně mobilního spoje. Protokol tunelu byl v pořádku; předpoklad o vnější tuple ne.

Stejný zmatek se objevuje i na straně serveru. Pokud samotná VPN krabice stojí za NAT, potřebujete přesměrování portu a funkční cestu pro předávání; průvodce strongSwan pro předávání pokrývá tento případ pro IPsec. Server dostupný jen na soukromé adrese nikdy nevidí přeloženou tuple, kterou mu jeho klienti předkládají, a to je jiný problém než překlad klientů.

Projděte tyto čtyři kontroly popořadě a zastavte se u první, která selže:

• Zachyťte na obou koncích současně; potvrďte, že zdrojový port, cílový port a časová razítka odpovídají.
• Přečtěte v seznamu protějších uzlů serveru adresu, kterou právě drží, ne adresu, kterou jste očekávali.
• Zkontrolujte tabulku conntrack nebo NAT na záznam a jeho zbývající životnost.
• Potvrďte, že adresa tunelového rozhraní na klientovi odpovídá té, kterou přidělil server, ne adrese LAN.

Pokud se oba záznamy shodují na tuple a tunel přesto nefunguje, překlad není váš problém; přejděte k handshake a ke směrovací tabulce uvnitř tunelu.