Kontena Docker Tidak Boleh Dicapai melalui VPN? Bandingkan Subnet

Kontena menjawab di LAN pejabat, kemudian berhenti menjawab pada saat VPN syarikat bersambung. Tiada apa-apa dalam kontena berubah: tiada permulaan semula, tiada kemas kini imej, tiada suntingan konfigurasi. Yang berubah ialah jadual penghalaan hos, di mana laluan yang ditambah oleh terowong kini meliputi alamat yang diberikan oleh Docker. Sebelum anda menyunting subnet atau meminta pengecualian VPN, letakkan kedua-dua pelan alamat bersebelahan, kerana setiap pembaikan mengambil masa yang sangat berbeza.

Baca laluan sebelum anda menukar konfigurasi

Mulakan dengan rangkaian yang benar-benar dibina oleh Docker. Blok IPAM ialah pelan alamat, dan subnet ialah baris yang penting:

docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]

Compose memperuntukkan /16 untuk setiap projek baharu secara lalai, jadi dua perkhidmatan boleh berada dalam julat 65,536 alamat. Keluasan inilah sebabnya pertindihan biasa berlaku: /16 yang dipilih secara rawak cukup besar untuk menelan tapak yang anda capai melalui terowong, dan tiada siapa menyedarinya sehingga terowong dihidupkan.

Kemudian bandingkan pemilihan laluan untuk satu alamat kontena, sekali dengan terowong dimatikan dan sekali dengan ia dihidupkan:

ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1

Dua bentuk jawapan membawa ke tempat yang berbeza. Jika output menamakan tun0, wg0 atau peranti terowong lain, awalan VPN sekurang-kurangnya sama spesifik dengan laluan jambatan dan paket itu tidak pernah sampai ke kontena. Jika ia masih menamakan jambatan, hos boleh mencapai kontena, dan kesalahan anda ialah penapisan, DNS, atau laluan balik yang gagal dalam satu arah sahaja.

Mengapa perlanggaran /16 mudah berlaku

Docker mengambil rangkaian jambatan daripada kumpulan peribadi, dan kumpulan lalai datang daripada blok 172.16.0.0/12 dalam kepingan /16. Rangkaian korporat sering menggunakan ruang peribadi yang sama, dan VPN akses jauh menolak awalan itu kepada setiap klien yang bersambung. Apabila kedua-dua pihak percaya mereka memiliki 172.18.0.0/16, satu jadual penghalaan memegang dua dakwaan yang bercanggah.

Panjang awalan menentukan pemenang, bukan susunan laluan. Terowong yang menolak 10.0.0.0/8 tidak mengalahkan laluan jambatan 172.18.0.0/16, kerana /8 kurang spesifik. Terowong yang menolak 172.18.0.0/16, atau 172.18.5.0/24 di dalamnya, mengalahkannya. Itulah sebabnya satu komputer riba berfungsi di rangkaian pejabat dan gagal di Wi-Fi hotel dengan VPN yang sama: klien menerima awalan yang berbeza.

Jadual yang sama mengawal arah yang bertentangan. Kontena yang memerlukan hos dalaman pada 10.8.4.20 menghantar paket ke get laluan jambatannya, dan hos kemudian menghalakannya ke dalam terowong. Laluan itu biasanya berfungsi kerana hos melakukan NAT, tetapi ia gagal apabila pihak korporat hanya menerima alamat VPN komputer riba, atau apabila penapisan laluan songsang menggugurkan balasan asimetri.

Bandingkan tiga pembaikan

Hanya ada tiga jalan keluar, dan ia berbeza dari segi siapa yang mesti meluluskannya dan apa yang rosak semasa anda melaksanakannya.

Penomboran semula ialah satu-satunya pembaikan yang boleh diselesaikan tanpa tiket, sebab itu kebanyakan tulisan berhenti di situ. Ia murah pada projek baharu dan mahal apabila alat migrasi atau rentetan sambungan tersimpan menunjuk kepada alamat literal. Kira rujukan itu sebelum anda menyunting YAML, bukan selepasnya.

Pengecualian daripada terowong ialah jawapan paling bersih apabila pertindihan berada dalam julat yang benar-benar dimiliki syarikat anda. Ia juga paling lambat, dan tidak berguna kepada kontraktor yang tidak boleh menukar profil klien. Port yang diterbitkan atau proksi songsang kecil mengelakkan perdebatan: klien bercakap dengan alamat yang sudah dihalakan dengan betul oleh terowong, dan hanya port itu perlu boleh dicapai.

