DNAT di kontainer VPN: penerusan, bukan INPUT

Setelah DNAT, permintaan ke alamat terowongan menjadi lalu lintas yang diteruskan. Batasi aturan penerusan, baca rantai Docker, dan pilih jalur balik dengan sengaja.

Permintaan tiba dengan alamat IP terowongan dan keluar dari kontainer yang sama dengan alamat layanan tetangga. Di antara kedua momen itu DNAT menulis ulang tujuan, dan paket tidak lagi menjadi input bagi kontainer VPN. Kini paket itu lalu lintas yang diteruskan, dinilai oleh aturan lain. Pergeseran itulah yang menjelaskan mengapa aturan firewall yang tampak benar untuk alamat terowongan tidak berpengaruh pada koneksi yang diterjemahkan.

Ikuti paket setelah penerjemahan

Ambil kumpulan klien 10.90.0.0/24 dan alamat terowongan 10.90.0.1. Dua kontainer berada di satu bridge: 192.0.2.2 menjalankan VPN dan 192.0.2.3 menjalankan aplikasi. Sebuah klien terhubung ke 10.90.0.1:8080, dan aturan DNAT di namespace kontainer VPN menulis ulangnya ke alamat dan port asli aplikasi. Sebuah rute lalu mengirim paket melintasi bridge. Alamat-alamat itu hanya ilustrasi, bukan resep penerapan.

Port tempat aplikasi benar-benar mendengarkan bisa berbeda dari port mana pun yang diterbitkan di host. Baca pendengar di dalam kontainer alih-alih menganggap kedua angka itu sama.

Izin berada di jalur penerusan

Kontainer VPN memerlukan penerusan IP dan keputusan penerusan yang dibatasi pada kumpulan klien, alamat aplikasi, dan port yang dimaksud. Balasan yang sudah terjalin memerlukan izinnya sendiri. Aturan yang cocok dengan alamat terowongan asli tidak akan cocok setelah DNAT, karena tujuan sudah berubah. Izin INPUT adalah kait yang salah untuk lalu lintas yang tidak lagi dialamatkan ke host ini.

Jaga cakupan tetap sempit: satu rentang sumber, satu tujuan, satu layanan. Aturan penerusan yang longgar lebih mudah ditulis dan jauh lebih sulit dipertahankan nanti.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Rantai Docker bukan rantai kontainer Anda

Aturan di dalam namespace kontainer bukan aturan host Docker. Saat lalu lintas menyeberang dari antarmuka terowongan ke bridge, firewall bridge pada host dapat mengambil keputusan lain. Dengan backend iptables Docker, rantai penerusan yang didokumentasikan dan titik pencocokan setelah DNAT adalah tempat keputusan itu muncul.

Referensi firewall Docker menjelaskan rantai tersebut dan pencocokan setelah DNAT. Jangan perbaiki penerimaan yang hilang dengan mematikan pengelolaan firewall Docker atau membuat setiap rantai longgar, karena itu menghapus batas yang ingin Anda pakai.

Jadikan jalur balik pilihan yang disengaja

Jika alamat sumber dipertahankan, aplikasi melihat 10.90.0.x dan harus mengarahkan balasan kembali melalui kontainer VPN. Jika tidak, gateway Docker biasanya akan mengirimnya ke host, yang tidak memiliki terowongan. Alternatifnya adalah penerjemahan sumber yang sempit di kontainer VPN, yang menyederhanakan balasan tetapi menyembunyikan klien dari aplikasi. Pilih dengan sengaja dan catat mana yang Anda pilih.

Uji koneksi baru yang diizinkan dari klien biasa, lalu pastikan port yang tidak terkait tetap tertutup. Saat paket menghilang, periksa namespace VPN, namespace aplikasi, dan log aplikasi itu sendiri. Ping ke gateway bridge bukan uji penerimaan layanan.

Simpan aturan dalam konfigurasi startup kontainer yang didukung, karena suntingan interaktif hilang saat kontainer dibuat ulang. Publikasi port host adalah jalur paparan yang berbeda dan tidak diperlukan hanya karena layanan dapat dijangkau melalui terowongan.

Artikel terkait