SoftEther bakom NAT: direkt genomträngning eller VPN Azure-relä?

Din SoftEther-server står bakom en leverantörsrouter som du inte kan ändra, och klienterna ansluter ändå, så du antar att ett relä bär allt. Om det stämmer beror på vilken mekanism som gjorde jobbet: ett DNS-namn, en koordinerad UDP-väg eller en utgående tunnel till ett relä. Alla tre kan ge en ansluten klient, och de misslyckas under olika förhållanden. Bestäm vilken väg du köper innan du rör användare eller hubbar.

Tre mekanismer, tre olika löften

Dynamisk DNS är namngivning. Det håller ett värdnamn riktat mot en adress som ändras så att folk slutar jaga numret, och gör inget annat. Inbyggd NAT-genomträngning är samordning: två SoftEther-ändpunkter utbyter information och försöker öppna en användbar UDP-väg genom översättningsenheterna mellan dem. VPN Azure är ett relä: servern ringer ut till tjänsten, och klienter anländer via ett värdnamn på reläets infrastruktur.

De tre kompletterar varandra snarare än är versioner av en funktion. En distribution kan använda namngivning medan dess anslutning faktiskt beror på genomträngningen eller på reläet.

Bestäm utifrån klienten och nätverket

Valet börjar hos klienten, eftersom genomträngning bara finns i den inbyggda SoftEther-anslutningsmekanismen. OpenVPN, L2TP/IPsec och SSTP-lyssnare på samma server ärver den inte, trots att de delar en värd. Titta på vad användaren ska köra och sedan vad nätverket tillåter. Ett företagsnät som bara tillåter TCP 443 knuffar dig mot ett relä på den porten, medan ett nät som släpper igenom de UDP-portar som genomträngning behöver kan försöka en direkt väg; bekräfta båda mot den faktiska utgående policyn.

En manuellt nåbar lyssnare är fortfarande en legitim design när en administratör kan publicera en, men det är ett separat projekt med egen adressering och brandväggsarbete.

Bekräfta vilken transport sessionen valde

Anslutningsstatus är den enda ärliga källan till vägen som används. Läs den på servern och slå upp värdnamnet klienten fick.

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

SessionList visar vilka sessioner som är anslutna, och SessionGet på en av dem rapporterar anslutningstypen, inklusive om sessionen kom via reläet. En post som löses upp till reläinfrastruktur säger att sessionen går genom en tredje part, vilket du kan bekräfta genom att blockera den rutten i ett test. Med en inbyggd klient kan UDP-acceleration flytta datavägen bort från kontrollvägen, så en observation beskriver inte hela sessionen. Ett inaktuellt dynamiskt DNS-namn efter en adressändring, och ett relä som svarar medan backend-vägen saknas, är två felmoder som är värda att testa separat. Skriv ned det du mätte, inte det designen avsåg.

Planera utifrån vad den valda vägen beror på

Varje väg bär ett beroende. En direkt genomträngning kan ändras efter en nätverksövergång eller en ny översättningsenhet, medan en reläsession misslyckas när tjänsten eller dess nåbara port misslyckas. Anslut igen från ett annat nätverk och bekräfta serveridentiteten som klienten verifierade, och behåll den tidigare fungerande vägen i samma test. Testa sedan den privata resursen bakom VPN, eftersom auktorisering, hub-medlemskap, adressutdelning och returvägar ändå förblir ditt ansvar.

Skriv ned värdnamnet, protokollet, funktionsinställningarna och den observerade transporten. Just den fyrdelade registreringen gör det möjligt för nästa person att återskapa en fungerande anslutning.