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

SoftEther-serveren din står bak en leverandørrutet som du ikke kan endre, og klientene kobler seg fortsatt til, så du antar at et relé bærer alt. Om det er sant avhenger av hvilken mekanisme som gjorde jobben: et DNS-navn, en koordinert UDP-vei eller en utgående tunnel til et relé. Alle tre kan gi en tilkoblet klient, og de feiler under forskjellige forhold. Bestem hvilken vei du kjøper før du rører brukere eller huber.

Tre mekanismer, tre forskjellige løfter

Dynamisk DNS er navngiving. Det holder et vertsnavn rettet mot en adresse som endrer seg, slik at folk slutter å jage nummeret, og det gjør ingenting annet. Innebygd NAT-gjennomtrengning er koordinering: to SoftEther-endepunkter utveksler informasjon og prøver å åpne en brukbar UDP-vei gjennom oversettelsesenhetene mellom dem. VPN Azure er et relé: serveren ringer ut til tjenesten, og klientene kommer gjennom et vertsnavn på reléets infrastruktur.

De tre utfyller hverandre i stedet for å være versjoner av én funksjon. En utrulling kan bruke navngiving mens tilkoblingen faktisk avhenger av gjennomtrengning eller av reléet.

Bestem ut fra klienten og nettverket

Valget starter hos klienten, fordi gjennomtrengning bare finnes i den innebygde SoftEther-tilkoblingsmekanismen. OpenVPN, L2TP/IPsec og SSTP-lyttere på samme server arver den ikke, selv om de deler en vert. Se på hva brukeren skal kjøre, og deretter hva nettverket tillater. Et bedriftsnettverk som bare tillater TCP 443, skyver deg mot et relé på den porten, mens et nettverk som slipper gjennom UDP-portene gjennomtrengning trenger, kan forsøke en direkte vei; bekreft begge mot den faktiske utgående policyen.

En manuelt tilgjengelig lytter er fortsatt et legitimt design når en administrator kan publisere en, men det er et eget prosjekt med egen adressering og brannmurarbeid.

Bekreft hvilken transport økten valgte

Tilkoblingsstatus er den eneste ærlige kilden til veien som brukes. Les den på serveren, og slå opp vertsnavnet klienten fikk.

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

SessionList viser hvilke økter som er tilkoblet, og SessionGet på en av dem rapporterer tilkoblingstypen, inkludert om økten kom gjennom reléet. En oppføring som løses til reléinfrastruktur forteller deg at økten går gjennom en tredjepart, noe du kan bekrefte ved å blokkere den ruten i en test. Med en innebygd klient kan UDP-akselerasjon flytte datastien bort fra kontrollstien, så én observasjon beskriver ikke hele økten. Et utdatert dynamisk DNS-navn etter en adresseendring, og et relé som svarer mens backend-ruten mangler, er to feilmoduser det er verdt å teste hver for seg. Skriv ned det du målte, ikke det designet hadde tenkt.

Planlegg ut fra hva den valgte veien avhenger av

Hver vei bærer en avhengighet. En direkte gjennomtrengning kan endre seg etter en nettverksovergang eller en ny oversettelsesenhet, mens en reléøkt feiler når tjenesten eller dens tilgjengelige port feiler. Koble til på nytt fra et annet nettverk og bekreft serveridentiteten klienten verifiserte, mens du beholder den tidligere fungerende veien i samme test. Test deretter den private ressursen bak VPN-en, fordi autorisasjon, hub-medlemskap, adressetildeling og returruter uansett forblir ditt ansvar.

Skriv ned vertsnavnet, protokollen, funksjonsinnstillingene og den observerte transporten. Nettopp den firedelte registreringen gjør det mulig for neste person å gjenskape en fungerende tilkobling.