Mengapa kontena Docker tidak dapat mencapai hos di belakang VPN

Kontena yang tidak dapat mencapai apa-apa di belakang VPN korporat biasanya tinggal dalam ruang nama rangkaian yang berbeza daripada terowong. Laluan, pelayan DNS dan tanda tembok api klien hos milik tindanan hos; kontena rangkaian jambatan mempunyai tindanannya sendiri. Fakta tunggal ini menjelaskan kebanyakan laporan yang sampai kepada pasukan platform, dan ia juga sebab mengapa «VPN rosak» dan «Docker memintas VPN» boleh kedua-duanya salah pada masa yang sama. Dua persediaan yang sangat berbeza bersembunyi di sebalik satu gejala, jadi kenal pasti yang mana anda ada sebelum menukar sebarang tetapan.

Ketahui ruang nama siapa yang memiliki terowong

Pada Docker Desktop untuk macOS atau Windows, kontena berjalan di dalam mesin maya Linux. Klien VPN yang dipasang pada desktop mencipta terowong dalam sistem pengendalian desktop, dan mesin maya tidak pernah melihatnya. Tiada konfigurasi kontena yang membaikinya, kerana antara muka yang diperlukan kontena tidak wujud sama sekali dalam ruang nama rangkaiannya.

Pada hos Linux terowong tinggal dalam ruang nama hos, dan kontena jambatan biasanya mencapainya melalui jadual penghalaan hos dengan NAT sumber dikenakan semasa keluar. Apabila laluan itu gagal, puncanya biasanya dasar pemajuan, penapisan laluan songsang atau subnet bertindih dan bukannya laluan yang hilang. Sahkan di dunia mana anda berada sebelum membaca lebih lanjut:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

Perbezaan antara kedua-dua jadual penghalaan itu ialah keseluruhan masalah pada satu skrin. Jika paparan hos mengandungi antara muka terowong dan paparan jambatan tidak, anda melihat pengasingan ruang nama, dan semua yang lain ialah pilihan tentang cara melintasinya.

Rangkaian hos ialah ujian, bukan reka bentuk

Menjalankan kontena dengan rangkaian hos, yang didokumenkan Docker sebagai berkongsi ruang nama rangkaian hos, membuatnya mewarisi antara muka terowong dan laluannya secara langsung. Jika permintaan yang sama kemudian berjaya, teori laluan disahkan dan kegagalan ialah pengasingan ruang nama, bukan kelayakan, DNS atau peraturan akses.

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

Simpan ia sebagai diagnostik. Rangkaian hos melepaskan penerbitan port dan sebahagian besar pengasingan yang anda mahukan daripada kontena, dan pada Docker Desktop «host» bermaksud mesin maya, bukan desktop, jadi kejayaan atau kegagalan di sana boleh mengelirukan anda jika anda lupa hos mana yang anda tujukan.

Peranti tun dan keistimewaan yang menyertainya

Klien VPN di dalam kontena memerlukan peranti terowong dan kebenaran untuk mengkonfigurasinya. Jalan pintas biasa ialah --privileged, yang memberikan setiap peranti dan melonggarkan dasar keselamatan di seluruh kontena. Itu jauh lebih banyak daripada yang diperlukan tugas ini, dan sukar untuk dijustifikasi dalam semakan.

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

Bentuk yang lebih sempit memetakan satu nod peranti dan hanya menambah keupayaan pentadbiran rangkaian. Muatkan modul pada hos terlebih dahulu supaya nod itu wujud. Jika kontena bermula dan klien melaporkan tidak dapat membuka peranti terowong, semak pemetaan sebelum mengesyaki profil, kerana ralat itu biasanya literal.

Reka bentuk ini juga bermakna klien berjalan bagi setiap kontena. Itu jawapan yang betul apabila setiap beban kerja memerlukan terowongnya sendiri, dan jawapan yang salah apabila anda hanya mahu terowong hos kelihatan, yang mungkin diandaikan pasukan platform sedang anda lakukan.

NAT jambatan mengubah sumber yang dilihat VPN

Dengan jambatan lalai, trafik keluar kontena diterjemahkan kepada alamat hos. Oleh itu di belakang VPN pihak korporat melihat alamat terowong hos dan bukan alamat kontena, peraturan akses mengikut sumber berkelakuan seolah-olah hos yang menghantar permintaan, dan dua kontena menjadi tidak dapat dibezakan kepada pelayan VPN.

macvlan atau ipvlan memberikan kontena alamat LAN sebagai gantinya, yang membantu penemuan LAN dan membuat kontena kelihatan seperti rakan setara pada segmen. Ia juga memintas terowong hos sepenuhnya, jadi kontena sebegitu tidak akan mencapai awalan khusus-VPN melainkan VPN juga boleh dicapai dari LAN itu.

Kedua-dua bentuk adalah sah; ia menjawab keperluan yang berbeza. Jika keperluannya ialah «kontena ini mesti mencapai perkhidmatan khusus-VPN», anda memilih antara penghalaan melalui hos dan menamatkan terowong di dalam kontena. Tuliskan pilihan itu sebelum penggunaan, bukan selepas permintaan pertama yang gagal. Apa pun yang anda pilih, catat alamat sumber yang akan dilihat hujung jauh, kerana itulah yang akan ditunjukkan oleh peraturan akses dan lognya. Reka bentuk yang tidak dapat menyatakan alamat itu belum siap.

DNS mengikut daemon, bukan terowong

Kontena mendapat konfigurasi penyelesai apabila bermula, disalin daripada daemon atau daripada imej. Alamat yang ditolak VPN selepas bersambung tiba terlalu lewat untuk salinan itu, dan ia ditolak ke penyelesai hos dan bukan ke dalam kontena.

Tetapkan penyelesai secara eksplisit untuk perkhidmatan itu, atau halakan ia ke penyelesai dalaman yang boleh dicapai melalui terowong. Kontena yang menyelesaikan nama peribadi kepada alamat awam biasanya menggunakan penyelesai awam, bukan menderita laluan rosak, dan pembetulannya terletak dalam fail compose atau konfigurasi daemon.

Penaakulan yang sama terpakai kepada persoalan alamat keluar. Jika setiap kontena mesti muncul dari alamat VPN yang berbeza, satu terowong hos tidak dapat menyediakannya kerana NAT meruntuhkan semuanya menjadi satu sumber. Bentuk yang boleh dilaksanakan ialah klien dalam ruang nama setiap kontena atau sidecar yang memiliki terowong dan berkongsi tindanannya, dan kedua-duanya mengubah cara aplikasi dialamatkan.

Senarai semak sebelum menutup tiket: kenal pasti ruang nama yang memiliki terowong, buktikan laluan dengan rangkaian hos, petakan hanya peranti tun yang diperlukan, ingat alamat sumber selepas NAT, tetapkan penyelesai secara eksplisit dan layan alamat keluar bagi setiap kontena sebagai keputusan seni bina dan bukan bendera.