Publikasi port Docker dan sumber VPN: dua kecocokan yang Anda lewatkan

Aturan itu menyuruh mengizinkan alamat server VPN ke layanan yang dipublikasikan, dan koneksi tetap putus. Hasil seperti itu lazim, dan itu bukan bug Docker. Dua kecocokan terpisah salah: sumber yang Anda tulis mungkin bukan sumber yang diterima host, dan port yang Anda tulis mungkin bukan port yang dilihat filter. Memperbaiki keduanya menuntut melihat jalur paket, bukan diagram layanan.

Mitos: izinkan server VPN dan selesai

VPN yang dirutekan dapat mempertahankan alamat tunnel klien sampai ke host Docker. Gateway yang melakukan terjemahan sumber dapat mengganti alamat itu dengan alamatnya sendiri. Kedua rancangan sah, dan keduanya menghasilkan sumber berbeda untuk tindakan pengguna yang sama.

Jadi frasa IP server VPN menggambarkan asumsi, bukan pengamatan. Sampai Anda tahu mana dari dua rancangan itu yang ada di depan Anda, aturan itu hanya dugaan.

Sumber: kumpulan klien atau gateway yang diterjemahkan

Periksa empat hal secara berurutan. Pertama, kumpulan alamat klien, misalnya 10.90.0.0/24. Kedua, apakah gateway menerjemahkan kumpulan itu sebelum mencapai host. Ketiga, sumber yang benar-benar diamati host untuk satu koneksi baru. Keempat, apakah autentikasi aplikasi membedakan pengguna satu per satu, karena alamat terjemahan bersama tidak bisa.

Jika kumpulan itu dipertahankan, aturan yang hanya cocok dengan alamat publik gateway akan melewatkan setiap klien. Jika gateway menerjemahkan dengan sengaja, mengizinkan alamat terjemahan itu memasukkan setiap pengguna di belakangnya, yang mungkin dapat diterima untuk layanan dengan login sendiri dan tidak dapat diterima untuk hal lain.

Port: DNAT mengubah nomor yang Anda cocokkan

Pada publikasi jembatan Linux biasa dengan iptables Docker, pemetaan host dari 8443 ke port kontainer 443 diterjemahkan sebelum filter penerusan berjalan. Paket tiba di filter dengan port tujuan 443. Aturan yang cocok dengan 8443 pada titik itu tidak pernah aktif, walaupun 8443 adalah yang diketik klien.

Port yang dipublikasikan tetap ada di pelacakan koneksi, karena itulah tujuan asli dapat dicocokkan di sana ketika benar-benar dibutuhkan.

Tentukan nomor mana yang menyatakan maksud. Cocokkan port kontainer setelah DNAT ketika aturan melindungi layanan di dalam kontainer. Cocokkan tujuan asli dengan opsi conntrack ketika aturan harus menjelaskan apa yang diminta klien, dan terima biaya pencocokan tambahan serta kehati-hatian urutan aturan yang menyertainya.

Rantai: DOCKER-USER, bukan INPUT

Panduan iptables Docker menempatkan kebijakan penerusan pengguna di rantai DOCKER-USER, yang dievaluasi sebelum aturan penerusan Docker sendiri. Aturan yang disalin dari layanan host ke rantai INPUT menyaring lalu lintas yang ditujukan ke host, bukan lalu lintas yang diteruskan ke kontainer. Kesalahan itu menghasilkan aturan yang tampak benar dan tidak berpengaruh pada jalur kontainer.

Simpan rentang sumber, port tujuan efektif, protokol, dan antarmuka masuk bersama-sama dalam aturan yang sama. Izin hanya berdasarkan sumber untuk setiap tujuan yang diteruskan lebih luas daripada mengizinkan satu layanan yang dipublikasikan.

Verifikasi dengan koneksi baru

Uji kedua arah dengan koneksi baru: satu klien VPN yang diizinkan dan satu sumber yang harus tetap ditolak. Status koneksi yang ada dapat menjaga sesi tetap hidup setelah kebijakan berubah, jadi koneksi lama tidak membuktikan apa pun tentang aturan baru. Lalu periksa jalur balasan, karena kontainer tetap harus merutekan balik ke sumber yang dilihatnya.

Panduan iptables Docker mendokumentasikan urutan rantai dan perilaku terjemahan port di balik pemeriksaan ini. Bacalah sebelum menyalin resep, dan pastikan backend mana yang dipakai Docker yang terpasang, karena backend nftables memadukan kebijakan secara berbeda.