SoftEther di Belakang NAT: Laluan Terus atau Geganti VPN Azure?

Pelayan SoftEther anda berada di belakang penghala penyedia yang tidak boleh anda ubah, dan klien masih bersambung, jadi anda menganggap geganti membawa segala-galanya. Sama ada itu benar bergantung pada mekanisme mana yang melakukan kerja: nama DNS, laluan UDP yang diselaraskan atau terowong keluar ke geganti. Ketiga-tiganya boleh menghasilkan klien bersambung, dan ia gagal dalam keadaan berbeza. Tentukan laluan mana yang anda beli sebelum menyentuh pengguna atau hab.

Tiga mekanisme, tiga janji berbeza

DNS dinamik ialah penamaan. Ia mengekalkan nama hos menghala ke alamat yang berubah supaya orang berhenti mengejar nombor itu, dan tidak melakukan apa-apa lagi. Traversal NAT asli ialah penyelarasan: dua titik akhir SoftEther bertukar maklumat dan cuba membuka laluan UDP yang boleh digunakan melalui peranti terjemahan antara mereka. VPN Azure ialah geganti: pelayan mendail keluar ke perkhidmatan, dan klien tiba melalui nama hos pada infrastruktur geganti.

Ketiga-tiganya saling melengkapi, bukan versi satu ciri. Sesuatu penggunaan boleh memakai penamaan sementara sambungannya sebenarnya bergantung pada traversal atau pada geganti.

Tentukan daripada klien dan rangkaian

Pilihan bermula dengan klien, kerana traversal hanya wujud dalam mekanisme sambungan asli SoftEther. OpenVPN, L2TP/IPsec dan pendengar SSTP pada pelayan yang sama tidak mewarisinya, walaupun berkongsi hos. Lihat apa yang akan dijalankan pengguna, kemudian apa yang dibenarkan rangkaian. Rangkaian korporat yang hanya membenarkan TCP 443 menolak anda ke geganti pada port itu, manakala rangkaian yang meluluskan port UDP yang diperlukan traversal boleh mencuba laluan terus; sahkan kedua-duanya terhadap dasar keluar sebenar.

Pendengar yang boleh dicapai secara manual masih reka bentuk yang sah apabila pentadbir boleh menerbitkan satu, tetapi ia projek berasingan dengan pengalamatan dan kerja tembok api sendiri.

Sahkan pengangkutan mana yang dipilih oleh sesi

Status sambungan ialah satu-satunya sumber jujur bagi laluan yang digunakan. Baca di pelayan, dan selesaikan nama hos yang diterima klien.

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

SessionList menunjukkan sesi mana yang bersambung, dan SessionGet pada salah satunya melaporkan jenis sambungan, termasuk sama ada sesi tiba melalui geganti. Rekod yang menyelesaikan ke infrastruktur geganti memberitahu anda bahawa sesi melalui pihak ketiga, yang boleh anda sahkan dengan menyekat laluan itu dalam ujian. Dengan klien asli, pecutan UDP boleh memindahkan laluan data jauh daripada laluan kawalan, jadi satu pemerhatian tidak menggambarkan keseluruhan sesi. Nama DNS dinamik yang lapuk selepas perubahan alamat, dan geganti yang menjawab sementara laluan backend tiada, ialah dua mod kegagalan yang wajar diuji secara berasingan. Catat apa yang anda ukur, bukan apa yang dimaksudkan oleh reka bentuk.

Rancang apa yang menjadi pergantungan laluan yang dipilih

Setiap laluan membawa pergantungan. Traversal terus boleh berubah selepas peralihan rangkaian atau peranti terjemahan baharu, manakala sesi geganti gagal apabila perkhidmatan atau portnya yang boleh dicapai gagal. Sambung semula dari rangkaian lain dan sahkan identiti pelayan yang disahkan oleh klien, sambil mengekalkan laluan yang berfungsi sebelum ini dalam ujian yang sama. Kemudian uji sumber peribadi di belakang VPN, kerana kebenaran, keahlian hab, peruntukan alamat dan laluan pulang tetap menjadi tanggungjawab anda dalam apa jua keadaan.

Catat nama hos, protokol, tetapan ciri dan pengangkutan yang diperhatikan. Rekod empat bahagian itulah yang membolehkan orang seterusnya menghasilkan semula sambungan yang berfungsi.