Mengapa pencarian nama gagal lewat terowongan OpenVPN yang dirutekan

Sebuah host menjawab ping lewat alamat dan gagal pada setiap pencarian lewat nama. Terowongan aktif dan rutenya ada, jadi kesimpulan alaminya adalah VPN salah konfigurasi. Kesimpulan yang lebih berguna adalah pencarian itu tidak pernah bisa dirutekan: terowongan yang dirutekan membawa unicast IP, sedangkan kuerinya adalah siaran yang mencari segmen yang tidak ada di sisi lain. Begitu ketidakcocokan lapisan terlihat, perbaikannya menyusun dirinya sendiri menurut biaya.

Mitos: terowongannya rusak karena nama gagal

Gejalanya meyakinkan karena semua yang di atas lapisan nama bekerja. Alamat dirutekan, antarmuka aktif, dan rekan menjawab ping. Yang gagal adalah mekanisme penemuan yang tidak pernah punya jalur lewat tautan titik-ke-titik, dan itu pernyataan berbeda dari terowongan yang rusak. Memisahkan kedua pernyataan itu adalah sebagian besar diagnosis.

Memperlakukannya sebagai kerusakan terowongan menghasilkan penyuntingan profil yang tidak bisa menolong. Menambah opsi, mengganti enkripsi, atau memasang ulang klien membiarkan siaran persis di tempatnya.

Sebut mekanisme yang gagal sebelum menyebut perbaikannya. Pencarian yang memakai siaran butuh segmen, sedangkan pencarian yang memakai resolver butuh alamat untuk ditanya.

Apa yang dibawa TUN dan apa yang tidak

Perangkat TUN adalah antarmuka IP, dan itulah yang membuatnya bisa dirutekan. OpenVPN memberi klien sebuah alamat dan sekumpulan rute, dan sejak itu klien mengirim datagram ke rekan. Tidak ada apa pun dalam model itu yang menciptakan tautan bersama tempat setiap host mendengar setiap frame.

Lalu lintas penemuan sama sekali tidak cocok dengan model itu. Kueri nama Windows yang lama, pengumuman SSDP, dan permintaan mDNS dikirim ke semua orang di segmen, bukan ke satu tujuan. Tautan yang dirutekan tidak punya «semua orang» untuk dikirimi. Setiap mekanisme itu mengandaikan media bersama.

Karena itu terowongannya bisa sehat sementara penemuan gagal total. Kalimat itulah yang perlu dipegang ketika seseorang melaporkan VPN-nya mati.

Jembatan bekerja dengan menghapus batas

Perangkat TAP membawa frame, dan jembatan memasangnya ke segmen LAN sungguhan. Klien lalu memegang alamat di segmen itu dan mendengar lalu lintas siarannya. Itulah sebabnya menjembatani tampak menyembuhkan masalah nama. Ini juga membuat klien bergantung pada segmen itu untuk pengalamatan.

Obatnya adalah penghapusan batas perutean, bukan kemampuan penamaan baru di dalam terowongan. Semua yang disiarkan segmen sekarang juga menyeberangi tautan.

Untuk laboratorium kecil itu pertukaran yang wajar. Di tenaga kerja yang tersebar jarang begitu.

Mendorong DNS dan WINS adalah perbaikan yang lebih sempit

Beri klien tempat tertentu untuk bertanya. dhcp-option DNS dan dhcp-option DOMAIN mengarahkan nama internal ke server yang mengenal zona itu, dan klien Windows yang masih bergantung pada NetBIOS bisa menerima server WINS dengan cara yang sama. Terowongannya tetap dirutekan dan segmennya tetap di tempatnya.

Dua syarat menentukan apakah itu berhasil. Server yang disebut harus menjawab untuk zona itu, dan kuerinya harus diizinkan lewat terowongan.

Uji resolver dari klien, bukan dari shell server itu sendiri. Resolver yang bekerja secara lokal tidak mengatakan apa pun tentang apa yang dibawa terowongan.

Cari tahu lapisan mana yang gagal

Ping alamatnya dulu, lalu selesaikan namanya dan baca server mana yang menjawab. Jawaban negatif dari server yang tidak menghosting zona itu terlihat berbeda dari kueri yang tidak pernah meninggalkan mesin. Nama yang terselesaikan tetapi menolak koneksi adalah masalah ketiga yang sama sekali lain.

Multicast berada di balik dinding yang sama. Grup seperti 224.0.0.251 tidak diteruskan lewat terowongan yang dirutekan secara bawaan, dan rute untuk grup itu tidak cukup tanpa jalur yang memahami multicast atau reflektor di LAN.