DNAT dalam kontena VPN: pemajuan, bukan INPUT
Selepas DNAT, permintaan ke alamat terowong menjadi trafik yang dimajukan. Hadkan peraturan pemajuan, baca rantai Docker dan pilih laluan pulang dengan sengaja.
Permintaan tiba dialamatkan ke IP terowong dan keluar dari kontena yang sama dialamatkan ke perkhidmatan jiran. Antara dua saat itu DNAT menulis semula destinasi, dan paket tidak lagi menjadi input untuk kontena VPN. Kini ia trafik yang dimajukan, dinilai oleh peraturan lain. Peralihan itu menjelaskan mengapa peraturan firewall yang kelihatan betul untuk alamat terowong tidak memberi kesan pada sambungan yang diterjemah.
Ikuti paket selepas terjemahan
Ambil kumpulan klien 10.90.0.0/24 dan alamat terowong 10.90.0.1. Dua kontena berada pada satu jambatan: 192.0.2.2 menjalankan VPN dan 192.0.2.3 menjalankan aplikasi. Klien menyambung ke 10.90.0.1:8080, dan peraturan DNAT dalam ruang nama kontena VPN menulis semula ke alamat dan port sebenar aplikasi. Kemudian laluan menghantar paket merentas jambatan. Alamat itu ilustratif, bukan resipi penggunaan.
Port yang aplikasi benar-benar mendengar mungkin berbeza daripada mana-mana port yang diterbitkan pada hos. Baca pendengar di dalam kontena daripada menganggap kedua-dua nombor sepadan.
Kebenaran terletak pada laluan pemajuan
Kontena VPN memerlukan pemajuan IP dan keputusan pemajuan yang terhad kepada kumpulan klien, alamat aplikasi dan port yang dimaksudkan. Balasan yang terjalin memerlukan kebenarannya sendiri. Peraturan yang sepadan dengan alamat terowong asal tidak akan sepadan selepas DNAT, kerana destinasi sudah berubah. Kebenaran INPUT ialah cangkuk yang salah untuk trafik yang tidak lagi dialamatkan ke hos ini.
Kekalkan skop sempit: satu julat sumber, satu destinasi, satu perkhidmatan. Peraturan pemajuan yang longgar lebih mudah ditulis dan jauh lebih sukar dipertahankan kemudian.
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 kontena anda
Peraturan di dalam ruang nama kontena bukan peraturan hos Docker. Apabila trafik melintas dari antara muka terowong ke jambatan, firewall jambatan pada hos boleh membuat keputusan lain. Dengan backend iptables Docker, rantai pemajuan yang didokumenkan dan titik padanan selepas DNAT ialah tempat keputusan itu muncul.
Rujukan firewall Docker menerangkan rantai itu dan padanan selepas DNAT. Jangan betulkan penerimaan yang hilang dengan mematikan pengurusan firewall Docker atau menjadikan setiap rantai longgar, kerana itu menghapuskan sempadan yang anda cuba gunakan.
Jadikan laluan pulang pilihan yang disengajakan
Jika alamat sumber dikekalkan, aplikasi melihat 10.90.0.x dan mesti menghalakan balasan kembali melalui kontena VPN. Jika tidak, gateway Docker biasa akan menghantarnya ke hos, yang tidak memiliki terowong. Alternatifnya ialah terjemahan sumber yang sempit pada kontena VPN, yang memudahkan balasan tetapi menyembunyikan klien daripada aplikasi. Pilih dengan sengaja dan catat mana yang anda pilih.
Uji sambungan baru yang dibenarkan dari klien biasa, kemudian pastikan port tidak berkaitan kekal tertutup. Apabila paket hilang, periksa ruang nama VPN, ruang nama aplikasi dan log aplikasi itu sendiri. Ping ke gateway jambatan bukan ujian penerimaan untuk perkhidmatan.
Simpan peraturan dalam konfigurasi permulaan kontena yang disokong, kerana suntingan interaktif hilang apabila ia dicipta semula. Penerbitan port hos ialah laluan pendedahan yang berbeza dan tidak diperlukan hanya kerana perkhidmatan boleh dicapai melalui terowong.