SoftEther SecureNAT: DHCP dan NAT adalah dua keputusan
SecureNAT menjalankan DHCP virtual dan NAT virtual, dan masing-masing bisa gagal sendiri. Periksa sewa, lalu jalur keluar dan resolver, sebelum menyalahkan hub.
SecureNAT adalah satu kotak centang yang menyalakan dua layanan, dan dari situlah sebagian besar kebingungan tentangnya berasal. Server DHCP virtual memberi klien alamat, mask, gateway, dan sering kali resolver. NAT virtual meneruskan paket melewati gateway itu menggunakan tumpukan jaringan host server sendiri. Keduanya berdampingan dalam konfigurasi dan gagal secara terpisah: klien bisa memiliki sewa yang sempurna tanpa jalur yang berfungsi, atau jalur yang berfungsi dengan pengaturan yang menunjuk ke resolver yang salah. Periksa keduanya sebagai dua keputusan, dan diagnosisnya menjadi singkat.
Dua layanan di balik satu kotak centang
Sisi DHCP virtual menjawab pertanyaan konfigurasi: pengaturan apa yang diterima klien ini di dalam hub virtual ini. Sisi NAT virtual menjawab pertanyaan penerusan: ketika klien mengirim paket ke alamat di luar hub, apakah server menerjemahkan dan meneruskannya. Yang pertama bersifat lokal bagi hub dan tidak memerlukan jaringan di atasnya. Yang kedua sepenuhnya bergantung pada host.
Antarmuka host virtual termasuk keputusan pertama, bukan yang kedua. Alamatnya, sering kali sesuatu seperti 192.168.30.1 secara bawaan, adalah gateway yang ditawarkan layanan DHCP. Itu bukan alamat pendengar publik server, dan mencampuradukkan keduanya menghasilkan aturan firewall dan pengaturan klien yang mengarah ke mesin yang tidak ada di jaringan itu.
Keputusan 1: siapa yang memasok alamat
Jika DHCP virtual diaktifkan, klien seharusnya menerima sewa di kumpulan yang Anda konfigurasi, dengan antarmuka host virtual sebagai gateway dan resolver yang Anda sediakan. Periksa sewanya, bukan teks status klien, karena «terhubung» menggambarkan terowongan dan bukan penetapan alamat:
vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route
Ada dua mode kegagalan yang perlu diketahui sebelum Anda men-debug hal lain. Klien dengan alamat statis sisa dari rancangan sebelumnya akan mempertahankannya dan mengabaikan sewa, yang tampak seperti DHCP menolak menjawab. Dan sumber DHCP kedua pada segmen yang dijembatani akan bersaing untuk klien yang sama, yang menghasilkan alamat yang kadang muncul kadang tidak serta antrean dukungan yang tidak dapat mereproduksi masalahnya.
Kumpulan yang tumpang tindih juga termasuk di sini. Jika kumpulan DHCP virtual tumpang tindih dengan subnet LAN host atau kumpulan hub lain, klien mendapat alamat yang dirutekan secara ambigu, dan setiap pengujian berikutnya tidak meyakinkan.
Keputusan 2: siapa yang meneruskan melewati gateway virtual
Dengan NAT virtual aktif, lalu lintas keluar dari hub diterjemahkan oleh server dan dikirim melalui tabel perutean host. Artinya rantai penerusan adalah: klien ke gateway virtual, NAT virtual ke tumpukan host, tumpukan host ke rute bawaannya. Setiap mata rantai bisa gagal tanpa menyentuh yang lain, dan tanda kegagalannya berbeda.
Uji keputusan kedua dengan sesuatu yang harus meninggalkan hub, bukan dengan sesuatu yang lokal di dalamnya. Melakukan ping ke gateway virtual membuktikan mata rantai pertama dan tidak lebih:
vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10
Jika resolusi nama berfungsi tetapi koneksi ke alamat publik gagal, Anda berada di rantai penerusan, bukan di DHCP. Jika keduanya gagal, periksa resolver lebih dulu, karena resolver yang didorong sebagai alamat internal yang tak terjangkau akan membuat jalur yang berfungsi tampak benar-benar rusak.
Penerusan SecureNAT diimplementasikan oleh proses server, bukan oleh jalur penerusan kernel yang akan Anda gunakan dengan jembatan. Itu nyaman dan lebih lambat daripada menjembatani, dan itu juga berarti aturan firewall serta keputusan perutean host tetap berlaku pada lalu lintas yang diterjemahkan. NAT virtual tidak memotong kebijakan host; ia menggunakannya.
Jalur host itu sendiri adalah hal ketiga
Semua di atas mengandaikan host server dapat mencapai tujuan. Host tanpa rute hulu yang berfungsi, dengan kebijakan keluar yang ketat, atau dengan keluarga alamat yang tidak dimilikinya akan gagal pada keputusan kedua, sekalipun konfigurasi hub benar. Periksa host itu sendiri, di luar terowongan, sebelum menyatakan kegagalannya sebagai kesalahan SoftEther.
SecureNAT juga bukan otorisasi untuk mencapai setiap jaringan yang terhubung ke server. Ia menerjemahkan dan meneruskan lalu lintas yang sampai kepadanya; memutuskan apa yang boleh dicapai host tetap tugas firewall dan perutean host, dan rancangan yang mengandalkan terowongan untuk memberi akses hanya berjarak satu aturan buruk dari memberi terlalu banyak.
Keluarga alamat layak mendapat pemeriksaannya sendiri. Contoh DHCP IPv4 yang berfungsi tidak membuktikan bahwa setiap kemampuan IPv6 ada dalam build Anda, jadi bacalah manual untuk versi yang benar-benar Anda jalankan sebelum menjanjikan perilaku tumpukan ganda. Bagian SecureNAT dalam manual mencakup fungsi NAT dan DHCP virtual untuk rilis saat ini.
Periksa setiap keputusan dengan ujinya sendiri
Terima keputusan pertama dengan pemeriksaan sewa: alamat di dalam kumpulan, gateway sama dengan antarmuka host virtual, resolver yang Anda konfigurasi. Terima yang kedua dengan permintaan keluar dari klien plus melihat tabel NAT di server, karena jumlah sesi yang naik adalah satu-satunya bukti langsung bahwa penerjemahan terjadi, bukan sekadar diaktifkan.
Lalu catat pemisahan itu dalam catatan rancangan: komponen mana yang memasok alamat, komponen mana yang meneruskan, dan antarmuka host mana yang dilalui lalu lintas keluar. Ketika mulai ulang mengubah perilaku, catatan itu memberi tahu Anda mana dari ketiganya yang harus diperiksa alih-alih memulai ulang semuanya dan berharap gejalanya berpindah.
Satu keputusan lagi termasuk dalam catatan, meskipun Anda tidak mengambilnya hari ini: SecureNAT dan jembatan lokal adalah rancangan berbeda untuk hub yang sama, dan hub yang membutuhkan keduanya adalah hub yang membutuhkan rencana lain. Pilih dengan sadar, tuliskan alasannya, dan orang berikutnya tidak perlu merekayasa balik dari konfigurasi yang berjalan.