NAT mögötti VPN, amelyet nem tud beállítani: mi működik mégis

Minden alagút-végpontnak kell egy cím és port, amelyet a másik fél elér, és az a router, amelyet nem Ön felügyel, a szokásos oka annak, hogy ez a követelmény meghiúsul. Az érdekes rész nem az, hogy léteznek trükkök, hanem hogy mindegyik egy olyan leképezési tábla tulajdonságától függ, amelyet az ügyfél felől nem lát. Két ilyen tulajdonság szinte mindent eldönt: hogyan jön létre egy leképezés, és hogy elfogad-e csomagokat olyan címről, amellyel a belső oldal soha nem lépett kapcsolatba. Rendezze a környezetet e tulajdonságok szerint, és a kerülő megoldások megszűnnek népmesének lenni.

A leképezési tábla dönt mindenről

A hálózati címfordítás olyan táblát tart, amelyben egy belső cím és port egy nyilvános cím és port ellenében szerepel. A rekorddal egyező válaszok visszafordításra kerülnek, és a kívülről érkező, egyező rekord nélküli csomagnak egyáltalán nincs célja. Ez az egyetlen viselkedés magyarázza, miért érhetetlen az internetről a router mögötti figyelő. Azt is magyarázza, miért kell minden irányban az első csomagnak belülről indulnia.

Nézze a táblát a router oldaláról, és a kerülő megoldások nyilvánvalóvá válnak: vagy valami állandó bejegyzést hoz létre, vagy ideiglenest hoz létre és frissen tartja, vagy a forgalom sosem arra az útra megy. A cikk többi része ez a három eset sorrendben. Itt semmi nem függ a szállító olyan funkciójától, amely túlmutat azon, amit a tábla rögzít.

Mit tud és mit nem tud a találkozási szolgáltatás

Az UDP-lyukfúrás a kimenő rekordot ideiglenes nyílásként használja, ahelyett hogy legyőzné a szűrőt. Mindkét fél kapcsolatba lép egy találkozási szolgáltatással, amely megtanulja az egyes nyilvános végpontokat, és visszaküldi a másik félnek annak végpontját. Ezután mindketten egymás felé küldenek, és minden kimenő csomag létrehozza vagy felfrissíti azt a rekordot, amely beengedi a választ. A sorrend az, ami működőképessé teszi, és a sorrend az, ami törékennyé is teszi: az a fél, amely a másik rekordjának létrehozása előtt küld, egyszerűen eldobódik, míg egy pillanattal későbbi újrapróbálkozás sikerül. A szolgáltatás maga nem szállít VPN-forgalmat, így egyetlen befolyása az általa összehangolt időzítés.

A leképezési viselkedés dönt a többi részről, és a RFC 4787 három formát nevez meg: végpontfüggetlen, címfüggő, valamint cím- és portfüggő. Utóbbinál a port, amelyet a félnek céloznia kell, minden céllal változik, így az előrejelzés megszűnik megbízhatónak lenni. Ott fut a technika zsákutcába, mert a szolgáltatói szintű NAT és egy szigorú vállalati tűzfal egyaránt eltávolítja azt a kiszámíthatóságot, amelyre a séma szorul, és semmilyen mennyiségű újrapróbálkozás nem hozza vissza.

Keepalive-ok, újraindítások és a mozgó végpont

A kilyukasztott útvonal folyam, nem figyelő, tehát mindennek, ami fölötte fut, túl kell élnie a változást. Folyamatos forgalommal életben kell tartania a leképezést, észre kell vennie, amikor a nyilvános végpont elmozdul, és újra kell épülnie a router újraindítása vagy a cím újrakiosztása után. A mesh VPN termékek ezt a logikát a saját vezérsíkjukba teszik, míg egy egyszerű szerver Önre hagyja. A keepalive-ok csak addig segítenek, amíg ugyanaz a leképezés túlél, és mobil ügyfélen akkumulátort fogyasztanak, ezért az agresszív intervallum nem ingyenes.

Az egy órát alvó laptop általában más nyilvános végponton tér vissza. Mindennek, ami az útvonalat újraépíti, ismét belülről kell futnia, ami ugyanazt a követelményt teszi vissza az ügyfélre.

Három út a hiányzó továbbítás megkerülésére

Az első út arra kéri a routert, hogy maga hozza létre a bejegyzést, UPnP IGD, NAT-PMP vagy PCP segítségével, ha a funkció létezik és be van kapcsolva. A második nyilvános címmel rendelkező relének adja a forgalmat, ami mindig működik, és mindig sávszélességbe, valamint egy másik bizalmi határba kerül. A harmadik megfordítja az irányt: a belső gép kimenő alagutat nyit egy nyilvános szerver felé, és minden más azon belül utazik.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

A relé végpont láthatóvá teszi ezt az alkut az ügyfél konfigurációjában, ahol a végpont relé, nem pedig a fél saját címe. Az állandó keepalive melegen tartja a leképezést, az engedélyezett előtagok pedig eldöntik, mit küldhet az ügyfél rajta keresztül. Fordított alagút a belső gépről ugyanaz az ötlet más tulajdonossal, és egyáltalán nem igényel NAT-változtatást. Mindhárom megszünteti a bejövő követelményt anélkül, hogy legyőzne egy tűzfalat, amely tervezésénél fogva blokkolja a kéretlen forgalmat, mert a forgalom még mindig belülről indul.

Illessze a kerülő megoldást a router tulajdonosához

Ha Ön felügyeli a routert, a statikus UDP-továbbítás könnyebben auditálható, mint bármely lyukfúrási séma, és olyan módokon hibázik, amelyeket lát. Ha nem, derítse ki, kínál-e a szállító relét vagy hosztolt vezérsíkot, és engedné-e a szabályzat a használatát. Ha egyik sem elérhető, a fennmaradó választások a fordított alagút vagy annak elfogadása, hogy a végpont kívülről nem érhető el. Annak rögzítése, melyiket használta, fontosabb, mint hangzik, mert a lehetőségek abban különböznek, ki figyelheti a forgalmat, és mi történik, ha egy harmadik fél megváltoztat valamit.

Jegyezze meg, hogy a végül elért útvonal közvetlen vagy relén keresztüli volt-e, mert ez az egy tény a késleltetést és a hiba viselkedését is előrejelzi. Az RFC 4787 továbbra is a leképezési viselkedés referenciája mindez alatt, és a leképezési fejezetének elolvasása gyorsabb, mint három kerülő megoldás egymás utáni tesztelése. A táblát nem érdekli, melyik lehetőséget választotta; csak azt rögzíti, mit tehet a következő csomag.