SoftEther di Belakang NAT: Traversal Langsung atau Relay VPN Azure?

Server SoftEther Anda berada di belakang router penyedia yang tidak bisa Anda ubah, dan klien tetap terhubung, jadi Anda menganggap relay membawa semuanya. Apakah itu benar bergantung pada mekanisme mana yang melakukan pekerjaan: nama DNS, jalur UDP terkoordinasi, atau terowongan keluar ke relay. Ketiganya dapat menghasilkan klien terhubung, dan gagal dalam kondisi berbeda. Putuskan jalur mana yang Anda beli sebelum menyentuh pengguna atau hub.

Tiga mekanisme, tiga janji berbeda

DNS dinamis adalah penamaan. Ia menjaga nama host tetap mengarah ke alamat yang berubah agar orang berhenti mengejar nomor, dan tidak melakukan hal lain. Traversal NAT asli adalah koordinasi: dua titik akhir SoftEther bertukar informasi dan mencoba membuka jalur UDP yang dapat dipakai melalui perangkat penerjemah di antara keduanya. VPN Azure adalah relay: server menghubungi layanan ke luar, dan klien datang melalui nama host di infrastruktur relay.

Ketiganya saling melengkapi, bukan versi dari satu fitur. Suatu penerapan dapat memakai penamaan sementara koneksinya sebenarnya bergantung pada traversal atau pada relay.

Putuskan dari klien dan jaringan

Pilihan dimulai dari klien, karena traversal hanya ada di mekanisme koneksi asli SoftEther. OpenVPN, L2TP/IPsec, dan pendengar SSTP di server yang sama tidak mewarisinya, meskipun berbagi host. Lihat apa yang akan dijalankan pengguna, lalu apa yang diizinkan jaringan. Jaringan korporat yang hanya mengizinkan TCP 443 mendorong Anda ke relay pada port itu, sedangkan jaringan yang meneruskan port UDP yang dibutuhkan traversal dapat mencoba jalur langsung; pastikan keduanya terhadap kebijakan keluar yang sebenarnya.

Pendengar yang dapat dijangkau secara manual tetap merupakan rancangan yang sah ketika administrator dapat menerbitkannya, tetapi itu proyek terpisah dengan pengalamatan dan pekerjaan firewall sendiri.

Pastikan transport mana yang dipilih sesi

Status koneksi adalah satu-satunya sumber jujur untuk jalur yang dipakai. Bacalah di server, dan selesaikan nama host 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 terhubung, dan SessionGet pada salah satunya melaporkan jenis koneksi, termasuk apakah sesi tiba melalui relay. Catatan yang mengarah ke infrastruktur relay memberi tahu Anda bahwa sesi melewati pihak ketiga, yang dapat Anda pastikan dengan memblokir rute itu dalam pengujian. Dengan klien asli, akselerasi UDP dapat memindahkan jalur data menjauh dari jalur kendali, sehingga satu pengamatan tidak menggambarkan seluruh sesi. Nama DNS dinamis yang kedaluwarsa setelah perubahan alamat, dan relay yang menjawab sementara rute backend hilang, adalah dua mode kegagalan yang layak diuji terpisah. Catat apa yang Anda ukur, bukan apa yang dimaksudkan rancangan.

Rencanakan apa yang menjadi sandaran jalur yang dipilih

Setiap jalur membawa ketergantungan. Traversal langsung dapat berubah setelah transisi jaringan atau perangkat penerjemah baru, sedangkan sesi relay gagal ketika layanan atau port yang dapat dijangkau gagal. Sambungkan ulang dari jaringan lain dan pastikan identitas server yang diverifikasi klien, sambil mempertahankan jalur yang sebelumnya berfungsi dalam pengujian yang sama. Lalu uji sumber daya privat di belakang VPN, karena otorisasi, keanggotaan hub, penetapan alamat, dan rute balik tetap menjadi tanggung jawab Anda dalam hal apa pun.

Catat nama host, protokol, pengaturan fitur, dan transport yang diamati. Catatan empat bagian itulah yang memungkinkan orang berikutnya mereproduksi koneksi yang berfungsi.