Publikasi Port Docker versus VPN: Ke Mana Balasan Pergi

Kontainer yang dipublikasikan membalas dari alamatnya sendiri sebelum NAT terbalik. Dua desain dapat menjaga balasan itu di jalur publik, dengan biaya berbeda.

Host tetap menjawab SSH setelah VPN tunnel penuh aktif, sementara layanan yang dipublikasikan Docker di mesin yang sama menjadi diam. Tidak ada yang salah dengan listener: kontainer berjalan, pemetaan port ada, dan paket tiba. Kontainer sehat dan permintaan memang mencapainya. Yang berbeda adalah dari mana balasan dimulai saat Linux memilih rutenya, dan perbedaan itu menentukan desain mana dari dua di bawah ini yang Anda butuhkan.

Ikuti tuple melalui NAT tujuan

Ambil sebuah host di 192.0.2.10 yang memublikasikan TCP 2222 ke kontainer di 172.30.240.5:22. Permintaan dari 198.51.100.25 diterjemahkan sebelum mencapai kontainer, dan kontainer menjawab sebagai dirinya sendiri.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

Pada keputusan rute host, balasan masih membawa alamat sumber kontainer. Penerjemahan balik memulihkan tuple yang dipublikasikan nanti, dan itulah sebabnya paket terlihat salah tepat pada saat rute dipilih.

Mengapa aturan khusus host melewatkannya

Aturan yang memilih tabel WAN hanya untuk paket dari 192.0.2.10 mencakup daemon host sendiri dan melewatkan balasan yang diteruskan ini sepenuhnya. Alamat sumber pada balasan adalah 172.30.240.5, bukan host.

Koreksi berlebihan adalah merutekan semua dari kontainer melalui WAN, yang juga membebaskan koneksi keluar tak terkait milik kontainer dari VPN. Itu kebijakan berbeda dari yang diminta, dan biasanya mengejutkan seseorang nanti.

Pencocokan pasca-DNAT adalah hook yang berbeda

Dokumentasi Docker tentang firewall mencatat bahwa penyaringan pengguna biasa melihat tujuan pasca-DNAT, jadi mencocokkan port 2222 yang dipublikasikan dalam aturan normal tidak sama dengan mencocokkan port kontainer 22. Jika tuple asli penting, gunakan mekanisme tujuan asli yang didukung alih-alih menebak port mana yang terlihat.

Kebingungan hook ini menghasilkan aturan yang tampak benar dan tidak pernah cocok. Periksa penghitung pada aturannya sendiri sebelum menulis ulang kebijakan. Aturan tanpa satu pun kecocokan memberi tahu Anda bahwa ia dievaluasi di tempat yang tidak pernah dicapai paket.

Desain A: bawa keputusan sebagai status koneksi

Tanda koneksi dapat membawa keputusan masuk melintasi penerjemahan, tetapi harus dipulihkan ke paket sebelum pencarian rute yang penting. Tahapannya adalah:

  1. Pesan bidang tanda dan prioritas aturan yang tidak bertabrakan dengan Docker, VPN, atau pemilik kebijakan lain.
  2. Identifikasi hanya koneksi WAN baru yang dimaksud pada titik pra-DNAT tempat pelacakan koneksi tersedia.
  3. Catat keputusan pada tanda koneksi, tanpa memaksa permintaan aslinya sendiri ke tabel WAN.
  4. Pada arah balasan, pulihkan hanya bit tanda Anda sendiri ke paket sebelum perutean.
  5. Pilih tabel WAN lengkap cukup dini sehingga aturan VPN tidak bisa menang lebih dulu.

Tabel itu memerlukan rute terhubung yang nyata dan gateway. Tabel itu juga memerlukan perilaku yang terdefinisi saat rute tidak ada. Jatuh diam-diam ke dalam tunnel adalah hasil terburuk, karena konfigurasinya masih tampak berfungsi. Gagal tertutup dan catat sebagai gantinya.

Desain B: akhiri di host

Frontend yang dikonfigurasi dengan sengaja di sisi host, seperti proxy TCP atau proxy terbalik di depan kontainer, menjaga balasan tetap berasal dari alamat host. Aturan yang ditulis untuk host kemudian berperilaku seperti yang diharapkan, dan kontainer tetap di jaringan privatnya.

Biayanya adalah satu lagi bagian bergerak dengan konfigurasi, penanganan alamat sumber, dan kontrol aksesnya sendiri. Biasanya ini batas yang didukung dan lebih sederhana, dan sering kali jawaban yang tepat ketika kebijakan perutean akan dipelihara oleh satu orang yang mungkin pergi.

Verifikasi perubahannya, bukan niatnya

Buka koneksi resmi baru dari sisi publik dan pastikan balasan keluar melalui antarmuka yang dimaksud. Lalu periksa bahwa permintaan tak terkait yang dimulai kontainer masih mengikuti VPN.

Jangan bersihkan tabel koneksi mesin untuk menguji satu aturan: entri yang ada menyimpan pemetaan sebelumnya, dan pembersihan merusak semua hal lain di host. Memublikasikan port menentukan keterjangkauan. Itu tidak menentukan jalur balasan. Tuliskan desain yang dipilih dengan nama tabelnya, supaya orang berikutnya tidak menemukannya lagi saat insiden.

Artikel terkait