Nama hos LAN gagal melalui VPN: sufiks, mDNS atau zon?

Di sebelah peranti, pencetak menjawab nama pendek dan pelayan fail menjawab nama panggilan. Melalui terowong, kedua-dua nama tamat masa manakala alamatnya masih berfungsi. Laluan menjalankan tugasnya; laluan penamaan yang menjadikan nama pendek itu berfungsi tidak pernah melintasi terowong. Tiga mekanisme menghasilkan tingkah laku itu, dan setiap satu memerlukan pembetulan berbeza.

Mulakan dengan mengenal pasti mekanisme mana yang menjadi sandaran nama itu.

Tiga jenis nama yang berkelakuan berbeza

Nama berlabel tunggal seperti fileserver biasanya bergantung pada sufiks carian DNS yang ditambahkan oleh penyelesai. Sufiks itu sering datang bersama pajakan DHCP setempat, jadi klien jauh yang memperoleh pengalamatan daripada VPN tiada sebab untuk mengetahuinya. Menambah laluan tidak menyampaikan sufiks itu. Nama pendek itu berhenti wujud sebagai nama, walaupun alamat di belakangnya boleh dicapai.

Nama yang berakhir dengan .local biasanya diselesaikan oleh DNS multicast pada pautan setempat, seperti yang diterangkan RFC 6762. Multicast tidak melintasi terowong yang dilalui laluan melainkan sesuatu sengaja menjambatani atau memproksikannya, jadi nama itu berhenti diselesaikan pada saat anda meninggalkan segmen.

Nama syarikat yang layak sepenuhnya tergolong dalam zon dalaman yang dilayani oleh penyelesai organisasi. Nama itu berfungsi dari jauh apabila VPN menolak penyelesai tersebut dan klien dikonfigurasikan untuk menggunakannya. Dan localhost ialah penggunaan khas menurut RFC 6761: ia merujuk mesin di hadapan anda, tidak pernah kepada perkhidmatan jauh.

Baca penyelesai sebelum menukar laluan

Tanya pelayan nama mana yang menjawab dan sufiks apa yang ditambahkan. Pertanyaan yang sama melalui penyelesai berbeza memberikan jawapan berbeza, dan perbezaan itulah bukti yang anda perlukan.

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 pertanyaan yang layak sepenuhnya diselesaikan tetapi yang pendek tidak, kegagalan itu terletak pada sufiks, bukan pelayan. Jika kedua-duanya tidak diselesaikan dan alamatnya berfungsi, klien langsung tidak menggunakan penyelesai dalaman. Bandingkan senarai penyelesai dengan apa yang sepatutnya ditolak oleh VPN, kerana klien yang menyimpan penyelesai setempatnya untuk setiap pertanyaan tidak akan pernah melihat zon dalaman.

Bawa nama yang betul kepada klien

Minta nama akses jauh yang didokumenkan daripada pentadbir, sepenuhnya, dan gunakannya dalam profil dan bukannya meneka sufiks. Jika penggunaan menyokong split DNS, konfigurasikan domain dalaman untuk diselesaikan oleh pelayan dalaman sementara semua yang lain mengekalkan penyelesai setempat. Tolak domain carian melalui konfigurasi VPN di tempat klien menyokongnya.

Sahkan hasilnya pada klien dan bukan pada gerbang. Tetapan yang digunakan pada pelayan dan tidak pernah sampai kepada klien tidak mengubah apa-apa.

Kekalkan identiti sijil

Ujian berasaskan alamat yang mengabaikan ralat sijil hanya membuktikan bahawa soket dibuka. Sijil perkhidmatan dikeluarkan untuk nama, dan klien akan terus menolak ketidakpadanan dengan alasan yang wajar. Jika sijil hanya menyenaraikan nama dalaman, gunakan nama itu dan betulkan penyelesaian, atau dapatkan sijil yang merangkumi alamat yang anda ingin gunakan.

Rekodkan nama, penyelesai dan sufiks yang menghasilkan sambungan berjaya. Rekod itu menjimatkan orang seterusnya daripada mengulangi penyelesaian sementara berasaskan alamat yang menyembunyikan masalah sebenar.