VPN pada Penghala atau Penghantaran Port: Mana yang Menang?

Router menamatkan VPN itu sendiri, dan peraturan penghantaran lama masih menghantar port UDP yang sama kepada mesin di LAN. Hanya satu daripadanya boleh menjadi titik akhir sebenar, dan kernel tidak mengadili antara keduanya. Terjemahan destinasi menulis semula paket sebelum perkhidmatan tempatan dirujuk, jadi proses VPN menunggu trafik yang telah dihantar ke tempat lain. Tugasnya ialah memutuskan siapa memiliki port itu, kemudian menyelaraskan peraturannya.

Satu port, dua pemilik yang dituntut

Pelayan VPN yang berjalan di dalam router memerlukan kebenaran masuk yang menuju ke soketnya sendiri. Entri NAT destinasi untuk port yang sama menuju ke tempat yang sama sekali berbeza: alamat LAN dan keputusan penghantaran. Kedua-duanya titik akhir berbeza dengan log berbeza dan mod kegagalan berbeza. Petunjuk biasa ialah satu keluarga alamat berfungsi dan yang lain tidak, kerana entri yang tinggal ditulis untuk satu keluarga sahaja dan tidak pernah disemak semula.

Catat tuntutan sebelum mengedit: keluarga, alamat luaran, pengangkutan, port dan sasaran terjemahan.

Terjemahan berjalan sebelum semakan tempatan

NAT destinasi mengubah sasaran paket pada peringkat pra-penghalaan, sebelum kernel memilih antara penghantaran tempatan dan penghantaran ke hadapan. Sebaik sahaja sasaran menjadi hos LAN, paket mengambil laluan penghantaran. Peraturan input untuk soket router sendiri tidak pernah dirujuk, itulah sebabnya log VPN kekal kosong sementara klien menunggu sehingga tamat masa.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Urutan itulah keseluruhan mekanisme, dan antara muka peranti menyembunyikannya di belakang kotak semak tanpa mengubahnya. Pemilik destinasi masih menentukan laluan yang diambil oleh paket.

Jika hos LAN ialah titik akhir yang dimaksudkan, penghantaran itu betul dan router tidak sepatutnya turut mendengar pada port itu.

Kekalkan satu pemetaan dan buang yang satu lagi

Senaraikan entri NAT untuk port dan keluarga itu dan pilih yang terselamat:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Entri TCP dengan nombor yang sama tidak relevan kepada kegagalan UDP, dan memperlakukannya sebagai satu objek menyebabkan peraturan yang salah dipadam. Apabila soket tempatan sepatutnya menang, pemilik pemetaan yang bercanggah membuang atau menulis semula entri itu, dan kebenaran masuk untuk port router sendiri kekal di tempatnya. Penghantaran yang tidak berkaitan, laluan pengurusan dan salinan set peraturan semuanya harus bertahan daripada perubahan itu.

Jika VPN tinggal pada hos berasingan, penghantaran ialah objek yang betul. Perkhidmatan dalam kontena atau mesin maya mungkin memerlukan port yang diterbitkan walaupun kotak itu dipanggil router, jadi jejaki soket dan ruang namanya, bukan label pada kotak itu.

Sahkan pemilik dari luar

Uji setiap keluarga secara berasingan, kerana sambungan IPv6 yang berakhir pada router tidak mengatakan apa-apa tentang sambungan IPv4 yang dialihkan oleh peraturan lapuk. Baca log perkhidmatan penerima untuk melihat titik akhir mana yang menjawab, dan anggap mesej kejayaan klien sebagai bukti lemah. Aliran baharu diperlukan untuk ujian yang bermakna. Hantar prob dari hos luar dengan nc -zvu 203.0.113.7 1194 dan baca log pemenang dengan journalctl -u openvpn@server -n 20. Pendengar router mencatat sambungan itu sendiri, manakala hos LAN mencatatnya dalam perkhidmatannya sendiri.

Penjejakan sambungan mengekalkan aliran sedia ada pada pemetaan asalnya, jadi sesi yang telah terbentuk boleh hidup lebih lama daripada peraturan yang baru anda betulkan.

Setelah titik akhir yang dimaksudkan menjawab dengan pemeriksaan identitinya yang biasa, uji sumber peribadi di belakang terowong. Mencapai pendengar luar hanyalah lompatan pertama; penghalaan dalaman dan kebenaran aplikasi ialah hasil yang berasingan.