Elérés egy NAT mögötti munkaállomáshoz porttovábbítás nélkül
Egy bejövő port nélküli munkaállomás is elérhető hubon, relén vagy alkalmazásbrókeren keresztül. Hasonlítsa össze, mit garantál az egyes tervek, mielőtt választ.
Két végpont a szolgáltató NAT-ja mögött és egy lezárt irodai router nem hagy bejövő portot továbbításra, a reflexus mégis az, hogy kérjünk egyet. A jobb kérdés az, melyik oldal tud kifelé tárcsázni, és melyik elérhető szolgáltatásnak van engedélye a forgalom szállítására. Négy terv válaszol erre a kérdésre eltérően, és eltérő módon hibázik, amikor egy útvonal blokkolva van. A köztük való választás a garanciák összehasonlítása, nem a protokollneveké.
Négy terv, négy különböző ígéret
Az alábbi táblázat a rövid változat. A középső oszlopot úgy olvassa, mint a tesztelhető ígéretet, a jobb oszlopot pedig úgy, mint amit senki nem ígért.
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
Hogy melyik sor érvényes, a feladattól függ, nem a preferenciától. Egy távoli asztali munkamenet, egy rendszergazdai shell és hozzáférés egy egész privát alhálózathoz három olyan követelmény, amelyeknek nem kell ugyanaz a belépési pont, még ha véletlenül ugyanazt a gépet érintik is.
A hub megváltoztatja, ki tárcsáz kifelé, nem azt, mi engedélyezett
Egy irányított hubos tervben a távoli laptop és a munkaállomás, vagy az előtte lévő telephelyi átjáró, mindegyik kimenő alagutat nyit egy olyan szolgáltatás felé, amelyet mindkettő elér. Semmi nem fogad kéretlen kapcsolatot a munkaállomás routerén, és pontosan ezért éli túl ez a terv a NAT-ot, és működik akkor is, amikor a telephelynek nincs statikus címe. Ezután a hub a saját szabályzata szerint irányítja a forgalmat a két belső cím között.
Az ár az, hogy a hubnak léteznie kell, mindkét oldalról elérhetőnek kell lennie, és valakinek üzemeltetnie kell. A kimenő szűrésnek engedélyeznie kell a szállítást, és egy azt blokkoló hálózat meghiúsítja a tervet, még ha nem is kellett porttovábbítás.
A finom rész az, hogy az elérhetőség és a jogosultság külön döntések, amelyeket különböző helyeken hoznak. Egy előtag felé vezető útvonal semmit nem mond arról, melyik szolgáltatást használhatja az identitás a munkaállomáson, és a tűzfal-szabály, amely engedélyezi az alagutat, semmit nem mond arról, be tud-e jelentkezni a fiók. Konfigurálja mindkettőt, tesztelje mindkettőt, és tartsa a jogosultsági döntést annál a rendszernél, amely az erőforrás tulajdonosa, ne az útválasztási táblánál.
Az átjárás csak akkor működik, ha mindkét verem megvalósítja
A peerek közötti átjárás egy adott rendszer képessége, nem olyan beállítás, amely javítja a VPN-t. Az Interactive Connectivity Establishment több jelöltcímet gyűjt, és párokat tesztel, amíg egy működik: gazdacímek a helyi interfészeken, kiszolgáló-tükröző jelöltek abból, amit a NAT felfed, és relén kiosztott továbbított jelöltek. Egy privát cím önmagában nem útvonal, mert a másik oldal nem tud oda irányítani.
A továbbított esetet érdemes megérteni, mielőtt elvetjük. RFC 8656 a TURN-t olyan protokollként írja le, amelyben az ügyfél továbbított szállítási címet kér a kiszolgálótól, és a kiszolgáló továbbítja a forgalmat ezen ügyfél és peerjei között. A relé tehát szállítja az adatokat, ami lényegesen más, mint egy olyan könyvtár, amely csak segít a végpontoknak találkozni. A relécím cseréje a peerrel olyan koordinációs lépés, amelyet az alkalmazásnak el kell végeznie.
Amit nem ígérhet, az a közvetlen útvonal. A szimmetrikus NAT és néhány vállalati tűzfal meghiúsítja a lyukfúrást, és amikor ezt teszik, a rendszer vagy visszaáll egy relére, vagy meghibásodik. Arra sem következtethet, hogy két lefordított végpont soha nem tud beszélni; a relés tartalékkal rendelkező támogatott verem éppen azért létezik, mert gyakran tudnak. Döntse el, hogy az elérhetőség vagy a közvetlenség fontosabb, majd ellenőrizze, melyik útvonalat választotta valójában a telepítés, ahelyett hogy a kedvező esetet feltételezné.
A bróker szűkebb, mint egy hálózat
Amikor a követelmény egyetlen alkalmazás, egy alkalmazásbróker vagy a munkaállomás által indított fordított kapcsolat lehet a legkisebb válasz. A munkaállomás kifelé tárcsáz egy brókerhez, a bróker hitelesíti a távoli felhasználót, és csak az az alkalmazás-munkamenet szállítódik. Nem jön létre útvonal a munkaállomás alhálózata felé, így a távoli munkamenet kompromittálása nem örököl utat minden mellette lévő eszközhöz.
Ennek a szűkségnek ára van: minden további alkalmazásnak saját integráció kell, és bármi, amit az alkalmazás egy helyi hálózatról feltételez, például egy fájlmegosztás, amelyet egy közeli kiszolgálón nyit meg, lehet, hogy nem elérhető. A brókerek a szabályzatot és a naplózást is egy helyen összpontosítják, ami addig hasznos, amíg az a hely leállássá nem válik.
Hasonlítsa össze a bizalmi határokat, majd tesztelje az útvonalat
Az alagutakat lezáró hub olvashatja az általa irányított forgalmat. A relé önállóan védett cserét szállíthat, amikor az alkalmazás végponttól végpontig titkosít, a bróker pedig általában lezárja a bemutatott munkamenetet. Állapítsa meg, hol ér véget valójában a védelem, mielőtt úgy dönt, hogy két terv egyenértékű, mert mindkettő titkosított.
Ezután ellenőrizze, mit ér el a munkaállomás kifelé valójában, mert a fenti tervek mindegyike ettől függ. Futtassa ezt a munkaállomáson, és cserélje ki a használni kívánt gazdanevet.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comCsak akkor fogadja el a tervet, ha a szándékolt távoli művelet az engedélyezett identitás alatt sikerül, a nem jóváhagyott identitás elutasításra kerül, és ismert és dokumentált, mi történik, ha a közvetlen vagy továbbított útvonal nem elérhető. Vegye bele az újracsatlakozást és a munkaállomás szokásos indítási környezetét, mert az irodában a LAN-on keresztül indult munkamenet semmit nem tesztel abból, amitől a távoli hozzáférés függ.