Penerbitan port Docker dan sumber VPN: dua padanan yang anda terlepas

Peraturan itu menyatakan benarkan alamat pelayan VPN ke perkhidmatan yang diterbitkan, namun sambungan masih terputus. Hasil itu biasa, dan ia bukan pepijat Docker. Dua padanan berasingan adalah salah: sumber yang anda tulis mungkin bukan sumber yang diterima hos, dan port yang anda tulis mungkin bukan port yang dilihat penapis. Membetulkan kedua-duanya memerlukan pemerhatian laluan paket, bukan rajah perkhidmatan.

Mitos: benarkan pelayan VPN dan selesai

VPN yang dihalakan boleh mengekalkan alamat terowong klien sehingga ke hos Docker. Get laluan yang melakukan terjemahan sumber boleh menggantikan alamat itu dengan alamatnya sendiri. Kedua-dua reka bentuk sah, dan ia menghasilkan sumber berbeza untuk tindakan pengguna yang sama.

Jadi frasa IP pelayan VPN menerangkan andaian, bukan pemerhatian. Sehingga anda tahu yang mana antara dua reka bentuk itu ada di hadapan anda, peraturan itu ialah tekaan.

Sumber: kolam klien atau get laluan yang diterjemah

Semak empat perkara mengikut urutan. Pertama, kolam alamat klien, contohnya 10.90.0.0/24. Kedua, sama ada get laluan menterjemah kolam itu sebelum ia sampai ke hos. Ketiga, sumber yang benar-benar diperhatikan hos untuk satu sambungan baharu. Keempat, sama ada pengesahan aplikasi membezakan pengguna individu, kerana alamat terjemahan berkongsi tidak boleh berbuat demikian.

Jika kolam itu dikekalkan, peraturan yang hanya sepadan dengan alamat awam get laluan akan terlepas setiap klien. Jika get laluan sengaja menterjemah, membenarkan alamat terjemahan itu memasukkan setiap pengguna di belakangnya, yang mungkin boleh diterima untuk perkhidmatan dengan log masuk sendiri dan tidak boleh diterima untuk apa-apa yang lain.

Port: DNAT menukar nombor yang anda padankan

Dalam penerbitan jambatan Linux biasa dengan iptables Docker, pemetaan hos daripada 8443 ke port kontena 443 diterjemah sebelum penapis penghantaran berjalan. Paket tiba di penapis dengan port destinasi 443. Peraturan yang sepadan dengan 8443 pada titik itu tidak pernah tercetus, walaupun 8443 ialah apa yang ditaip klien.

Port yang diterbitkan masih wujud dalam penjejakan sambungan, sebab itulah destinasi asal boleh dipadankan di sana apabila benar-benar diperlukan.

Tentukan nombor mana yang menyatakan niat. Padankan port kontena selepas DNAT apabila peraturan melindungi perkhidmatan di dalam kontena. Padankan destinasi asal dengan pilihan conntrack apabila peraturan mesti menerangkan apa yang diminta klien, dan terima kos padanan tambahan serta kehati-hatian susunan peraturan yang menyertainya.

Rantaian: DOCKER-USER, bukan INPUT

Panduan iptables Docker meletakkan dasar penghantaran pengguna dalam rantaian DOCKER-USER, yang dinilai sebelum peraturan penghantaran Docker sendiri. Peraturan yang disalin daripada perkhidmatan hos ke rantaian INPUT menapis trafik yang dialamatkan kepada hos, bukan trafik yang dihantar ke kontena. Kesilapan itu menghasilkan peraturan yang kelihatan betul dan tidak memberi kesan pada laluan kontena.

Simpan julat sumber, port destinasi berkesan, protokol dan antara muka masuk bersama-sama dalam peraturan yang sama. Kebenaran berdasarkan sumber sahaja untuk setiap destinasi yang dihantar adalah lebih luas daripada membenarkan satu perkhidmatan yang diterbitkan.

Sahkan dengan sambungan baharu

Uji kedua-dua arah dengan sambungan baharu: satu klien VPN yang dibenarkan dan satu sumber yang sepatutnya kekal ditolak. Keadaan sambungan sedia ada boleh mengekalkan sesi hidup selepas dasar berubah, jadi sambungan lama tidak membuktikan apa-apa tentang peraturan baharu. Kemudian semak laluan balasan, kerana kontena masih perlu menghalakan semula ke sumber yang dilihatnya.

Panduan iptables Docker mendokumenkan susunan rantaian dan tingkah laku terjemahan port di sebalik semakan ini. Bacalah sebelum menyalin resipi, dan pastikan backend mana yang digunakan Docker yang dipasang, kerana backend nftables menyepadukan dasar secara berbeza.