Tetapkan julat dengan sengaja

Untuk satu projek, isytiharkan subnet dalam fail compose supaya projek berhenti mengambil daripada kumpulan kongsi:

networks:
  default:
    ipam:
      config:
        - subnet: 10.201.7.0/24

Ambil julat itu daripada daftar yang diselenggara pasukan anda, bukan daripada contoh yang anda jumpa semasa mencari. Semak ia terhadap awalan yang ditolak VPN, LAN rumah tempat orang bekerja, dan rangkaian kontena lain pada hos yang sama. Kemudian rancang penciptaan semula, kerana rangkaian sedia ada mengekalkan subnet lamanya: docker compose down, kemudian up -d. docker network rm enggan semasa titik akhir masih terpasang, dan mana-mana entri ipv4_address dalam fail mesti berada dalam julat baharu.

Untuk rangkaian yang dicipta Docker sendiri, tetapkan kumpulan daemon dalam /etc/docker/daemon.json:

{
  "default-address-pools": [
    { "base": "10.201.0.0/16", "size": 24 },
    { "base": "10.202.0.0/16", "size": 24 }
  ]
}

Kumpulan itu terpakai kepada rangkaian yang dicipta selepas daemon dimulakan semula, dan jambatan yang sudah wujud mengekalkan alamatnya. Itu mudah dan senang dilupakan, jadi anggap projek lama masih bertindih sehingga seseorang mencipta semula rangkaiannya. dokumentasi rangkaian enjin Docker menerangkan peraturan peruntukan jika anda perlu mempertahankan kumpulan itu semasa semakan.

Jambatan Linux dan Docker Desktop gagal secara berbeza

Pada hos Linux, kontena duduk di atas jambatan dalam ruang nama hos. Satu jadual menentukan segala-galanya, jadi perbandingan di atas ialah keseluruhan cerita: baca laluan jambatan, baca laluan terowong, dan lihat mana yang menang untuk alamat kontena sebenar.

Docker Desktop meletakkan kontena di belakang VM dengan NAT sendiri. Hos tidak mempunyai laluan langsung ke alamat kontena; ia mencapai perkhidmatan melalui port yang diterbitkan, biasanya terikat pada 127.0.0.1. Oleh itu klien VPN boleh merosakkan perkhidmatan tanpa sebarang pertindihan subnet, sama ada dengan memasang laluan untuk julat dalaman VM atau dengan menyekat trafik gelung balik semasa terowong bersambung. Jika ip route get pada hos melaporkan tiada laluan untuk alamat kontena, itu dijangka dan bukan pepijat.

Kesan praktikalnya ialah di mana anda melihat dahulu. Pada Linux, mulakan dengan jadual penghalaan. Pada Desktop, mulakan dengan port yang diterbitkan dan peraturan tembok api klien VPN, kemudian semak sama ada subnet dalaman VM berlanggar dengan sesuatu yang ditolak terowong.

Sahkan dengan terowong dihidupkan

Sambung semula VPN dua kali sebelum anda menganggapnya selesai, kerana profil yang menolak laluan semasa bersambung dan menariknya semula semasa terputus boleh kelihatan betul selepas percubaan pertama. Kemudian jalankan pemeriksaan yang sebenarnya dijalankan oleh klien:

1. ip route get daripada hos, menggunakan alamat sebenar kontena.
2. Permintaan daripada kontena lain, untuk membuktikan perkhidmatan itu sendiri sihat.
3. curl -sv http://127.0.0.1:8080/ daripada klien dengan terowong dihidupkan, kemudian traceroute -n ke alamat kontena daripada mesin di LAN.
4. sysctl net.ipv4.conf.all.rp_filter jika permintaan sampai ke hos tetapi balasannya hilang.

Akhir sekali, tulis julat yang dipilih ke dalam daftar yang sama yang anda gunakan untuk memilihnya, dengan tarikh dan projek yang memilikinya. Pertindihan seterusnya akan datang daripada projek yang tiada siapa mendokumentasikannya, dan satu-satunya pertahanan ialah julat itu ditempah dengan sengaja dan bukan diambil secara rawak.