Dev Container tidak menjangkau host khusus VPN: ke mana harus melihat

API privat terbuka di browser desktop Anda dan gagal di container pengembangan. Itu bukan kontradiksi, dan jarang VPN itu sendiri penyebabnya. Permintaan browser dan permintaan yang gagal dibuat oleh proses berbeda, dengan resolver, proxy, dan rute berbeda, dan sering dari ruang nama jaringan yang sama sekali berbeda. “Di laptop saya” bisa berarti host Windows, distribusi WSL, mesin virtual Docker Desktop, dan container di dalam VM itu — empat konteks yang masing-masing dapat menjawab nama host yang sama secara berbeda. Cari tahu mana yang dipakai proses yang gagal sebelum Anda menyentuh satu setelan pun.

Temukan prosesnya sebelum mengubah setelan

Mulailah dari mesin container, bukan dari klien VPN. Tanyakan konteks mana yang sedang diajak bicara oleh baris perintah, dan sistem operasi apa yang menjalankan mesin itu, karena container Linux yang dikelola VM desktop menempuh jalur berbeda dari yang dikelola daemon lokal:

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

Di Windows, wsl -l -v memberi tahu apakah distribusi berjalan di bawah WSL 2, yang menempatkannya di balik sakelar virtualnya sendiri. Detail itu menentukan apakah container berbagi tabel perutean host atau berada di balik NAT yang memerlukan port diteruskan atau nama host untuk menjangkau host.

Jaga satu permintaan tetap konstan dan bandingkan

Pilih satu endpoint tak berbahaya di host privat dan gunakan untuk setiap perbandingan: dari browser, dari terminal host, dari distribusi WSL, dan dari dalam container. Catat empat hal untuk setiap percobaan: alamat yang diresolusi, apakah proxy dipakai, kelas kegagalan, dan waktu yang berlalu. Pencarian nama, pembentukan koneksi, validasi TLS, dan status HTTP adalah empat masalah berbeda, dan mencampurnya menjadi “tidak berfungsi” membuang satu pagi.

Jalankan perbandingan di dalam container yang gagal, dengan timeout agar firewall yang senyap tidak menahan terminal selama menit-menitan. Container baru mereproduksi konteks jaringan mesin, tetapi bukan ruang nama, variabel proxy, atau resolver container aplikasi, jadi docker exec ke container yang sebenarnya adalah uji yang sah, dan sidecar hanyalah cara mengisolasi apakah perbedaannya ada di mesin atau di container:

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

Image dasar alpine membawa busybox dan tidak membawa curl, dan itulah jenis detail yang membuat blok diagnostik hasil salin-tempel gagal: pilih image yang memiliki kliennya, atau tambahkan di jalannya yang sama. Perbandingan dengan situs publik yang tak terkait tidak mengisolasi apa pun. Jika https://example.com berfungsi dari container, Anda hanya belajar bahwa container punya akses internet, dan tidak tahu apakah ia menjangkau alamat privat melalui tunnel. Sama halnya, membuka terminal baru hanya membuktikan terminal baru itu berfungsi, bukan bahwa ia berbagi runtime dengan aplikasi yang gagal.

Docker Desktop bisa bekerja dengan VPN

Dokumentasi Docker sendiri tentang VPN dan konektivitas host menggambarkannya sebagai penyiapan yang didukung, dan ringkasan jujurnya adalah ia bekerja alih-alih rusak secara otomatis. Jangan menganggap VM desktop melewati tunnel host sebagai soal desain; pada banyak penyiapan lalu lintas mengikuti tunnel host dengan benar, dan itulah sebabnya mitos “Docker mengabaikan VPN” menghasilkan nasihat yang percaya diri dan salah.

Yang masih penting adalah backend yang dipakai, kebijakan split-tunnel klien, dan konfigurasi resolver yang diterima VM. Klien VPN yang memasang rute tetapi bukan DNS, atau yang mendorong server DNS yang tidak dapat dijangkau VM, menghasilkan kegagalan pencarian nama di dalam container sementara host berfungsi karena host memiliki resolver tambahan atau jawaban ter-cache. Itu masalah resolver yang memakai kostum container. Ia bertahan pada setiap penyambungan ulang VPN yang Anda coba, karena tunnel sudah membawa lalu lintas yang Anda minta.

Tumpang tindih alamat dan MTU adalah kegagalan berbeda

Dua kegagalan layak didiagnosis sendiri karena sering disalahartikan sebagai kebijakan akses. Yang pertama adalah tumpang tindih alamat: jika VPN mendorong rentang yang bertabrakan dengan subnet jembatan default jaringan container, rute container untuk rentang itu mengarah ke jembatan lokal dan tidak pernah mencapai tunnel. Periksa subnet sebenarnya alih-alih menebak:

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

Yang kedua adalah masalah MTU. Jika koneksi terbentuk dan TLS selesai tetapi respons yang lebih besar tersendat, Anda punya masalah ukuran paket, bukan masalah otorisasi, dan mengganti record DNS tidak akan pernah memperbaikinya. Uji dengan permintaan kecil dan besar sebelum mengubah apa pun, dan catat kedua hasilnya.

Perbaikan untuk tumpang tindih adalah subnet container lain atau rute terbatas, dipilih oleh pemilik rencana alamat. Perbaikan untuk kemacetan MTU adalah menjepit atau menurunkan MTU tunnel atau antarmuka ke nilai yang bertahan di jalur, diterapkan pada lapisan yang Anda kendalikan.

Konfigurasi proxy bersifat per proses, bukan per mesin

Di dalam container, localhost menamai konteks jaringan container itu sendiri, jadi proxy yang berjalan di host tidak terjangkau di sana dengan nama itu. Docker Desktop menyediakan host.docker.internal untuk akses host, dan di Linux Anda menambahkannya secara eksplisit dengan --add-host=host.docker.internal:host-gateway. Bagaimanapun, nama itu memberi Anda rute ke host; ia tidak membuat layanan proxy atau memberi Anda wewenang untuk memakainya.

Gunakan alamat dan port proxy yang disediakan untuk lingkungan sebenarnya, dan periksa siapa yang membacanya. Variabel yang diekspor di shell interaktif tidak otomatis mengonfigurasi setiap ekstensi editor, server bahasa, alat build, dan daemon latar belakang. Yang penting adalah proses yang membuat permintaan gagal itu, jadi periksa lingkungannya, bukan lingkungan terminal Anda.

Terakhir, buat perbaikan itu menjelaskan dirinya sendiri. Penyelesaian yang berguna menyebut batas yang salah, setelan yang mengubahnya, dan kumpulan proses yang kini terpengaruh. Menyalakan ulang VPN, editor, dan mesin secara berurutan dapat mengubah gejala, tetapi tidak meninggalkan apa pun yang bisa dipakai orang berikutnya.