Tunnel sudah aktif, jadi mengapa nama privat masih gagal?

Semua tentang koneksi terlihat benar: tunnel aktif dan konsol menampilkan titik akhir privat, tetapi setiap permintaan gagal pada resolusi nama. Langkah alami adalah menyalahkan tunnel, yang biasanya ternyata tidak bersalah. Kueri dikirim ke server yang tidak tahu apa pun tentang zona privat. Tidak ada perubahan perutean yang akan mengubah jawaban itu, karena masalahnya adalah siapa yang ditanya.

Resolver mana yang menerima kueri?

Temukan resolver yang terpasang pada setiap tautan sebelum melihat tunnel sama sekali. Linux menampilkan server per tautan melalui perintah status resolver, dan macOS menampilkan resolver berlingkup dalam dump konfigurasi DNS-nya. Jika jawaban masih datang dari router rumah, tautan tunnel tidak pernah ditanyai.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Dua tahap tercampur di sini: server yang mendorong alamat resolver, dan klien yang memasangnya pada tautan aktif. Profil dapat berisi opsi itu, dan log dapat menunjukkan kedatangannya, sementara sistem operasi tetap menggunakan server lama. Bandingkan log dengan apa yang dilaporkan tautan, dan percayai tautan.

Gunakan alamat yang benar-benar dijawab oleh jaringan cloud

Jaringan cloud biasanya menjawab nama privat melalui alamat cadangan yang berjarak dua dari dasar rentang, jadi jaringan yang dimulai pada 10.0.0.0 menjawab pada 10.0.0.2. Beberapa penyedia juga menerbitkan resolver lokal-tautan yang bekerja tanpa mengetahui rentang, yang membantu ketika jaringan dibangun oleh orang lain. Tanyakan alamat kandidat secara langsung sebelum mendorongnya ke siapa pun. Alamat yang bukan resolver terlihat persis seperti drop firewall, karena kueri tidak pernah mendapat jawaban.

Jika kueri langsung menjawab dari dalam jaringan tetapi tidak melalui tunnel, resolvernya baik dan jalur antara dua titik tidak. Hasil itu memindahkan penyelidikan ke rute, penerusan, dan aturan akses alih-alih profil klien.

Tunnel tidak membawa ruang nama

Paket melintas; nama tidak. Setiap sisi harus diberi tahu ruang nama mana yang milik sisi lain, dan itu objek terpisah yang dimiliki oleh pemegang zona. Bentuk biasanya adalah penerusan untuk satu ruang nama, diarahkan ke resolver yang dapat dijangkau melalui tunnel.

Dalam praktiknya setiap arah membutuhkan aturannya sendiri, karena sisi yang memiliki zona harus mengirimkan kueri. Kedua arah memerlukan sumber kueri dirutekan dan diizinkan, dan sisi yang menjawab harus mengembalikan jawaban melalui tunnel alih-alih ke internet. Jaga penerusan tetap sempit, sehingga hanya ruang nama privat yang bergantung pada tautan. Mengirim setiap kueri melaluinya mengubah ketergantungan kecil menjadi pemadaman total saat tunnel jatuh.

Telusuri batas-batas secara berurutan

Uji resolver yang terpasang pada tautan aktif, lalu kueri langsung ke resolver itu, lalu kueri yang sama dari sisi jauh, dan akhirnya aplikasi yang menggunakan nama yang sama. Setiap langkah mengisolasi satu batas, sehingga kegagalan memberi tahu Anda di mana harus melihat alih-alih memulai penyelidikan dari awal. Jawaban yang berfungsi sementara aplikasi gagal menunjuk pada kepercayaan sertifikat atau kebijakan API alih-alih DNS. Kesalahan itu nyata, dan tidak ada perubahan resolver yang akan memperbaikinya.

Catat langkah mana yang gagal. Satu baris itu adalah yang dibutuhkan orang berikutnya, dan mencatatnya butuh sepuluh detik.

Simpan rantai di tempat orang berikutnya dapat menemukannya

Catat resolver yang didorong, aturan penerusan, sumber kueri yang diizinkan, dan titik akhir yang menjawab di satu tempat. Ketika nama privat gagal lagi, catatan menunjukkan apakah tunnel berpindah, alamat resolver berubah, atau aturan dipersempit. Tanpanya setiap insiden dimulai dari nol dan berakhir dengan tiga dugaan yang sama.

Jaga catatan tetap cukup singkat agar akurat: empat baris, tanggal, dan nama pemilik setiap bagian. Catatan usang lebih buruk daripada tidak ada, karena terlihat berwibawa padahal salah.