SoftEther NAT:n takana: suora läpäisy vai VPN Azure -rele?

Dynaaminen DNS, NAT-läpäisy ja VPN Azure tekevät eri töitä. Valitse polku ennen käyttäjien muokkaamista ja varmista sitten, mitä siirtotietä istunto todella käyttää.

SoftEther-palvelimesi on palveluntarjoajan reitittimen takana, jota et voi muuttaa, ja asiakkaat yhdistävät silti, joten oletat releen kantavan kaiken. Onko se totta, riippuu siitä, mikä mekanismi teki työn: DNS-nimi, koordinoitu UDP-polku vai lähtevä tunneli releeseen. Kaikki kolme voivat tuottaa yhdistetyn asiakkaan, ja ne epäonnistuvat eri olosuhteissa. Päätä, minkä polun ostat, ennen kuin kosket käyttäjiin tai keskuksiin.

Kolme mekanismia, kolme erilaista lupausta

Dynaaminen DNS on nimeämistä. Se pitää isäntänimen osoitettuna muuttuvaan osoitteeseen, jotta ihmiset lopettavat numeron perässä juoksemisen, eikä tee muuta. Natiivi NAT-läpäisy on koordinointia: kaksi SoftEther-päätepistettä vaihtavat tietoja ja yrittävät avata käyttökelpoisen UDP-polun niiden välissä olevien käännöslaitteiden läpi. VPN Azure on rele: palvelin soittaa ulos palveluun, ja asiakkaat saapuvat releen infrastruktuurissa olevan isäntänimen kautta.

Kolme täydentävät toisiaan eivätkä ole yhden ominaisuuden versioita. Käyttöönotto voi käyttää nimeämistä, vaikka sen yhteys todella riippuu läpäisystä tai releestä.

Päätä asiakkaan ja verkon perusteella

Valinta alkaa asiakkaasta, koska läpäisy on olemassa vain natiivissa SoftEther-yhteysmekanismissa. OpenVPN, L2TP/IPsec ja SSTP-kuuntelijat samassa palvelimessa eivät peri sitä, vaikka jakavat isännän. Katso, mitä käyttäjä ajaa, ja sitten, mitä verkko sallii. Yritysverkko, joka sallii vain TCP 443:n, työntää sinut releeseen sillä portilla, kun taas verkko, joka päästää läpi läpäisyn tarvitsemat UDP-portit, voi yrittää suoraa polkua; varmista molemmat todellista lähtevän liikenteen käytäntöä vasten.

Käsin saavutettava kuuntelija on edelleen kelvollinen suunnittelu, kun ylläpitäjä voi julkaista sellaisen, mutta se on erillinen projekti, jolla on oma osoitteistus ja palomuurityö.

Varmista, minkä siirtotien istunto valitsi

Yhteyden tila on ainoa rehellinen lähde käytössä olevalle polulle. Lue se palvelimella ja selvitä isäntänimi, jonka asiakas sai.

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

SessionList näyttää, mitkä istunnot ovat yhteydessä, ja SessionGet yhdessä niistä ilmoittaa yhteyden tyypin, mukaan lukien sen, tuliko istunto releen kautta. Releen infrastruktuuriin selviävä tietue kertoo, että istunto kulkee kolmannen osapuolen kautta, minkä voit varmistaa estämällä kyseisen reitin testissä. Natiivilla asiakkaalla UDP-kiihdytys voi siirtää datapolun pois ohjauspolulta, joten yksi havainto ei kuvaa koko istuntoa. Vanhentunut dynaaminen DNS-nimi osoitteen muutoksen jälkeen ja rele, joka vastaa, kun taustapolku puuttuu, ovat kaksi vikatilaa, jotka kannattaa testata erikseen. Kirjaa se, mitä mittasit, älä sitä, mitä suunnittelu tarkoitti.

Suunnittele sen mukaan, mistä valittu polku riippuu

Jokainen polku kantaa riippuvuuden. Suora läpäisy voi muuttua verkkosiirtymän tai uuden käännöslaitteen jälkeen, kun taas releistunto epäonnistuu, kun palvelu tai sen saavutettava portti epäonnistuu. Yhdistä uudelleen toisesta verkosta ja varmista palvelimen identiteetti, jonka asiakas vahvisti, pitäen aiemmin toimineen polun samassa testissä. Testaa sitten VPN:n takana oleva yksityinen resurssi, sillä valtuutus, keskusjäsenyys, osoitteiden jakaminen ja paluureitit jäävät joka tapauksessa vastuullenne.

Kirjaa isäntänimi, protokolla, ominaisuuden asetukset ja havaittu siirtotie. Juuri tämä neliosainen tietue mahdollistaa sen, että seuraava henkilö voi toistaa toimivan yhteyden.

Aiheeseen liittyvät artikkelit