VPN di Router atau Penerusan Port: Mana yang Menang?

Router sendiri yang mengakhiri VPN, dan aturan penerusan lama masih mengirim port UDP yang sama ke sebuah mesin di LAN. Hanya salah satunya yang bisa menjadi titik akhir sebenarnya, dan kernel tidak memutuskan di antara keduanya. Penerjemahan tujuan menulis ulang paket sebelum layanan lokal dikonsultasikan, sehingga proses VPN menunggu lalu lintas yang sudah dikirim ke tempat lain. Tugasnya adalah memutuskan siapa yang memiliki port, lalu menyelaraskan aturannya.

Satu port, dua pemilik yang diklaim

Server VPN yang berjalan di dalam router membutuhkan izin masuk yang menuju soketnya sendiri. Entri NAT tujuan untuk port yang sama menuju ke tempat yang sama sekali berbeda: alamat LAN dan keputusan penerusan. Keduanya titik akhir berbeda dengan log berbeda dan mode kegagalan berbeda. Petunjuk yang biasa adalah satu keluarga alamat berfungsi dan yang lain tidak, karena entri sisa ditulis untuk satu keluarga dan tidak pernah ditinjau lagi.

Catat klaimnya sebelum mengedit: keluarga, alamat eksternal, transportasi, port, dan target terjemahan.

Penerjemahan berjalan sebelum pemeriksaan lokal

NAT tujuan mengubah target paket pada tahap pra-routing, sebelum kernel memilih antara pengiriman lokal dan penerusan. Begitu targetnya menjadi host LAN, paket menempuh jalur penerusan. Aturan masukan untuk soket router sendiri tidak pernah diperiksa, itulah sebabnya log VPN tetap kosong sementara klien kehabisan waktu.

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 seluruh mekanismenya, dan antarmuka perangkat menyembunyikannya di balik kotak centang tanpa mengubahnya. Pemilik tujuan tetap menentukan jalur yang diambil paket.

Jika host LAN adalah titik akhir yang dimaksud, penerusan itu benar dan router tidak boleh juga mendengarkan di port itu.

Pertahankan satu pemetaan dan hapus yang lain

Daftarkan entri NAT untuk port dan keluarga itu lalu pilih yang bertahan:

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

Entri TCP dengan nomor yang sama tidak relevan untuk kegagalan UDP, dan memperlakukannya sebagai satu objek membuat aturan yang salah terhapus. Ketika soket lokal seharusnya menang, pemilik pemetaan yang bertabrakan menghapus atau menulis ulang entri itu, dan izin masuk untuk port router sendiri tetap di tempatnya. Penerusan yang tidak terkait, jalur manajemen, dan salinan kumpulan aturan semuanya harus bertahan dari perubahan.

Jika VPN hidup di host terpisah, penerusan adalah objek yang tepat. Layanan dalam kontainer atau mesin virtual mungkin memerlukan port yang dipublikasikan bahkan ketika kotaknya disebut router, jadi telusuri soket dan ruang namanya, bukan label pada kotaknya.

Pastikan pemiliknya dari luar

Uji setiap keluarga secara terpisah, karena koneksi IPv6 yang berakhir di router tidak mengatakan apa pun tentang koneksi IPv4 yang dialihkan oleh aturan usang. Baca log layanan penerima untuk melihat titik akhir mana yang menjawab, dan anggap pesan sukses klien sebagai bukti lemah. Diperlukan aliran baru untuk pengujian yang bermakna. Kirim probe dari host luar dengan nc -zvu 203.0.113.7 1194 dan baca log pemenang dengan journalctl -u openvpn@server -n 20. Pendengar router mencatat koneksi itu sendiri, sedangkan host LAN mencatatnya di layanannya sendiri.

Pelacakan koneksi mempertahankan aliran yang ada pada pemetaan aslinya, sehingga sesi yang sudah terbentuk bisa hidup lebih lama daripada aturan yang baru saja Anda perbaiki.

Setelah titik akhir yang dimaksud menjawab dengan pemeriksaan identitas normalnya, uji sumber daya privat di balik terowongan. Mencapai pendengar luar hanyalah lompatan pertama; perutean dalam dan otorisasi aplikasi adalah hasil terpisah.