SoftEther bak NAT: direkte gjennomtrenging eller VPN Azure-relé?

SoftEther-tenaren din står bak ein leverandørrutet som du ikkje kan endre, og klientane koplar seg framleis til, så du reknar med at eit relé ber alt. Om det er sant, avheng av kva mekanisme som gjorde jobben: eit DNS-namn, ein koordinert UDP-veg eller ein utgåande tunnel til eit relé. Alle tre kan gje ein tilkopla klient, og dei feilar under ulike tilhøve. Bestem kva veg du kjøper før du rører brukarar eller hubar.

Tre mekanismar, tre ulike lovnader

Dynamisk DNS er namngjeving. Det held eit vertsnamn retta mot ei adresse som endrar seg, slik at folk sluttar å jage nummeret, og det gjer ingenting anna. Innebygd NAT-gjennomtrenging er koordinering: to SoftEther-endepunkt utvekslar informasjon og prøver å opne ein brukbar UDP-veg gjennom omsetjingsseiningane mellom dei. VPN Azure er eit relé: tenaren ringjer ut til tenesta, og klientane kjem gjennom eit vertsnamn på infrastrukturen til reléet.

Dei tre utfyller kvarandre i staden for å vere versjonar av éin funksjon. Ei utrulling kan bruke namngjeving medan tilkoplinga faktisk avheng av gjennomtrenginga eller av reléet.

Bestem ut frå klienten og nettverket

Valet startar hos klienten, fordi gjennomtrenging berre finst i den innebygde SoftEther-tilkoplingsmekanismen. OpenVPN, L2TP/IPsec og SSTP-lyttarar på same tenar arvar han ikkje, sjølv om dei deler ein vert. Sjå på kva brukaren skal køyre, og deretter kva nettverket tillèt. Eit bedriftsnettverk som berre tillèt TCP 443, skyv deg mot eit relé på den porten, medan eit nettverk som slepp gjennom UDP-portane gjennomtrenging treng, kan prøve ein direkte veg; stadfest begge mot den faktiske utgåande policyen.

Ein manuelt tilgjengeleg lyttar er framleis eit legitimt design når ein administrator kan publisere ein, men det er eit eige prosjekt med eiga adressering og brannmurarbeid.

Stadfest kva transport økta valde

Tilkoplingsstatus er den einaste ærlege kjelda til vegen som blir brukt. Les han på tenaren, og slå opp vertsnamnet klienten fekk.

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

SessionList viser kva økter som er tilkopla, og SessionGet på éi av dei rapporterer tilkoplingstypen, inkludert om økta kom gjennom reléet. Ei oppføring som blir løyst til reléinfrastruktur fortel deg at økta går gjennom ein tredjepart, noko du kan stadfeste ved å blokkere den ruta i ein test. Med ein innebygd klient kan UDP-akselerasjon flytte datastien bort frå kontrollstien, så éin observasjon skildrar ikkje heile økta. Eit utdatert dynamisk DNS-namn etter ei adresseendring, og eit relé som svarar medan backend-ruta manglar, er to feilmodus det er verdt å teste kvar for seg. Skriv ned det du målte, ikkje det designet hadde tenkt.

Planlegg ut frå kva den valde vegen avheng av

Kvar veg ber ein avhengigheit. Ei direkte gjennomtrenging kan endre seg etter ein nettverksovergang eller ei ny omsetjingsseining, medan ei reléøkt feilar når tenesta eller den tilgjengelege porten hennar feilar. Kopla til på nytt frå eit anna nettverk og stadfest tenaridentiteten klienten verifiserte, medan du held den tidlegare fungerande vegen i same test. Test deretter den private ressursen bak VPN-en, fordi autorisasjon, hub-medlemskap, adressetildeling og returruter uansett blir ditt ansvar.

Skriv ned vertsnamnet, protokollen, funksjonsinnstillingane og den observerte transporten. Nettopp den firedelte registreringa gjer det mogleg for neste person å gjenskape ei fungerande tilkopling.