SoftEther NAT mögött: közvetlen áthatolás vagy VPN Azure-relé?

A SoftEther-kiszolgálója egy szolgáltatói router mögött áll, amelyet nem tud módosítani, és az ügyfelek mégis csatlakoznak, ezért feltételezi, hogy egy relé visz mindent. Az, hogy ez igaz-e, attól függ, melyik mechanizmus végezte a munkát: egy DNS-név, egy összehangolt UDP-útvonal vagy egy kimenő alagút egy reléhez. Mindhárom létrehozhat csatlakozott ügyfelet, és különböző körülmények között hibáznak. Döntse el, melyik útvonalat vásárolja, mielőtt felhasználókhoz vagy hubokhoz nyúlna.

Három mechanizmus, három különböző ígéret

A dinamikus DNS elnevezés. Egy hosztnevet változó címre irányítva tart, hogy az emberek ne kergethessék tovább a számot, és semmi mást nem tesz. A natív NAT-áthatolás koordináció: két SoftEther végpont információt cserél, és megpróbál egy használható UDP-útvonalat nyitni a köztük lévő fordítási eszközökön keresztül. A VPN Azure egy relé: a kiszolgáló kifelé tárcsáz a szolgáltatáshoz, az ügyfelek pedig egy hosztnéven keresztül érkeznek a relé infrastruktúráján.

A három kiegészíti egymást, nem egyetlen funkció változatai. Egy telepítés használhat elnevezést, miközben a kapcsolata valójában az áthatolástól vagy a relétől függ.

Az ügyfél és a hálózat alapján döntsön

A választás az ügyfélnél kezdődik, mert az áthatolás csak a natív SoftEther kapcsolódási mechanizmusban létezik. Az ugyanazon a kiszolgálón futó OpenVPN, L2TP/IPsec és SSTP figyelők nem öröklik, bár egy hosztot osztanak meg. Nézze meg, mit fog futtatni a felhasználó, majd hogy mit enged a hálózat. Egy vállalati hálózat, amely csak a TCP 443-at engedi, a relé felé tereli ezen a porton, míg egy hálózat, amely átengedi az áthatoláshoz szükséges UDP-portokat, közvetlen útvonalat kísérelhet meg; mindkettőt ellenőrizze a tényleges kimenő szabályzattal szemben.

A kézzel elérhető figyelő továbbra is legitim tervezés, ha egy rendszergazda közzé tud tenni egyet, de ez külön projekt saját címzési és tűzfalas munkával.

Ellenőrizze, melyik átvitelt választotta a munkamenet

A kapcsolat állapota az egyetlen őszinte forrás a használt útvonalról. Olvassa el a kiszolgálón, és oldja fel az ügyfél által kapott hosztnevet.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

A SessionList megmutatja, mely munkamenetek kapcsolódnak, a SessionGet pedig az egyiken jelenti a kapcsolat típusát, beleértve azt is, hogy a munkamenet a relén keresztül érkezett-e. A relé infrastruktúrájára feloldódó rekord azt mondja, hogy a munkamenet harmadik félen halad át, amit úgy erősíthet meg, hogy blokkolja ezt az útvonalat egy tesztben. Natív ügyféllel az UDP-gyorsítás elmozdíthatja az adatútvonalat a vezérlőútvonaltól, így egyetlen megfigyelés nem írja le a teljes munkamenetet. Egy elavult dinamikus DNS-név címváltozás után, és egy relé, amely válaszol, miközben a háttérútvonal hiányzik, két külön tesztelendő hibaállapot. Azt írja le, amit mért, ne azt, amit a tervezés szándékozott.

Tervezze meg, mitől függ a választott útvonal

Minden útvonal hordoz egy függőséget. A közvetlen áthatolás megváltozhat hálózati átmenet vagy új fordítási eszköz után, míg a relé munkamenet meghiúsul, ha a szolgáltatás vagy annak elérhető portja meghiúsul. Csatlakozzon újra egy másik hálózatról, és erősítse meg az ügyfél által ellenőrzött kiszolgálóidentitást, megtartva a korábban működő útvonalat ugyanabban a tesztben. Ezután tesztelje a VPN mögötti privát erőforrást, mert az engedélyezés, a hubtagság, a címkiosztás és a visszatérő útvonalak mindenképp az Ön felelőssége marad.

Írja le a hosztnevet, a protokollt, a funkció beállításait és a megfigyelt átvitelt. Ez a négyrészes feljegyzés teszi lehetővé a következő embernek egy működő kapcsolat újratermelését.