SoftEther VPN Azure: reléútvonal, nem nyitott port

A kiszolgálója egy olyan útválasztó mögött van, amelyet nem tud beállítani, így a port továbbításának kézenfekvő terve nem elérhető. VPN Azure pontosan erre a helyzetre létezik, és úgy oldja meg, hogy megfordítja az első kapcsolat irányát: a kiszolgáló kifelé csatlakozik egy reléhez, az ügyfelek pedig a relét érik el a kiszolgáló helyett. Ennek a fordításnak a megértése megmagyarázza, mit javít a szolgáltatás, és minden korlátot, amelybe később belefut.

Mi változik az útvonalban

Hagyományos figyelő esetén az ügyfél TCP-kapcsolatot nyit egy nyilvános címre, amelyet az útválasztója a kiszolgálóhoz továbbít. A relé esetén a kiszolgáló kimenő kapcsolatot tart fenn a relé infrastruktúrája felé, a relé pedig elfogadja az ügyfélkapcsolatokat, és továbbadja azok terhelését a várakozó kiszolgálónak. Nem nyílik bejövő port, nem szükséges statikus cím, és az útválasztó érintetlen marad. A tűzfal szempontjából a kiszolgáló közönséges kimenő ügyfél, ezért engedik át a korlátozó hálózatok.

A relé saját domainjén nevet rendel ehhez a kiszolgálóhoz, és az ügyfelek úgy vannak beállítva, hogy oda kapcsolódjanak.

Ez a név a relészolgáltatáshoz tartozik, amely nem Microsoft Azure VPN Gateway, bár mindkettőt Azure valaminek hívják. Felcserélhetőként kezelésük olyan konfigurációt eredményez, amely nem működhet.

Mely protokollok jutnak át a relén

A relé a SoftEther protokollt szállítja, és a projekt az SSTP ügyfélopcióként dokumentálja, ami hasznos, mert a Windows SSTP-ügyfelet tartalmaz. Nem válik azonban a gazdagép minden figyelőjének általános hordozójává: az OpenVPN-figyelőnek, az IPsec-válaszadónak és az L2TP-szolgáltatásnak külön-külön elérhető végpontra van szüksége, és egyiket sem szállítja a relé csak azért, mert a SoftEther-kiszolgáló csatlakozik.

Az ügyfélprofilok ezért a relé nevére mutatnak a kiszolgáló címének helyett, és a közvetlen kapcsolathoz készített meglévő profil nem működik változtatás nélkül. A tervezés előtt nézze meg a támogatott ügyfelek listáját az általa futtatott verzióhoz, ha olyan protokoll köré tervez, amelyet a relé nem szállít.

Amit a relé nem tesz meg Önért

A relé egy szállítóeszköz. Nem hoz létre felhasználókat, virtuális hubokat, hozzáférési házirendeket vagy útvonalakat, és semmit sem tud a kiszolgálója mögötti magánhálózatokról. Ha a távoli ügyfeleknek el kell érniük egy LAN-alhálózatot, a kiszolgálónak továbbra is szüksége van a híd- vagy útvonalválasztó beállításra, a visszaútra és a tűzfalszabályzatra, amelyek ezt működőképessé teszik. A két vég átfedő címtervei szintén láthatatlanok a relé számára, és továbbra is az Ön megoldandó problémája maradnak.

A támogatott biztonsági beállításokat is Ön választja. A projektdokumentáció régebbi platformpéldákat tartalmaz, és az elavult titkosítási vagy tanúsítványbeállítások régi képernyőképről való másolása jó módja annak, hogy olyan alagutat építsen, amelyet senki sem tud auditálni. Használja az aktuális útmutatót az általa futtatott verzióhoz.

A tanúsítványok ellenőrzése és a felhasználók hitelesítése a kiszolgáló felelőssége marad, és a relé soha nem helyettesíti egyiket sem.

Üzemeltesse függőségként

Az elérhetőség most egy harmadik felet is magában foglal. Ha a relé nem érhető el, az ügyfelek nem tudnak kapcsolódni, függetlenül attól, mennyire egészséges a kiszolgálója, és a hiba kívülről ügyfélproblémának tűnik. Figyelje a relé útvonalát a kiszolgáló egészségétől külön, és tartson dokumentált tartalékot, például egy közvetlen figyelőt másik címen arra a napra, amikor számít.

A késleltetés a relé földrajzát követi, nem a felhasználói közelségét, amit érdemes megmérni, mielőtt interaktív teljesítményt ígérne rajta.

Ellenőrizze a kiszolgáló személyazonosságát, majd egy valódi alkalmazásútvonalat, nem csak egy sikeres kapcsolódási sávot, és nézze meg, hogy a szükséges erőforrás elérhető-e a relé által szállított címcsaládon. Jegyezze fel a relé nevét, a használt protokollt és a tartalékot, mert ez a három tény válaszol a legtöbb jövőbeli kérdésre erről a kapcsolatról.