Kontena Windows dan VPN: mengapa rangkaian setempat rosak
Kontena Windows menggunakan jadual laluan hos, jadi VPN yang menyekat subnet setempat turut membawa awalan kontena bersamanya. Mod Linux mengambil laluan lain.
Pada satu komputer riba, dengan satu klien VPN disambungkan, kontena Linux terus bercakap sesama sendiri dan kontena Windows berhenti. Pemboleh ubahnya bukan imej, tetapi laluan yang dilalui paket masuk ke hos. Kontena Windows pada rangkaian lalai meminjam jadual laluan dan terjemahan hos, jadi dasar yang mengubah penghalaan hos turut mengubahnya. Sahkan itu dengan carian laluan sebelum memasang semula apa-apa.
Di mana paket kontena Windows masuk ke hos
Kontena pada rangkaian lalai nat mendapat alamat daripada awalan perkhidmatan Host Networking Service, biasanya di suatu tempat dalam 172.16.0.0/12, dan mencapai hos melalui penyesuai maya. Hos memiliki laluan untuk awalan itu dan menterjemah trafik ke penyesuai yang sedang aktif. Tiada mesin maya berasingan di tengah-tengah laluan itu.
Reka bentuk itulah yang menjadikan kegagalan itu mekanikal. Apabila kontena menghantar paket, hos melakukan carian laluan untuk awalan kontena. Laluan mana yang menang, ke situlah paket pergi, dan kontena tidak mempunyai pendapat tentangnya.
Apa yang diubah oleh klien VPN pada laluan itu
Klien korporat selalunya memasang set laluan yang luas dan penapis yang menafikan akses ke subnet setempat semasa terowong aktif. Niatnya bersifat pertahanan: rangkaian setempat yang terjejas tidak sepatutnya mencapai mesin yang dilindungi. Kesan sampingannya ialah laluan hos ke awalan kontena bukan lagi rangkaian NAT setempat.
Sebaliknya carian itu sepadan dengan terowong dan paket diserahkan kepada gerbang, yang tidak pernah mendengar alamat kontena itu. Ping gagal, aplikasi kehabisan masa, dan kontena kelihatan rosak sementara ikon VPN menyala. Lihat jadual hos semasa disambungkan dan laluan pesaing kelihatan.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
Mengapa kontena Linux berkelakuan berbeza
Enjin Linux menjalankan kontena di dalam mesin maya ringan, dan sambungan keluar daripada mesin itu dibuka oleh proksi di sebelah hos bagi pihak kontena. Hos yang memulakan soket, jadi peraturan VPN tentang awalan kontena tidak terpakai kepadanya dengan cara yang sama, dan beban kerja terus mencapai rangkaian.
Perbezaan itu juga menjelaskan mengapa resipi Linux tidak boleh dipindahkan. Kontena Linux yang memerlukan terowongnya sendiri diberi peranti TUN serta keupayaan NET_ADMIN. Kontena Windows tidak mendedahkan sebarang antara muka sebagai peranti, jadi corak itu tiada persamaan di sebelah itu.
Buktikan laluan itu, kemudian pilih reka bentuk
Kumpulkan bukti daripada hos, bukan daripada kontena, kerana hos yang melakukan carian:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Jalankan keluaran laluan sekali sebelum VPN disambungkan dan sekali selepasnya. Jika pada keluaran kedua awalan kontena menunjuk ke penyesuai terowong, diagnosis selesai dan memulakan semula kontena tidak akan membantu.
Pilihan pertama ialah keputusan dasar: tanya pemilik rangkaian sama ada akses LAN setempat boleh dibenarkan untuk peranti ini. Beberapa klien korporat menyediakannya sebagai tetapan, tetapi ia melemahkan sempadan yang disengajakan. Mintalah sebagai pengecualian berdokumen dengan pemilik dan tarikh semakan. Suis bagi setiap peranti yang tidak pernah disemak semula ialah cara dasar pertahanan hilang secara senyap.
Di tempat dasar mesti bertahan, pindahkan beban kerja dan bukannya bergelut dengan laluan. Rangkaian telus dengan subnet dan gerbang yang jelas meletakkan kontena pada pautan setempat, beban kerja Linux berjalan di belakang proksi mesin maya, dan mesin maya berasingan dengan kliennya sendiri mengekalkan dasarnya sendiri. Pilih satu dengan sengaja dan ujinya dari dalam kontena, kerana di situlah permintaan pengguna bermula.