SoftEther iza NAT-a: direktno probijanje ili VPN Azure relej?

Dinamički DNS, NAT probijanje i VPN Azure rade različite poslove. Odaberite put prije uređivanja korisnika, zatim potvrdite koji transport sesija zapravo koristi.

Vaš SoftEther server stoji iza provajderovog rutera koji ne možete mijenjati, a klijenti se i dalje spajaju, pa pretpostavljate da relej nosi sve. Da li je to tačno zavisi od toga koji je mehanizam obavio posao: DNS ime, koordinirani UDP put ili izlazni tunel do releja. Sva tri mogu dati povezanog klijenta, a padaju pod različitim uslovima. Odlučite koji put kupujete prije nego dirnete korisnike ili hubove.

Tri mehanizma, tri različita obećanja

Dinamički DNS je imenovanje. On drži ime hosta usmjereno na adresu koja se mijenja da ljudi prestanu juriti broj, i ne radi ništa drugo. Izvorno NAT probijanje je koordinacija: dvije SoftEther krajnje točke razmjenjuju informacije i pokušavaju otvoriti upotrebljiv UDP put kroz uređaje za prevođenje između njih. VPN Azure je relej: server se spaja prema usluzi, a klijenti dolaze kroz ime hosta na infrastrukturi releja.

To troje se dopunjuje, a nisu verzije jedne funkcije. Implementacija može koristiti imenovanje dok njena veza zapravo zavisi od probijanja ili od releja.

Odlučite na osnovu klijenta i mreže

Izbor počinje kod klijenta, jer probijanje postoji samo u izvornom SoftEther mehanizmu veze. OpenVPN, L2TP/IPsec i SSTP slušači na istom serveru ga ne nasljeđuju, iako dijele host. Pogledajte šta će korisnik pokretati, a zatim šta mreža dozvoljava. Korporativna mreža koja dozvoljava samo TCP 443 gura vas ka releju na tom portu, dok mreža koja propušta UDP portove potrebne za probijanje može pokušati direktan put; potvrdite oboje prema stvarnoj politici izlaza.

Ručno dostupan slušač je i dalje legitiman dizajn kada ga administrator može objaviti, ali to je odvojen projekat sa sopstvenim adresiranjem i radom na firewallu.

Potvrdite koji je transport sesija odabrala

Status veze je jedini iskren izvor za put koji se koristi. Pročitajte ga na serveru i razriješite ime hosta koje je klijent dobio.

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

SessionList pokazuje koje su sesije povezane, a SessionGet na jednoj od njih prijavljuje tip veze, uključujući da li je sesija došla kroz relej. Zapis koji se razrješava na infrastrukturu releja govori vam da sesija prolazi kroz treću stranu, što možete potvrditi blokiranjem te rute u testu. Sa izvornim klijentom UDP ubrzanje može pomjeriti putanju podataka od kontrolne putanje, pa jedno opažanje ne opisuje cijelu sesiju. Zastarjelo dinamičko DNS ime nakon promjene adrese i relej koji odgovara dok backend ruta nedostaje dva su načina otkaza koje vrijedi testirati odvojeno. Zapišite ono što ste izmjerili, a ne ono što je dizajn namjeravao.

Planirajte od čega zavisi odabrani put

Svaki put nosi zavisnost. Direktno probijanje može se promijeniti nakon mrežnog prelaza ili novog uređaja za prevođenje, dok relej sesija pada kada padne usluga ili njen dostupan port. Povežite se ponovo sa druge mreže i potvrdite identitet servera koji je klijent provjerio, držeći prethodno radni put u istom testu. Zatim testirajte privatni resurs iza VPN-a, jer autorizacija, članstvo u hubu, dodjela adresa i povratne rute u svakom slučaju ostaju vaša odgovornost.

Zapišite ime hosta, protokol, postavke funkcije i opaženi transport. Taj zapis od četiri dijela je ono što sljedećoj osobi omogućava da reprodukuje radnu vezu.

Povezani članci