SoftEther efter NAT: direkte trochgong of VPN Azure-relay?

Jo SoftEther-tsjinner stiet efter in router fan de provider dy't jo net feroarje kinne, en kliïnten meitsje noch altyd ferbining, dat jo nimme oan dat in relay alles draacht. Oft dat wier is, hinget ôf fan hokker meganisme it wurk dien hat: in DNS-namme, in koördinearre UDP-paad of in útgeande tunnel nei in relay. Alle trije kinne in ferbûne kliïnt leverje, en se mislearje ûnder ferskillende omstannichheden. Beslis hokker paad jo keapje foardat jo brûkers of hubs oanreitsje.

Trije meganismen, trije ferskillende beloften

Dynamyske DNS is neamen. It hâldt in hostnamme rjochte op in feroarjend adres sadat minsken ophâlde mei it nûmer efternei te rinnen, en it docht neat oars. Natyf NAT-trochgong is koördinaasje: twa SoftEther-einpunten wikselje ynformaasje út en besykje in brûkber UDP-paad troch de oersetapparaten tusken har te iepenjen. VPN Azure is in relay: de tsjinner skillet út nei de tsjinst, en kliïnten komme troch in hostnamme op 'e ynfrastruktuer fan 'e relay.

De trije binne oanfoljend ynstee fan ferzjes fan ien funksje. In útrulling kin neamen brûke wylst syn ferbining eins ôfhinget fan 'e trochgong of fan 'e relay.

Beslis fan 'e kliïnt en it netwurk út

De kar begjint by de kliïnt, want trochgong bestiet allinnich yn it nativen SoftEther-ferbiningsmeganisme. OpenVPN, L2TP/IPsec en SSTP-harkers op deselde tsjinner ervje it net, ek al diele se in host. Sjoch wat de brûker rinne sil, en dan wat it netwurk talit. In korporatyf netwurk dat allinnich TCP 443 talit, triuwt jo nei in relay op dat port, wylst in netwurk dat de UDP-porten trochlit dy't trochgong nedich hat, in direkte paad besykje kin; befêstigje beide tsjin it werklike útgongbelied.

In hânmjittich berikbere harker is noch altyd in legitime ûntwerp as in administrator ien publisearje kin, mar it is in apart projekt mei eigen adressearring en firewall-wurk.

Befêstigje hokker ferfier de sesje keas

Ferbiningstatus is de iennige earlike boarne foar it paad yn gebrûk. Lês it op 'e tsjinner, en los de hostnamme op dy't de kliïnt krige.

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

SessionList lit sjen hokker sesjes ferbûn binne, en SessionGet op ien fan har rapportearret it ferbiningstype, ynklusyf oft de sesje troch de relay kaam. In record dat nei relay-ynfrastruktuer oplost, fertelt jo dat de sesje troch in tredde partij giet, wat jo befêstigje kinne troch dy rûte yn in test te blokkearjen. Mei in nativen kliïnt kin UDP-fersnelling it gegevenspaad fan it kontrôlepaad wei bewege, dat ien waarnimming beskriuwt net de hiele sesje. In ferâldere dynamyske DNS-namme nei in adresferoaring, en in relay dy't antwurdet wylst de backend-rûte ûntbrekt, binne twa mislearringsmodi dy't apart testen wurde moatte. Skriuw op wat jo metten hawwe, net wat it ûntwerp bedoelde.

Plan foar wat it keazen paad fan ôfhinget

Elk paad draacht in ôfhinklikens. In direkte trochgong kin feroarje nei in netwurkoergong of in nij oersetapparaat, wylst in relaysesje mislearret as de tsjinst of syn berikbere port mislearret. Ferbynje opnij fan in oar netwurk en befêstigje de tsjinneridentiteit dy't de kliïnt ferifiearre, en hâld it earder wurkjende paad yn deselde test. Test dan de privee-resource efter de VPN, want autorisaasje, hub-lidmaatskip, adrestawizing en weromrûtes bliuwe yn elk gefal jo ferantwurdlikens.

Skriuw de hostnamme, it protokol, de funksje-ynstellingen en it waarnommen ferfier op. Krekt dat fjouwerdielige record lit de folgjende persoan in wurkjende ferbining reprodusearje.