Kontainer Windows dan VPN: mengapa jaringan lokal rusak
Kontainer Windows memakai tabel rute host, jadi VPN yang memblokir subnet lokal ikut membawa prefiks kontainer. Mode Linux menempuh jalur lain.
Pada satu laptop, dengan satu klien VPN terhubung, kontainer Linux terus saling berbicara sementara kontainer Windows berhenti. Variabelnya bukan image, melainkan jalur yang dilalui paket masuk ke host. Kontainer Windows di jaringan default meminjam tabel rute dan terjemahan host, sehingga kebijakan yang mengubah perutean host juga mengubahnya. Pastikan itu dengan pencarian rute sebelum memasang ulang apa pun.
Dari mana paket kontainer Windows masuk ke host
Kontainer di jaringan default nat mendapat alamat dari prefiks layanan Host Networking Service, biasanya di suatu tempat dalam 172.16.0.0/12, dan mencapai host melalui adaptor virtual. Host memiliki rute untuk prefiks itu dan menerjemahkan lalu lintas ke adaptor yang sedang aktif. Tidak ada mesin virtual terpisah di tengah jalur tersebut.
Desain itulah yang membuat kegagalannya mekanis. Saat kontainer mengirim paket, host melakukan pencarian rute untuk prefiks kontainer. Rute mana pun yang menang, ke sanalah paket pergi, dan kontainer tidak punya pendapat soal itu.
Apa yang diubah klien VPN pada jalur itu
Klien korporat sering memasang banyak rute dan filter yang menolak akses ke subnet lokal selama terowongan aktif. Niatnya bersifat bertahan: jaringan lokal yang disusupi tidak boleh mencapai mesin yang dilindungi. Efek sampingnya adalah rute host ke prefiks kontainer bukan lagi jaringan NAT lokal.
Sebagai gantinya, pencarian cocok dengan terowongan dan paket diserahkan ke gateway, yang tidak pernah mendengar alamat kontainer itu. Ping gagal, aplikasi kehabisan waktu, dan kontainer tampak rusak sementara ikon VPN menyala. Lihat tabel host saat terhubung dan rute pesaingnya terlihat.
| 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 kontainer Linux berperilaku berbeda
Mesin Linux menjalankan kontainer di dalam mesin virtual ringan, dan koneksi keluar dari mesin itu dibuka oleh proksi di sisi host atas nama kontainer. Host yang memulai soket, jadi aturan VPN tentang prefiks kontainer tidak berlaku padanya dengan cara yang sama, dan beban kerja tetap mencapai jaringan.
Perbedaan itu juga menjelaskan mengapa resep Linux tidak bisa dipindahkan. Kontainer Linux yang butuh terowongannya sendiri diberi perangkat TUN plus kemampuan NET_ADMIN. Kontainer Windows tidak mengekspos antarmuka apa pun sebagai perangkat, jadi pola itu tidak punya padanan di sisi itu.
Buktikan rutenya, lalu pilih desain
Kumpulkan bukti dari host, bukan dari kontainer, karena host yang melakukan pencarian:
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 rute sekali sebelum VPN terhubung dan sekali sesudahnya. Jika pada keluaran kedua prefiks kontainer menunjuk ke adaptor terowongan, diagnosis selesai dan memulai ulang kontainer tidak akan menolong.
Opsi pertama adalah keputusan kebijakan: tanyakan kepada pemilik jaringan apakah akses LAN lokal dapat diizinkan untuk perangkat ini. Beberapa klien korporat menyediakannya sebagai pengaturan, tetapi itu melemahkan batas yang disengaja. Mintalah sebagai pengecualian terdokumentasi dengan pemilik dan tanggal tinjauan. Sakelar per perangkat yang tidak pernah ditinjau lagi adalah cara kebijakan bertahan menghilang diam-diam.
Di tempat kebijakan harus bertahan, pindahkan beban kerja alih-alih melawan rute. Jaringan transparan dengan subnet dan gateway eksplisit menempatkan kontainer pada tautan lokal, beban kerja Linux berjalan di belakang proksi mesin virtual, dan mesin virtual terpisah dengan kliennya sendiri mempertahankan kebijakannya sendiri. Pilih satu dengan sengaja dan ujilah dari dalam kontainer, karena di sanalah permintaan pengguna berasal.