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

Satu arahan sampai ke 10.8.0.5 di dalam ruang nama VPN tanpa sebarang aduan, dan arahan yang sama gagal sebaik sahaja ia menggunakan nama hos. Ruang nama mempunyai antara muka, laluan dan soketnya sendiri; ia tidak mempunyai fail penyelesai sendiri. Kecuali sesuatu meletakkan satu di sana, proses di dalam membaca /etc/resolv.conf hos dan bertanya kepada pelayan yang mungkin tidak dapat dicapai dari tindanan rangkaian itu.

Ini masalah pemilihan fail dan bukan masalah penghalaan, dan itulah sebabnya destinasi berangka masih berfungsi.

Semak pandangan penyelesai yang benar-benar diterima proses

Jangan anggap shell yang anda gunakan setara dengan proses yang anda nyahpepijat. Aplikasi grafik, unit systemd dan kontena masing-masing boleh memasuki konteks lekap atau rangkaian yang berbeza. Jalankan carian melalui laluan pelancaran yang sama, dan cetak fail penyelesai dari dalamnya.

Untuk ruang nama yang dicipta dengan ip netns add, semakan baca sahaja adalah ringkas:

ip netns exec vpn cat /etc/resolv.conf

Perhatikan sama ada hasilnya menamakan alamat yang boleh dicapai, stub loopback, atau pautan simbolik yang menunjuk ke tempat dengan kebolehmencapaian yang berbeza.

Apa yang sebenarnya dilekapkan oleh pembantu exec

Alat ip-netns mendokumenkan konfigurasi setiap ruang nama di bawah /etc/netns/NAME/. Apabila ia melancarkan proses, pembantu itu mencipta ruang nama lekap dan melekapkan fail-fail itu di atas laluan biasa mereka, jadi proses melihat salinan khusus ruang nama. Itu kemudahan pelancar khusus ini. Memasuki ruang nama rangkaian melalui laluan lain, seperti unshare atau runtime kontena, tidak menghasilkan semula perkara itu secara automatik.

Penyelesai loopback ialah perangkap di sini: 127.0.0.53 bermaksud loopback ruang nama itu sendiri, bukan stub hos. Stub yang mendengar hanya dalam ruang nama hos tidak menjadi perkhidmatan dalam ruang nama baharu.

Pilih penyelesai yang boleh dicapai oleh ruang nama

Walau apa pun pelayan yang dinamakan oleh fail itu, ia masih memerlukan laluan dari ruang nama itu. Penyelesai awam boleh menjawab nama awam dan masih gagal untuk zon dalaman, kerana perkhidmatan persendirian hanya boleh dicapai melalui terowong. Semak laluan pada masa yang sama dengan alamat, bukan selepas carian sudah gagal.

Aplikasi dengan penyelesai sendiri, seperti yang menggunakan DNS melalui HTTPS, mungkin mengabaikan fail itu sepenuhnya. Jika alat itu mempunyai tetapan DNS sendiri, menukar resolv.conf tidak akan menjejaskannya, dan ruang nama tidak pernah menjadi masalahnya.

Tulis fail itu di tempat yang betul

Cipta fail khusus ruang nama di bawah /etc/netns/NAME/resolv.conf dan biarkan pelancar membentangkannya. Kekalkan ia minimum: satu atau dua pelayan yang boleh dicapai dan domain carian yang diperlukan oleh tugasan. Jangan sunting fail penyelesai terjana hos untuk membaiki pandangan yang dimaksudkan untuk satu kumpulan proses, kerana itu mengubah setiap aplikasi pada mesin. Jika hos menggunakan pengurus penyelesai, konfigurasikan laluan ruang nama melalui pengurus itu dan bukannya bergelut dengannya.

Catat kandungan fail itu dalam runbook. Jika tidak, orang seterusnya akan menguji penyelesai hos, melihat jawapan yang berfungsi dan membuat kesimpulan bahawa ruang nama itu baik.

Uji semula keseluruhan laluan

Uji di dalam ruang nama dengan alamat berangka, nama dalaman dan nama awam. Urutan itu memisahkan kebolehmencapaian daripada penyelesaian dan memisahkan zon dalaman daripada zon awam. Kemudian cipta semula ruang nama dan ulangi, kerana fail yang hanya wujud dalam instans yang berjalan hilang bersamanya.

Sahkan proses, bukan shell, yang menerima fail itu. Carian yang berfungsi dari shell interaktif dan gagal dari perkhidmatan ialah penemuan tentang konteks lekap, dan ia wajar dicatat sebelum insiden seterusnya daripada ditemui semula dari awal.