SoftEther în spatele NAT: traversare directă sau releu VPN Azure?

DNS dinamic, traversarea NAT și VPN Azure fac lucruri diferite. Alegeți calea înainte de a edita utilizatori, apoi confirmați ce transport folosește de fapt sesiunea.

Serverul SoftEther stă în spatele unui router al furnizorului pe care nu îl puteți schimba, iar clienții se conectează în continuare, așa că presupuneți că un releu transportă totul. Dacă acest lucru este adevărat depinde de mecanismul care a făcut treaba: un nume DNS, o cale UDP coordonată sau un tunel de ieșire către un releu. Toate trei pot produce un client conectat și eșuează în condiții diferite. Decideți ce cale cumpărați înainte de a atinge utilizatori sau huburi.

Trei mecanisme, trei promisiuni diferite

DNS dinamic este denumire. Menține un nume de gazdă îndreptat către o adresă care se schimbă pentru ca oamenii să nu mai alerge după număr, și nu face altceva. Traversarea NAT nativă este coordonare: două capete SoftEther schimbă informații și încearcă să deschidă o cale UDP utilizabilă prin dispozitivele de traducere dintre ele. VPN Azure este un releu: serverul se conectează în exterior la serviciu, iar clienții sosesc printr-un nume de gazdă în infrastructura releului.

Cele trei se completează, nu sunt versiuni ale unei singure funcții. O implementare poate folosi denumirea în timp ce conexiunea ei depinde de fapt de traversare sau de releu.

Decideți după client și după rețea

Alegerea începe cu clientul, pentru că traversarea există doar în mecanismul nativ de conectare SoftEther. OpenVPN, L2TP/IPsec și ascultătorii SSTP de pe același server nu o moștenesc, deși împart o gazdă. Uitați-vă la ce va rula utilizatorul, apoi la ce permite rețeaua. O rețea corporativă care permite doar TCP 443 vă împinge spre un releu pe acel port, în timp ce o rețea care lasă să treacă porturile UDP necesare traversării poate încerca o cale directă; confirmați ambele față de politica reală de ieșire.

Un ascultător accesibil manual rămâne un design legitim când un administrator poate publica unul, dar este un proiect separat cu adresarea și munca de firewall proprii.

Confirmați ce transport a ales sesiunea

Starea conexiunii este singura sursă onestă a căii folosite. Citiți-o pe server și rezolvați numele de gazdă primit de client.

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

SessionList arată ce sesiuni sunt conectate, iar SessionGet pe una dintre ele raportează tipul conexiunii, inclusiv dacă sesiunea a sosit prin releu. O înregistrare care se rezolvă către infrastructura releului vă spune că sesiunea trece prin terți, ceea ce puteți confirma blocând acea rută într-un test. Cu un client nativ, accelerarea UDP poate muta calea datelor departe de calea de control, așa că o singură observație nu descrie întreaga sesiune. Un nume DNS dinamic învechit după o schimbare de adresă și un releu care răspunde în timp ce lipsește ruta către backend sunt două moduri de eșec care merită testate separat. Notați ce ați măsurat, nu ce intenționa designul.

Planificați de ce depinde calea aleasă

Fiecare cale poartă o dependență. O traversare directă se poate schimba după o tranziție de rețea sau un dispozitiv de traducere nou, în timp ce o sesiune de releu eșuează când eșuează serviciul sau portul său accesibil. Reconectați-vă dintr-o altă rețea și confirmați identitatea serverului verificată de client, păstrând calea care funcționa anterior în același test. Apoi testați resursa privată din spatele VPN-ului, pentru că autorizarea, apartenența la hub, alocarea adreselor și rutele de întoarcere rămân responsabilitatea dumneavoastră în orice caz.

Notați numele de gazdă, protocolul, setările funcției și transportul observat. Exact acea înregistrare în patru părți îi permite următoarei persoane să reproducă o conexiune funcțională.

Articole similare