Pevné UDP porty môžu obísť presmerovanie portov, ale nie každý NAT

Dva domáce routery, žiadne presmerované porty a VPN, ktoré sa niekedy predsa pripojí. UDP to umožňuje, pretože firewall prepustí paket, ktorý dokáže spárovať s tokom, ktorý stroj už začal. Je to podmienený trik, nie funkcia, a podmienky sa dajú ľahko vymenovať, keď viete, čo firewall porovnáva. Sú aj dôvodom, prečo sa rovnaké profily v rôznych sieťach správajú odlišne.

Porovnanie, ktoré firewall vykonáva

Každý odchádzajúci datagram vytvorí krátkodobú položku: zdrojová adresa, zdrojový port, cieľová adresa, cieľový port. Čokoľvek príde a zhoduje sa s položkou, považuje sa za odpoveď a prepustí sa. Pravidlá pre prichádzajúcu prevádzku do toho nevstupujú.

Otázka teda nie je, či firewall pustí partnera dnu. Ide o to, či paket partnera vyzerá ako odpoveď, na ktorú položka čaká. Zmeňte jedno pole tejto štvordielnej n-tice a paket sa stane cudzincom. Preto sa funkčná konfigurácia môže pokaziť, keď sa zmení iba číslo portu, a preto ten istý port môže na jednom routeri fungovať a na ďalšom zlyhať.

Zafixujte miestny zdrojový port a to isté číslo sa objaví na oboch stranách výmeny. To je celý mechanizmus a vysvetľuje, prečo je trik krehký, a nie záhadný.

Zafixovanie jedného portu na každom konci

Predvolený UDP port OpenVPN je 1194 a lport nastavuje zdrojový port, z ktorého odosiela. Zafixujte oboch partnerov a odchádzajúca n-tica každého bude ukazovať na port, na ktorom ten druhý počúva:

# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194

To funguje len dovtedy, kým žiadny router medzi nimi neprepisuje zdrojový port. Keď sa pakety objavia v zachytení, ale tunel nevznikne, prepis je prvým podozrivým.

Kde sa n-tica prestane zhodovať

NAT, ktorý mapuje podľa cieľa, dá každému partnerovi iný vonkajší port. Adresa, ktorú partnerovi povedali, aby použil, nie je adresa, ktorá sa k nemu dostane, takže prichádzajúci paket sa s ničím nezhoduje a je ticho zahodený.

Preklad na úrovni operátora, vrstvený NAT aj randomizácia portov končia rovnako. Rovnako každý medzičlen, ktorý prepisuje porty a adresy necháva na pokoji.

Pri prúdových transportoch je to horšie. TCP handshake sa sleduje krok za krokom, takže VPN postavená na TCP sa takto nedá vôbec prepichnúť a potrebuje poslucháča niekde na ceste.

Zvyčajne zlyhá najprv jedna strana

V praxi sa obe siete správajú málokedy rovnako. Jeden router môže prideľovať predvídateľné mapovanie, zatiaľ čo druhý prideľuje porty podľa cieľa, a výsledkom je konfigurácia, ktorá funguje medzi dvoma domovmi a zlyhá z mobilnej siete. Protirečiace si správy zvyčajne opisujú dve rôzne dvojice routerov. Ani jeden autor sa nemýli a ani jeden výsledok sa nezovšeobecňuje.

Skôr než sa dotknete profilov, zistite, ktorá strana paket zahodila. Zachytenia na oboch koncoch to vyriešia na jeden pokus: datagramy, ktoré opustia A a nikdy nedorazia do B, znamenajú, že tok bol po ceste prepísaný, kým datagramy, ktoré dorazia do B a žiadna odpoveď sa nevracia, znamenajú, že ich firewall neprijal ako súvisiace.

Dvaja partneri s verejnými adresami IPv6 celý problém obídu. Bez prekladu niet čo párovať, takže stačí pravidlo firewallu, ktoré partnerov pomenuje, a návrh prestane závisieť od správania routera.

Kedy prestať skúšať

Hostiteľ s verejnou adresou je spoľahlivá odpoveď. Môže ukončiť tunel pre oboch partnerov, alebo im jednoducho pomôcť zistiť aktuálnu vonkajšiu adresu toho druhého, a obe usporiadania fungujú bez ohľadu na to, čo NAT robí. Spravovaný overlay poskytuje rovnakú koordináciu, ak to politika dovolí.

Nič z toho nepotrebuje vypnutý firewall. Vypnutie ochrany, aby sme vyhrali priame spojenie, zahadzuje dôvod, prečo bol priamy pokus lákavý, a necháva stroj otvorený po celý čas testu.

Najprv vyskúšajte priame usporiadanie a potom si zapíšte, čo ste videli. Správanie NAT a zachytenie, ktoré ho ukázalo, majú väčšiu cenu než dvojica portov, ktorú ste nakoniec použili, pretože ďalšia sieť bude iná. manuál OpenVPN 2.6 dokumentuje lport a voľby remote, na ktorých to závisí.