SoftEther bag NAT: direkte gennemtrængning eller VPN Azure-relay?

Din SoftEther-server står bag en udbyderrouter, du ikke kan ændre, og klienterne opretter stadig forbindelse, så du antager, at en relay bærer det hele. Om det er sandt, afhænger af, hvilken mekanisme der gjorde arbejdet: et DNS-navn, en koordineret UDP-vej eller en udgående tunnel til en relay. Alle tre kan give en tilsluttet klient, og de fejler under forskellige forhold. Beslut, hvilken vej du køber, før du rører brugere eller hubs.

Tre mekanismer, tre forskellige løfter

Dynamisk DNS er navngivning. Det holder et værtsnavn rettet mod en skiftende adresse, så folk holder op med at jage nummeret, og det gør intet andet. Indbygget NAT-gennemtrængning er koordinering: to SoftEther-endepunkter udveksler oplysninger og prøver at åbne en brugbar UDP-vej gennem oversættelsesenhederne mellem dem. VPN Azure er en relay: serveren ringer ud til tjenesten, og klienter ankommer gennem et værtsnavn på relayens infrastruktur.

De tre er komplementære snarere end versioner af én funktion. En udrulning kan bruge navngivning, mens dens forbindelse faktisk afhænger af gennemtrængning eller af relayen.

Beslut ud fra klienten og netværket

Valget starter ved klienten, fordi gennemtrængning kun findes i den indbyggede SoftEther-forbindelsesmekanisme. OpenVPN, L2TP/IPsec og SSTP-lyttere på samme server arver den ikke, selv om de deler en vært. Se på, hvad brugeren vil køre, og derefter på, hvad netværket tillader. Et virksomhedsnetværk, der kun tillader TCP 443, skubber dig mod en relay på den port, mens et netværk, der slipper de UDP-porte igennem, som gennemtrængning kræver, kan forsøge en direkte vej; bekræft begge mod den faktiske udgående politik.

En lytter, der kan nås manuelt, er stadig et legitimt design, når en administrator kan offentliggøre en, men det er et separat projekt med sin egen adressering og firewall-arbejde.

Bekræft, hvilken transport sessionen valgte

Forbindelsesstatus er den eneste ærlige kilde til den vej, der bruges. Læs den på serveren, og slå det værtsnavn op, klienten fik.

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

SessionList viser, hvilke sessioner der er tilsluttet, og SessionGet på en af dem rapporterer forbindelsestypen, herunder om sessionen kom gennem relayen. En post, der opløses til relayinfrastruktur, fortæller dig, at sessionen går gennem en tredjepart, hvilket du kan bekræfte ved at blokere den rute i en test. Med en indbygget klient kan UDP-acceleration flytte datastien væk fra kontrolstien, så én observation beskriver ikke hele sessionen. Et forældet dynamisk DNS-navn efter en adresseændring, og en relay der svarer, mens backend-ruten mangler, er to fejltilstande, der er værd at teste hver for sig. Skriv ned, hvad du målte, i stedet for hvad designet havde tænkt.

Planlæg ud fra, hvad den valgte vej afhænger af

Hver vej bærer en afhængighed. En direkte gennemtrængning kan ændre sig efter en netværksovergang eller en ny oversættelsesenhed, mens en relaysession fejler, når tjenesten eller dens tilgængelige port fejler. Genopret forbindelsen fra et andet netværk, og bekræft den serveridentitet, klienten verificerede, mens du beholder den tidligere fungerende vej i samme test. Test derefter den private ressource bag VPN'en, fordi autorisation, hub-medlemskab, adressetildeling og returruter under alle omstændigheder forbliver dit ansvar.

Skriv værtsnavnet, protokollen, funktionsindstillingerne og den observerede transport ned. Netop den firedelte registrering gør det muligt for den næste person at genskabe en fungerende forbindelse.