Nama host LAN gagal lewat VPN: sufiks, mDNS, atau zona?

Di samping perangkat, printer menjawab nama pendek dan server file menjawab nama panggilan. Lewat terowongan, kedua nama itu kehabisan waktu sementara alamatnya masih berfungsi. Rute menjalankan tugasnya; jalur penamaan yang membuat nama-nama pendek itu berfungsi tidak pernah menyeberangi terowongan. Tiga mekanisme menghasilkan perilaku itu, dan masing-masing memerlukan koreksi berbeda.

Mulailah dengan mengidentifikasi mekanisme mana yang menjadi sandaran nama itu.

Tiga jenis nama yang berperilaku berbeda

Nama berlabel tunggal seperti fileserver biasanya bergantung pada sufiks pencarian DNS yang ditambahkan resolver. Sufiks itu sering datang bersama sewa DHCP lokal, jadi klien jarak jauh yang memperoleh pengalamatan dari VPN tidak punya alasan untuk mengetahuinya. Menambahkan rute tidak mengantarkan sufiks itu. Nama pendek itu berhenti ada sebagai nama, meskipun alamat di belakangnya dapat dijangkau.

Nama yang berakhiran .local biasanya diselesaikan oleh DNS multicast di tautan lokal, seperti yang dijelaskan RFC 6762. Multicast tidak menyeberangi terowongan yang dirutekan kecuali ada sesuatu yang sengaja menjembatani atau memproksinya, sehingga nama itu berhenti diselesaikan saat Anda meninggalkan segmen.

Nama perusahaan yang sepenuhnya memenuhi syarat milik zona internal yang dilayani resolver organisasi. Nama itu berfungsi dari jarak jauh ketika VPN mendorong resolver tersebut dan klien dikonfigurasi untuk memakainya. Dan localhost bersifat penggunaan khusus menurut RFC 6761: nama itu merujuk mesin di depan Anda, tidak pernah ke layanan jarak jauh.

Baca resolver sebelum mengubah rute

Tanyakan server nama mana yang menjawab dan sufiks apa yang ditambahkan. Kueri yang sama melalui resolver berbeda memberi jawaban berbeda, dan perbedaan itulah bukti yang Anda butuhkan.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

Jika kueri yang sepenuhnya memenuhi syarat berhasil diselesaikan tetapi yang pendek tidak, kegagalannya ada pada sufiks, bukan pada server. Jika keduanya tidak diselesaikan dan alamatnya berfungsi, klien sama sekali tidak memakai resolver internal. Bandingkan daftar resolver dengan apa yang seharusnya didorong VPN, karena klien yang mempertahankan resolver lokalnya untuk setiap kueri tidak akan pernah melihat zona internal.

Bawa nama yang benar ke klien

Mintalah nama akses jarak jauh yang terdokumentasi kepada administrator, secara lengkap, dan pakailah dalam profil alih-alih menebak sufiks. Jika penerapan mendukung split DNS, konfigurasikan domain internal agar diselesaikan oleh server internal sementara semua yang lain mempertahankan resolver lokal. Dorong domain pencarian melalui konfigurasi VPN di tempat klien mendukungnya.

Verifikasi hasilnya di klien, bukan di gateway. Pengaturan yang diterapkan di server dan tidak pernah sampai ke klien tidak mengubah apa pun.

Jaga identitas sertifikat tetap utuh

Uji berbasis alamat yang mengabaikan kesalahan sertifikat hanya membuktikan bahwa soket terbuka. Sertifikat layanan diterbitkan untuk sebuah nama, dan klien akan terus menolak ketidakcocokan dengan alasan yang tepat. Jika sertifikat hanya mencantumkan nama internal, gunakan nama itu dan perbaiki penyelesaiannya, atau dapatkan sertifikat yang mencakup alamat yang ingin Anda pakai.

Catat nama, resolver, dan sufiks yang menghasilkan koneksi berhasil. Catatan itu menghemat orang berikutnya dari mengulangi solusi sementara berbasis alamat yang menyembunyikan masalah sebenarnya.