Port-triggering vagy port-továbbítás otthoni VPN-szerverhez

A port-továbbítás és a port-triggering a legtöbb otthoni routeren ugyanabban a menüben van, ezért úgy kezelik őket, mintha egy munka két módja lennének. A továbbítás statikus szabály: a WAN-portra érkező bejövő kapcsolat egy rögzített belső címre és portra fordul le, akár történik más, akár nem. A triggering feltételes: a router figyeli a kimenő forgalmat, és csak akkor nyit bejövő leképezést, ha egy megfelelő kapcsolat kimegy. A VPN-szerver arra vár, hogy előbb más kapcsolódjon, tehát éppen ez a feltétel az az egyetlen dolog, amit soha nem tud teljesíteni.

Két szabály, eltérő életciklussal

Az IPv4 NAT állapottartó. Amikor egy belső hoszt csomagot küld ki, a router leképezést hoz létre, hogy a válaszok megtalálják a visszautat; a bejövő csomagot, amely semelyik leképezéshez nem illik, eldobja, és ez az a viselkedés, amely a nem frissített asztali gépet az interneten kívül tartja. A továbbítás kézzel hozzáadott állandó fordítási bejegyzés. A triggering forgalmi mintával őrzött ideiglenes lyuk.

A gyakorlati különbség az idő. A továbbítás a mentés pillanatától létezik, amíg valaki törli. A kiváltott leképezés a trigger kiváltása után létezik, és tétlenségi időzítő zárja be, amelyet fogyasztói hardveren percekben mérnek, vagy újraindításkor azonnal.

Egyik sem biztonságosabb elvont értelemben. A továbbítás egy portot folyamatosan kitár; a trigger csak meghatározott kimenő forgalom után tárja ki. Egy olyan szolgáltatásnál, amelynek egy idegentől kell fogadnia az első csomagot, csak az egyik illik a feladathoz.

Miért nem tesz közzé szervert a triggering

A VPN-szerver tervezésénél fogva passzív. A partner, legyen az kávézói laptop vagy mobilneten lévő telefon, elküldi az első csomagot, és a routernek nincs hozzá leképezése. Odabent semmi nem indított forgalmat a trigger-portra, ezért a szabály soha nem lép működésbe, és a kapcsolat meghal, mielőtt a kézfogás elkezdődne.

Ahol a triggering működni látszik, ott valami más termel forgalmat a trigger-porton: egy kliens a LAN-on, egy monitorozó szonda vagy a szerver saját kimenő ellenőrzései. Ekkor a leképezés ahhoz az egy hoszthoz nyílik meg, és záródik, amikor a forgalom megáll, így a következő külső partner újra elbukik, miközben az első siker a naplóban ül, és bizonyítéknak látszik.

A triggering általában egyetlen hosztos is. Sok megvalósítás egyszerre csak egy belső eszköznek engedi a leképezést tartani, ami pontosan rossz egy olyan szervernél, amelynek több partnernek kell válaszolnia. A funkciót olyan alkalmazásokhoz építették, amelyek kimenő vezérlőkapcsolatot nyitnak, és egy második porton várnak bejövő adatot, és még mindig ehhez a formához illik.

Mit képez le valójában a továbbítás

A továbbítás egyetlen fordítási bejegyzés: WAN-port és protokoll belső címre és portra. Kell hozzá egy már futó figyelő a másik oldalon, és kell, hogy a belső cím a helyén maradjon. A másik gépre átkerülő DHCP-bérlet minden alagutat csendben a rossz hosztra küld, ezért a foglalást a szabály előtt hozza létre.

A protokoll fontosabb, mint amit az űrlap sugall. OpenVPN UDP fölött UDP-továbbítást igényel, a WireGuard UDP-t igényel, az IPsec-adat pedig ESP-ként, 50-es IP-protokollként érkezik, amelynek egyáltalán nincsenek portjai. Az olyan továbbítási űrlap, amely csak TCP-t vagy UDP-t fogad el, ezt nem tudja kifejezni, ezért az IPsecnek passthrough vagy statikus egy-az-egyhez leképezés kell portszabály helyett.

A routere fölötti réteg

A továbbítás csak a saját fordítását vezérli. Ha a WAN-cím nem az Öné, ami hordozószintű NAT mögött így van, ahol az előfizetők 100.64.0.0/10-et osztoznak az RFC 6598-ban leírtak szerint, a bejövő kapcsolat soha nem ér el a routeréhez, mert a szolgáltató fordított előbb. Az eszközén semmilyen szabály nem javítja ezt a sorrendet.

A kettős NAT ugyanez a probléma kicsiben. A routere az internetszolgáltató routeréhez továbbít, amelynek nincs megfelelő szabálya, és eldobja a csomagot. Vagy tegye hozzá a szabályt a külső eszközön, vagy állítsa a külső eszközt híd módba, és hagyja, hogy az Öné tartsa a nyilvános címet.

Ezért a tesztnek kívülről kell jönnie. Az ugyanazon a LAN-on, a nyilvános címen keresztül végzett teszt a hairpin NAT támogatásától függ, és a szabálytól független okokból is sikerülhet vagy bukhat meg; a mobilnetes telefon vagy egy másik hálózaton lévő barát a tisztább ellenőrzés.

Szűkítse a szabályt, aztán ellenőrizze mindkét felét

Egy portot egy címre továbbítson. A tartomány, amelyet azért adtak hozzá, mert az első próbálkozások elbuktak, az az út, amelyen a kezelőfelületek az internetre kerülnek, és a VPN-figyelőnek nincs szüksége a router admin oldalára mellette közzétéve.

Tartsa meg mindazt, ami már védte ezt a figyelőt: tanúsítvány- vagy kulcsazonosság, hoszt tűzfal, naprakész csomagverziók. A továbbítás beenged egy csomagot; a hitelesítés dönti el, hogy a csomagból alagút lesz-e, és ez két külön hiba, amikor valami elromlik.

Az ellenőrzésnek két fele van. A kézfogásnak külső hálózatról kell befejeződnie, majd a szerver mögötti privát erőforrásnak az alagúton keresztül kell válaszolnia. A továbbítás beengedi az alagút kapcsolatát és semmi többet; a 10.8.0.0/24 útválasztása és engedélyezése más beállítás egy másik képernyőn.

Döntsön három kérdéssel

Három kérdés gyorsabban eldönti a választást, mint bármely összehasonlító táblázat:

• Kapcsolódik-e valami kívülről első csomagként? Akkor használjon továbbítást vagy egy relét. A triggering nem tud megnyílni olyan kimenő forgalom nélkül, amely soha nem lesz.
• Kell-e a lyuknak túlélnie a tétlenségi időt? Akkor használjon továbbítást, mert a kiváltott leképezés a saját ütemezése szerint zárul.
• A WAN-cím az Öné, hogy közzétegye? Ha nem, javítsa a fölötte lévő réteget, mielőtt bármely szabályt szerkeszt.

Ha mindháromra nem a válasz, ami egy kereskedelmi szolgáltatót maga tárcsázó laptop esete, egyik szabály sem kell. A NAT mögötti kliens azért működik, mert maga hozza létre az állapottartó leképezést, és ez a legtöbb embert lefedi, aki éjfélkor a port-továbbításról szóló oldalt olvassa.