SoftEther pas NAT: kalim i drejtpërdrejtë apo rele VPN Azure?

Serveri juaj SoftEther qëndron pas një ruteri të ofruesit që nuk mund ta ndryshoni, dhe klientët ende lidhen, kështu që supozoni se një rele mban gjithçka. Nëse kjo është e vërtetë varet nga cili mekanizëm e bëri punën: një emër DNS, një rrugë UDP e koordinuar apo një tunel dalës drejt një releje. Të tre mund të prodhojnë një klient të lidhur, dhe dështojnë në kushte të ndryshme. Vendosni cilën rrugë po blini përpara se të prekni përdorues ose hub-e.

Tre mekanizma, tre premtime të ndryshme

DNS dinamik është emërtim. Mban një emër hosti të drejtuar drejt një adrese që ndryshon, që njerëzit të ndalojnë së ndjekuri numrin, dhe nuk bën asgjë tjetër. Kalimi autokton NAT është koordinim: dy pika fundore SoftEther shkëmbejnë informacion dhe përpiqen të hapin një rrugë UDP të përdorshme përmes pajisjeve të përkthimit midis tyre. VPN Azure është një rele: serveri lidhet nga jashtë me shërbimin, dhe klientët mbërrijnë përmes një emri hosti në infrastrukturën e relesë.

Të tre janë plotësues, jo versione të një funksioni të vetëm. Një vendosje mund të përdorë emërtimin, ndërsa lidhja e saj në fakt varet nga kalimi ose nga releja.

Vendosni nga klienti dhe rrjeti

Zgjedhja fillon me klientin, sepse kalimi ekziston vetëm në mekanizmin autokton të lidhjes SoftEther. OpenVPN, L2TP/IPsec dhe dëgjuesit SSTP në të njëjtin server nuk e trashëgojnë atë, edhe pse ndajnë një host. Shikoni çfarë do të ekzekutojë përdoruesi, më pas çfarë lejon rrjeti. Një rrjet korporativ që lejon vetëm TCP 443 ju shtyn drejt një releje në atë portë, ndërsa një rrjet që lë të kalojnë portat UDP që kalimi ka nevojë mund të provojë një rrugë të drejtpërdrejtë; konfirmoni të dyja kundrejt politikës reale të daljes.

Një dëgjues i arritshëm me dorë mbetet një dizajn legjitim kur një administrator mund të publikojë një të tillë, por është një projekt i veçantë me adresimin dhe punën e vet të murit të zjarrit.

Konfirmoni cilin transport zgjodhi sesioni

Statusi i lidhjes është burimi i vetëm i ndershëm për rrugën në përdorim. Lexojeni në server, dhe zgjidhni emrin e hostit që mori klienti.

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

SessionList tregon cilat sesione janë të lidhura, dhe SessionGet në njërin prej tyre raporton llojin e lidhjes, përfshirë nëse sesioni mbërriti përmes relesë. Një regjistrim që zgjidhet në infrastrukturën e relesë ju thotë se sesioni kalon përmes një pale të tretë, të cilin mund ta konfirmoni duke bllokuar atë rrugë në një provë. Me një klient autokton, përshpejtimi UDP mund ta largojë rrugën e të dhënave nga rruga e kontrollit, kështu që një vëzhgim nuk e përshkruan të gjithë sesionin. Një emër DNS dinamik i vjetëruar pas një ndryshimi adrese, dhe një rele që përgjigjet ndërsa mungon rruga drejt backend-it, janë dy mënyra dështimi që meritojnë provë të veçantë. Shkruani atë që matët, jo atë që synonte dizajni.

Planifikoni nga se varet rruga e zgjedhur

Çdo rrugë mbart një varësi. Një kalim i drejtpërdrejtë mund të ndryshojë pas një tranzicioni rrjeti ose një pajisjeje të re përkthimi, ndërsa një sesion rele dështon kur dështon shërbimi ose porta e tij e arritshme. Rilidhuni nga një rrjet tjetër dhe konfirmoni identitetin e serverit që verifikoi klienti, duke e mbajtur rrugën që funksiononte më parë në të njëjtën provë. Më pas provoni burimin privat pas VPN-së, sepse autorizimi, anëtarësimi në hub, caktimi i adresave dhe rrugët e kthimit mbeten përgjegjësia juaj në çdo rast.

Shkruani emrin e hostit, protokollin, cilësimet e funksionit dhe transportin e vëzhguar. Pikërisht ai regjistrim me katër pjesë u mundëson personit të ardhshëm të riprodhojë një lidhje që funksionon.