SoftEther achter NAT: directe doorgang of VPN Azure-relay?

Uw SoftEther-server staat achter een router van de provider die u niet kunt wijzigen, en clients verbinden toch, dus u neemt aan dat een relay alles draagt. Of dat waar is, hangt af van welk mechanisme het werk deed: een DNS-naam, een gecoördineerd UDP-pad of een uitgaande tunnel naar een relay. Alle drie kunnen een verbonden client opleveren, en ze falen onder verschillende omstandigheden. Beslis welk pad u koopt voordat u gebruikers of hubs aanraakt.

Drie mechanismen, drie verschillende beloften

Dynamische DNS is naamgeving. Het houdt een hostnaam gericht op een veranderend adres zodat mensen ophouden het nummer achterna te zitten, en het doet niets anders. Native NAT-doorgang is coördinatie: twee SoftEther-eindpunten wisselen informatie uit en proberen een bruikbaar UDP-pad te openen door de vertaalapparaten tussen hen. VPN Azure is een relay: de server belt uit naar de dienst, en clients komen binnen via een hostnaam op de infrastructuur van de relay.

De drie zijn aanvullend in plaats van versies van één functie. Een implementatie kan naamgeving gebruiken terwijl de verbinding feitelijk van de doorgang of van de relay afhangt.

Beslis vanuit de client en het netwerk

De keuze begint bij de client, omdat doorgang alleen bestaat in het native SoftEther-verbindingsmechanisme. OpenVPN, L2TP/IPsec en SSTP-luisteraars op dezelfde server erven het niet, ook al delen ze een host. Kijk naar wat de gebruiker gaat draaien en dan naar wat het netwerk toestaat. Een bedrijfsnetwerk dat alleen TCP 443 toestaat, duwt u naar een relay op die poort, terwijl een netwerk dat de UDP-poorten doorlaat die doorgang nodig heeft, een direct pad kan proberen; bevestig beide tegen het werkelijke uitgaande beleid.

Een handmatig bereikbare luisteraar is nog steeds een legitiem ontwerp wanneer een beheerder er een kan publiceren, maar het is een apart project met eigen adressering en firewallwerk.

Bevestig welke transportlaag de sessie koos

Verbindingsstatus is de enige eerlijke bron voor het pad dat in gebruik is. Lees die op de server en los de hostnaam op die de client kreeg.

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

SessionList toont welke sessies verbonden zijn, en SessionGet op een ervan meldt het verbindingstype, inclusief of de sessie via de relay binnenkwam. Een record dat naar relayinfrastructuur oplost, vertelt u dat de sessie via een derde partij loopt, wat u kunt bevestigen door die route in een test te blokkeren. Met een native client kan UDP-versnelling het datapad van het controledpad wegschuiven, dus één waarneming beschrijft niet de hele sessie. Een verouderde dynamische DNS-naam na een adreswijziging, en een relay die antwoordt terwijl de backend-route ontbreekt, zijn twee faalmodi die apart getest moeten worden. Noteer wat u hebt gemeten, niet wat het ontwerp bedoelde.

Plan voor waarvan het gekozen pad afhangt

Elk pad draagt een afhankelijkheid. Een directe doorgang kan veranderen na een netwerkovergang of een nieuw vertaalapparaat, terwijl een relaysessie faalt wanneer de dienst of zijn bereikbare poort faalt. Verbind opnieuw vanaf een ander netwerk en bevestig de serveridentiteit die de client verifieerde, terwijl u het eerder werkende pad in dezelfde test houdt. Test daarna de privébron achter de VPN, want autorisatie, hub-lidmaatschap, adrestoewijzing en retourroutes blijven in elk geval uw verantwoordelijkheid.

Schrijf de hostnaam, het protocol, de functie-instellingen en de waargenomen transportlaag op. Juist die vierdelige registratie maakt het voor de volgende persoon mogelijk een werkende verbinding te reproduceren.