Dua VPN, Satu Resolver: Yang Menulis Terakhir Menang

Dua klien VPN terhubung, satu untuk kerja dan satu untuk jaringan laboratorium, dan nama internal hanya diselesaikan untuk klien yang terhubung terakhir. Pola itu terlihat seperti bug pada salah satu klien. Biasanya itu hasil yang dapat diprediksi dari dua program yang menulis konfigurasi resolver yang sama tanpa kesepakatan tentang siapa pemilik nama mana.

Mitos: VPN terbaru memiliki DNS

Tidak ada aturan umum bahwa koneksi terbaru menang. Apa yang terjadi bergantung pada mekanisme platform dan pada cara setiap klien menulisnya. Klien yang mengganti berkas resolver menghasilkan satu hasil; klien yang menambahkan domain per tautan menghasilkan hasil lain; klien yang tidak melakukan apa pun membiarkan keadaan sebelumnya utuh.

Jadi perilaku yang teramati adalah sifat kedua implementasi, bukan prioritas yang terdokumentasi. Bernalar hanya dari urutan peluncuran kadang benar dan kadang salah dengan cara yang sulit direproduksi. Tuliskan pemetaannya. Desain yang hidup di dua klien bukanlah desain.

Petakan ruang nama ke resolver

Daftar sufiks privat dan resolver yang dibutuhkan setiap jaringan, lalu putuskan ke mana nama publik harus pergi. Daftar itu adalah desainnya. Tanpanya, klien mengambil keputusan secara kebetulan.

Platform yang mendukung DNS per tautan atau domain perutean dapat menyatakan pembagian itu dengan sengaja: satu domain menuju satu tautan, domain lain ke tautan lainnya, dan sisanya mengikuti default yang eksplisit. Dua skrip datar yang menimpa berkas yang sama tidak dapat mempertahankan desain itu, karena masing-masing menganggap dirinya memiliki seluruh konfigurasi.

Di Windows, tabel kebijakan resolusi nama dapat mengarahkan sufiks ke server tertentu, dan klien VPN dapat memasang aturan di sana. Periksa kebijakannya, bukan daftar adaptor, karena bukan daftar adaptor yang menyelesaikan nama.

Pertahankan jalur bootstrap

Setiap klien harus menemukan titik akhirnya sendiri sebelum dapat memakai layanan yang disediakan titik akhir itu. Jika nama host titik akhir hanya dapat diselesaikan melalui tunnel, dan tunnel membutuhkan nama host yang sudah diselesaikan, Anda punya ketergantungan melingkar yang muncul sebagai batas waktu koneksi. Pertahankan satu jalur bootstrap di luar kedua tunnel. Itu tidak memakan biaya sampai hari ketika ia menyelamatkan koneksi.

Lihat jalur ke setiap resolver, bukan hanya nama yang dikonfigurasi untuknya. Resolver yang hanya dapat dijangkau melalui tunnel lain berperilaku seperti resolver yang hilang, dan gejalanya adalah batas waktu, bukan kesalahan perutean.

Alamat yang tumpang tindih bukan masalah DNS

Dua jaringan privat yang memakai rentang alamat yang sama tidak bisa diperbaiki dengan urutan DNS. Jika kedua tunnel mengklaim 10.0.0.0/8, nama yang diselesaikan dengan benar tetap menunjuk ke alamat yang tidak dapat dirutekan host ke tunnel yang tepat. Itu memerlukan solusi di tingkat alamat, seperti rentang berbeda, ruang nama, atau penerjemahan, bukan pengaturan resolver lain. Memutuskan ini sejak awal mencegah pengalihan panjang melalui konfigurasi DNS yang tidak akan pernah berhasil.

Bandingkan penetapan alamat kedua tunnel sebelum menyalahkan resolusi nama. Ketika kedua pihak mendorong prefiks yang sama, host menyimpan satu rute untuknya, dan nama yang diselesaikan melalui tunnel kedua tetap mendarat di alamat yang dimiliki tunnel pertama. Rentang berbeda, ruang nama per jaringan, atau penerjemahan adalah perbaikannya; setelah setiap klien terhubung, pastikan tabel rute menunjukkan jalur yang Anda maksudkan.

Buktikan dengan aplikasi nyata

Pilih dua host yang hanya ada di dalam ruang namanya sendiri dan satu nama publik, lalu selesaikan masing-masing melalui klien yang seharusnya memilikinya. Jawaban benar dari resolver yang diharapkan tidak membuktikan aplikasi mencapai host, karena rute ke alamat itu masih bisa gagal. Ikuti setiap pencarian dengan uji koneksi dari program yang benar-benar akan dijalankan pengguna.

Klien dengan opsi DNS terenkripsi sendiri dapat melewati kebijakan yang baru saja Anda verifikasi, jadi periksa pengaturan itu sebagai bagian dari tinjauan. Lalu hubungkan kembali kedua klien dalam urutan yang didukung vendor dan ulangi pencarian; jika jawabannya bertukar saat urutannya berubah, penulis pesaing masih memiliki sebagian konfigurasi. Cari tahu komponen mana yang memasang aturan itu - klien, profil sistem operasi, atau agen manajemen - sebelum menyunting apa pun. Catat urutan dan pemiliknya agar orang berikutnya tidak perlu menemukannya lagi.