ip netns exec dan DNS: mengapa nama gagal di dalam namespace

Sebuah perintah mencapai 10.8.0.5 di dalam namespace VPN tanpa keluhan, dan perintah yang sama gagal begitu ia memakai nama host. Namespace punya antarmuka, rute, dan soketnya sendiri; ia tidak punya berkas resolver sendiri. Kecuali ada sesuatu yang menaruh satu di sana, proses di dalamnya membaca /etc/resolv.conf milik host dan bertanya ke peladen yang mungkin tidak terjangkau dari tumpukan jaringan tersebut.

Ini masalah pemilihan berkas, bukan masalah perutean, dan justru karena itulah tujuan numeriknya masih berfungsi.

Periksa tampilan resolver yang benar-benar diterima proses

Jangan menganggap shell yang Anda pakai setara dengan proses yang sedang Anda awakutu. Aplikasi grafis, unit systemd, dan wadah masing-masing dapat masuk ke konteks pemasangan atau jaringan yang berbeda. Jalankan pencarian lewat jalur peluncuran yang sama, dan cetak berkas resolver dari dalamnya.

Untuk namespace yang dibuat dengan ip netns add, pemeriksaan hanya-baca itu singkat:

ip netns exec vpn cat /etc/resolv.conf

Perhatikan apakah hasilnya menyebut alamat yang terjangkau, stub loopback, atau symlink yang menunjuk ke tempat dengan keterjangkauan berbeda.

Apa yang sebenarnya dipasang oleh pembantu exec

Alat ip-netns mendokumentasikan konfigurasi per namespace di bawah /etc/netns/NAME/. Saat meluncurkan proses, pembantu itu membuat namespace pemasangan dan memasang berkas-berkas tersebut di atas jalur biasanya, sehingga proses melihat salinan khusus namespace. Itu kemudahan peluncur ini saja. Masuk ke namespace jaringan lewat jalur lain, seperti unshare atau runtime wadah, tidak mereproduksinya secara otomatis.

Resolver loopback adalah jebakannya di sini: 127.0.0.53 berarti loopback milik namespace itu sendiri, bukan stub milik host. Stub yang hanya mendengarkan di namespace host tidak menjadi layanan di namespace baru.

Pilih resolver yang dapat dijangkau namespace

Peladen mana pun yang disebut berkas itu, ia tetap memerlukan rute dari namespace tersebut. Resolver publik dapat menjawab nama publik dan tetap gagal untuk zona internal, karena layanan privat hanya terjangkau lewat terowongan. Periksa rute bersamaan dengan alamat, bukan setelah pencarian sudah gagal.

Aplikasi dengan resolver sendiri, seperti yang memakai DNS over HTTPS, dapat mengabaikan berkas itu sepenuhnya. Jika alat itu punya pengaturan DNS sendiri, mengubah resolv.conf tidak akan memengaruhinya, dan namespace tidak pernah menjadi masalahnya.

Tulis berkas itu di tempat yang benar

Buat berkas per namespace di bawah /etc/netns/NAME/resolv.conf dan biarkan peluncur menyajikannya. Jaga agar minimal: satu atau dua peladen yang terjangkau dan domain pencarian yang dibutuhkan tugas. Jangan menyunting berkas resolver hasil buatan host untuk memperbaiki tampilan yang dimaksudkan bagi satu kelompok proses, karena itu mengubah setiap aplikasi di mesin. Jika host memakai pengelola resolver, konfigurasikan jalur namespace lewat pengelola itu alih-alih melawannya.

Catat isi berkas itu di runbook. Kalau tidak, orang berikutnya akan menguji resolver host, melihat jawaban yang berfungsi, dan menyimpulkan bahwa namespace baik-baik saja.

Uji ulang seluruh jalur

Uji di dalam namespace dengan alamat numerik, nama internal, dan nama publik. Urutan itu memisahkan keterjangkauan dari resolusi dan memisahkan zona internal dari zona publik. Lalu buat ulang namespace dan ulangi, karena berkas yang hanya ada di instans yang berjalan hilang bersamanya.

Pastikan proses, bukan shell, yang menerima berkas itu. Pencarian yang berhasil dari shell interaktif dan gagal dari sebuah layanan adalah temuan tentang konteks pemasangan, dan itu layak dicatat sebelum insiden berikutnya alih-alih ditemukan ulang dari nol.