Yönlendirilmiş bir OpenVPN tünelinde ad aramaları neden başarısız olur

Bir makine adresle ping'e yanıt verir ama adla yapılan her aramada başarısız olur. Tünel ayakta ve yol var, bu yüzden doğal sonuç VPN'in yanlış yapılandırıldığıdır. Daha işe yarar sonuç, aramanın hiçbir zaman yönlendirilebilir olmadığıdır: yönlendirilmiş tünel yalnızca unicast IP taşır, oysa söz konusu sorgu diğer tarafta bulunmayan bir segmenti arayan bir yayındı. Katman uyuşmazlığı görünür olduğunda onarımlar kendiliğinden maliyete göre sıralanır.

Efsane: adlar başarısız olduğu için tünel bozuk

Belirti inandırıcı çünkü ad katmanının üstündeki her şey çalışıyor. Adresler yönlendiriliyor, arayüz ayakta ve karşı taraf ping'e yanıt veriyor. Başarısız olan, noktadan noktaya bir bağlantı üzerinden hiç yolu olmayan bir keşif mekanizmasıdır ve bu, bozuk bir tünelden farklı bir ifadedir. Bu iki ifadeyi ayırmak teşhisin büyük bölümüdür.

Bunu bir tünel arızası olarak ele almak, yardımcı olamayacak profil değişikliklerine yol açar. Seçenek eklemek, şifrelemeyi değiştirmek veya istemciyi yeniden kurmak yayını tam olarak olduğu yerde bırakır.

Onarımı adlandırmadan önce başarısız olan mekanizmayı adlandırın. Yayın kullanan bir arama segmente ihtiyaç duyar, çözümleyici kullanan bir arama ise soracak bir adrese ihtiyaç duyar.

TUN neyi taşır, neyi taşımaz

TUN aygıtı bir IP arayüzüdür ve onu yönlendirilebilir yapan tam olarak budur. OpenVPN istemciye bir adres ve bir dizi yol verir, ardından istemci karşı tarafa datagram gönderir. O modelde her makinenin her çerçeveyi duyduğu paylaşılan bir bağlantı oluşturan hiçbir şey yoktur.

Keşif trafiği o modele hiç uymaz. Eski Windows ad sorguları, SSDP duyuruları ve mDNS istekleri tek bir hedefe değil, segmentteki herkese gönderilir. Yönlendirilmiş bir bağlantıda gönderilecek bir «herkes» yoktur. Bu mekanizmaların her biri paylaşılan bir ortam varsayar.

Bu yüzden tünel sağlıklıyken keşif tamamen başarısız olabilir. Birisi VPN'in çöktüğünü bildirdiğinde tutunulacak cümle tam olarak budur.

Köprüleme sınırı kaldırarak çalışır

TAP aygıtı çerçeve taşır ve bir köprü onu gerçek bir LAN segmentine bağlar. İstemci o segmentte bir adres tutar ve onun yayın trafiğini duyar. Köprülemenin ad sorununu iyileştiriyor görünmesinin nedeni budur. Aynı zamanda istemciyi adresleme için o segmente bağımlı kılar.

Çözüm, yönlendirme sınırının kaldırılmasıdır, tünelin içinde yeni bir adlandırma yeteneği değil. Segmentin yaydığı her şey artık bağlantıyı da geçiyor.

Küçük bir laboratuvar için bu adil bir değiş tokuştur. Dağıtılmış bir iş gücünde nadiren öyledir.

DNS ve WINS itmek daha dar onarımdır

İstemciye soracak belirli bir yer verin. dhcp-option DNS ve dhcp-option DOMAIN iç adları bölgeyi bilen bir sunucuya yönlendirir ve hâlâ NetBIOS'a güvenen bir Windows istemcisi de aynı şekilde bir WINS sunucusu alabilir. Tünel yönlendirilmiş kalır ve segment yerinde kalır.

İki koşul bunun işe yarayıp yaramayacağını belirler. Belirtilen sunucu bölge için yanıt vermeli ve sorguya tünelden izin verilmelidir.

Çözümleyiciyi sunucunun kendi kabuğundan değil istemciden test edin. Yerelde çalışan bir çözümleyici tünelin ne taşıdığı hakkında hiçbir şey söylemez.

Hangi katmanın başarısız olduğunu bulun

Önce adrese ping atın, sonra adı çözün ve hangi sunucunun yanıt verdiğini okuyun. Bölgeyi barındırmayan bir sunucudan gelen olumsuz yanıt, makineden hiç çıkmayan bir sorgudan farklı görünür. Çözülen ama bağlantıları reddeden bir ad, tamamen üçüncü bir sorundur.

Multicast aynı duvarın arkasındadır. 224.0.0.251 gibi bir grup varsayılan olarak yönlendirilmiş bir tünelden iletilmez ve grup için bir yol, multicast'ı anlayan bir yol ya da LAN üzerinde bir yansıtıcı olmadan yeterli değildir.