Penerbitan Port Docker lawan VPN: Ke Mana Balasan Pergi

Kontena yang diterbitkan membalas dari alamatnya sendiri sebelum NAT songsang. Dua reka bentuk boleh mengekalkan balasan itu di laluan awam, dengan kos berbeza.

Hos terus menjawab SSH selepas VPN terowong penuh aktif, sementara perkhidmatan yang diterbitkan Docker pada mesin yang sama menjadi senyap. Tiada yang salah dengan pendengar: kontena berjalan, pemetaan port wujud, dan paket tiba. Kontena sihat dan permintaan benar-benar mencapainya. Yang berbeza ialah dari mana balasan bermula apabila Linux memilih laluannya, dan perbezaan itu menentukan reka bentuk mana antara dua di bawah yang anda perlukan.

Ikuti tuple melalui NAT destinasi

Ambil hos di 192.0.2.10 yang menerbitkan TCP 2222 ke kontena di 172.30.240.5:22. Permintaan dari 198.51.100.25 diterjemah sebelum mencapai kontena, dan kontena membalas 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 laluan hos, balasan masih membawa alamat sumber kontena. Terjemahan songsang memulihkan tuple yang diterbitkan kemudian, dan itulah sebabnya paket kelihatan salah tepat pada saat laluan dipilih.

Mengapa peraturan khusus hos terlepas pandang

Peraturan yang memilih jadual WAN hanya untuk paket dari 192.0.2.10 meliputi daemon hos itu sendiri dan terlepas balasan yang dimajukan ini sepenuhnya. Alamat sumber pada balasan ialah 172.30.240.5, bukan hos.

Pembetulan berlebihan ialah mengarahkan semua daripada kontena melalui WAN, yang juga mengecualikan sambungan keluar tidak berkaitan kontena daripada VPN. Itu dasar berbeza daripada yang diminta, dan biasanya mengejutkan seseorang kemudian.

Padanan selepas DNAT ialah hook yang berbeza

Dokumentasi Docker tentang tembok api menyatakan bahawa penapisan pengguna biasa melihat destinasi selepas DNAT, jadi memadankan port terbitan 2222 dalam peraturan biasa tidak sama dengan memadankan port kontena 22. Jika tuple asal penting, gunakan mekanisme destinasi asal yang disokong dan bukannya meneka port mana yang kelihatan.

Kekeliruan hook ini menghasilkan peraturan yang kelihatan betul dan tidak pernah padan. Semak pembilang pada peraturan itu sendiri sebelum menulis semula dasar. Peraturan tanpa sebarang hit memberitahu anda ia dinilai di tempat yang tidak pernah dicapai oleh paket.

Reka bentuk A: bawa keputusan sebagai status sambungan

Tanda sambungan boleh membawa keputusan masuk melalui terjemahan, tetapi ia mesti dipulihkan pada paket sebelum carian laluan yang penting. Peringkatnya ialah:

  1. Tempah medan tanda dan keutamaan peraturan yang tidak bertembung dengan Docker, VPN atau pemilik dasar lain.
  2. Kenal pasti hanya sambungan WAN baharu yang dimaksudkan pada titik pra-DNAT di mana penjejakan sambungan tersedia.
  3. Rekod keputusan pada tanda sambungan, tanpa memaksa permintaan asal itu sendiri ke jadual WAN.
  4. Dalam arah balasan, pulihkan hanya bit tanda anda sendiri pada paket sebelum penghalaan.
  5. Pilih jadual WAN lengkap cukup awal supaya peraturan VPN tidak boleh menang dahulu.

Jadual itu memerlukan laluan bersambung sebenar dan get laluan. Ia juga memerlukan tingkah laku yang ditentukan apabila laluan tiada. Jatuh senyap ke dalam terowong ialah hasil terburuk, kerana konfigurasi masih kelihatan berfungsi. Gagal tertutup dan log ia sebagai gantinya.

Reka bentuk B: tamatkan pada hos

Frontend sisi hos yang dikonfigurasikan secara sengaja, seperti proksi TCP atau proksi songsang di hadapan kontena, mengekalkan balasan berasal dari alamat hos. Peraturan yang ditulis untuk hos kemudian berkelakuan seperti dijangka, dan kontena kekal pada rangkaian persendiriannya.

Kosnya ialah satu lagi bahagian bergerak dengan konfigurasi, pengendalian alamat sumber dan kawalan aksesnya sendiri. Ia biasanya sempadan disokong yang lebih mudah, dan selalunya jawapan yang betul apabila dasar penghalaan dikekalkan oleh seorang yang mungkin pergi.

Sahkan perubahan, bukan niat

Buka sambungan dibenarkan yang baharu dari sisi awam dan pastikan balasan keluar melalui antara muka yang dimaksudkan. Kemudian semak bahawa permintaan tidak berkaitan yang dimulakan kontena masih mengikuti VPN.

Jangan siram jadual sambungan mesin untuk menguji satu peraturan: entri sedia ada menyimpan pemetaan terdahulu, dan siraman memecahkan semua yang lain pada hos. Menerbitkan port menentukan ketercapaian. Ia tidak menentukan laluan balasan. Tuliskan reka bentuk yang dipilih dengan nama jadualnya, supaya orang seterusnya tidak perlu menemuinya semula semasa insiden.

Artikel berkaitan