SoftEther lokal brygga eller SecureNAT: vilken du ska slå på

Öppna SoftEther Manager, och det första riktiga beslutet om en hubb är inte en kryssruta, det är en topologifråga. En lokal brygga kopplar hubben till en fysisk adapter och låter det befintliga segmentet leverera adresseringen, medan SecureNAT ger hubben sin egen virtuella router, NAT och DHCP. Valet mellan dem ändrar var adresserna kommer från och vilken enhet som svarar för dem. Att slå på båda och hoppas att en vinner är hur ett fungerande labb blir en supporttråd.

Börja med hubben du faktiskt redigerar

Manager visar ett träd av servrar och hubbar, och det är lätt att konfigurera standardhubben medan klienterna ansluter till en annan med ett annat namn. Klicka på hubben, läs dess namn och bekräfta att sessionerna som listas under den är de klienter du försöker betjäna. Den enda kontrollen hindrar det mesta av den förvirring som senare skylls på protokollet.

Bestäm sedan vad klienten behöver från den bortre änden. Delat Ethernet-beteende med broadcast och LAN-tjänster pekar på en brygga, routad privat åtkomst till ett litet adressområde pekar på SecureNAT, och en internetutgång är ett routingbeslut som båda arrangemangen kan bära dåligt.

Skriv ner svaret innan du klickar på något, eftersom de två inställningarna inte är utbytbara och ångra tar längre tid än beslutet. Två minuters skrivande sparar en timmes återanslutning.

Vad en lokal brygga gör med adresseringen

En lokal brygga ansluter hubben till en fysisk adapter, så hubben blir en del av det Ethernet-segmentet. Klienterna får adresser från det som redan betjänar segmentet, och deras gateway är segmentets router. Från klientens synvinkel har den gått in i kontorets LAN, med all nåbarhet och all exponering det innebär.

Det betyder också att bryggan behöver en riktig adapter med rätt drivrutinsstöd och att administratören måste vara behörig att utöka segmentet. En VPN-inloggning bevisar autentisering, inte rätten att placera en värd på ett produktions-VLAN. Kontrollera att drivrutinens namn matchar den adapter du avser, eftersom att brygga fel port tar ner ett segment snabbt. Om adapterlistan är tom eller bryggan rapporterar ett fel är svaret vanligtvis kopplat till drivrutin eller behörigheter, inte till kryptografi.

Läs bryggtabellen från kommandoraden när det grafiska trädet är tvetydigt. Utdata namnger adaptern, vilket trädet inte alltid gör.

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

En tom brygglista med anslutna sessioner är en användbar bild: klienterna finns i den virtuella hubben och ingenting utökar den till ett segment ännu.

Vad SecureNAT lägger till och vad det döljer

SecureNAT ger hubben en virtuell router, en NAT-funktion och en DHCP-tjänst, allt inom SoftEther-processen. Klienterna får adresser från det virtuella DHCP-området, den virtuella routern svarar för standardgatewayen, och trafik som måste ut översätts. Ingen fysisk adapter är inblandad, och därför fungerar det på en värd med ett nätverkskort och utan switchkonfiguration.

Priset är att de virtuella adresserna tillhör hubben och ingenting annat. En maskin på kontorets LAN kan inte routa till en klients SecureNAT-adress utan hjälp, och allt som loggar källadresser ser den översatta adressen för SoftEther-värden. Om dina åtkomstregler eller ditt revisionsspår beror på klientens riktiga adress är det en designändring och inte en detalj. Det avgör också om en källadressregel någonsin kommer att se klienten.

Det är också en DHCP-server. Att köra den på ett segment som redan har en, eller att brygga det segmentet samtidigt, ger två svarare och oförutsägbara leasingavtal. Handboken behandlar de två funktionerna som separata val just av den anledningen.

Undersök vad hubben betjänar just nu innan du aktiverar något annat. Varje kommando skriver ut aktuellt tillstånd, inte det avsedda.

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

Slå på en utan att förstöra den andra

Välj arrangemanget, aktivera det och låt det andra vara av. En hubb med både brygga och SecureNAT aktiv är en hubb med två möjliga svar på samma fråga, och klienten kommer att tro på det som kommer först. När du migrerar från den ena till den andra, inaktivera den gamla funktionen och återanslut klienten i stället för att anta att den nya inställningen gäller en befintlig session.

Ordna ändringen så att klientpoolen inte överlappar LAN-området. Överlappande subnät är den näst vanligaste orsaken till en tunnel som ansluter och sedan inte når något, och de är osynliga tills du jämför båda adressplanerna sida vid sida.

Återanslut sedan från klienten och läs vad den fick, eftersom hubbens bild av sessionen inte är klientens bild av sitt eget nätverk. En återanslutning är det enda tillförlitliga sättet att tvinga fram ett nytt leasingavtal.

Kontrollera gatewayen och resolvern på klienten

En lyckad autentisering säger att inloggningsuppgifterna fungerar och att hubben accepterade sessionen. Den säger ingenting om huruvida klienten når något, eftersom det beror på adressen, masken, gatewayen och DNS-servern som den fick. Läs dessa fyra värden på klienten innan du rör en serverinställning igen.

I Windows visar adapterinformationen leasingavtalet och resolvern, och routingtabellen visar om tunneln verkligen är standardvägen.

ipconfig /all
route print -4
nslookup intranet.corp.internal

På en Linux-klient kommer samma information från filerna för adresser, rutter och resolver. Standardrutten är det värde som avgör om trafiken överhuvudtaget går ut genom tunneln. Om gatewayen pekar på kontorets router medan tunneln förväntar sig att bära trafiken, är topologin bryggad till namnet och bruten i praktiken. Åtgärda adresskällan först, testa applikationen igen och överväg först därefter att ändra det andra läget.