Bir LAN ana bilgisayarı neden bir OpenVPN istemci adresi için ARP yapar

Bir LAN ana bilgisayarı ile VPN istemcisi arasındaki erişilebilirlik sorunları çoğu zaman adres planının kendisine dayanır. Bu ana bilgisayara 10.0.100.0/22 üzerinde bir arayüz verin; 10.0.100.0 ile 10.0.103.255 arasındaki her adresi, 10.0.101.0/24 üzerine sessizce yerleştirilmiş bir istemci havuzu dahil, doğrudan bağlı sayar. Yanıt hiçbir zaman bir yönlendiriciye gitmez, çünkü ana bilgisayarın bakış açısından hiçbir yönlendirici işe karışmaz. Paket bir komşuya adreslenir ve kabloda istenir.

Bu mekanizma bütün bir rapor ailesinin arkasındadır: tünel açık, sunucunun bir yolu var ve LAN ana bilgisayarı yine de istemciye ulaşamıyor.

/24'ü yutan /22

Öneki bir dizi olarak değil, bir aralık olarak okuyun. Bir /22 1024 adres içerir ve 10.0.100.0/22, 10.0.100.0'dan 10.0.103.255'e uzanır, bu yüzden 10.0.101.0/24 üzerindeki bir havuz tamamen içinde kalır. Hata incelemeyi atlatır çünkü havuzun ilk oktetleri LAN'ın ilk oktetlerinden farklı görünür ve iç içe geçmeyi yalnızca üçüncü oktet ele verir. Ayrı olduklarını ilan etmeden önce iki aralığı da sayısal olarak yazın.

Aynı iç içe geçme ters yönde de görünebilir. Şu anda kimse kullanmadığı için boş görünen bir havuz yine de bir saha yönlendiricisinin duyurduğu bir önekin içine düşebilir ve adres planı bunu gösteren tek belgedir.

Doğrudan bağlantı ARP demektir, yönlendirme değil

Bir /22 arayüzü olan ana bilgisayar 10.0.101.25'e gönderdiğinde, çekirdek hedefi arayüzün önekiyle karşılaştırır ve bir eşleşme bulur. Paket yönlendirilmiş bir paket yerine komşu aramasına dönüşür ve Ethernet'te komşu araması o adres için bir ARP isteğidir. Adres yönlendirilmiş bir ağ geçidinin arkasındaki bir VPN istemcisine aitse, LAN'daki hiçbir ana bilgisayar ona sahip değildir, bu yüzden istek yanıtsız kalır ve paketler düşürülür. Tünel suçlu değildir ve istemci trafiği hiç görmez.

Bu yüzden arıza asimetrik ve zaman zaman kesintili görünür. VPN ana bilgisayarı LAN'a sık sık ulaşabilir çünkü kendi yolları doğru yönü gösterir, oysa LAN ana bilgisayarı yanıt veremez ve eski bir ARP girdisini önbelleğe alan her şey belirtiyi titretir.

TUN, TAP ve her birinin taşıdıkları

Bir TUN aygıtı IP paketleri taşır ve bir TAP aygıtı Ethernet çerçeveleri taşır. Yönlendirilmiş bir TUN bağlantısı IP erişilebilirliği sağlamak için ARP taşımak zorunda değildir ve yukarıdaki yanıtsız isteğin beklenen olmasının, bozuk olmamasının nedeni tam da budur. Kasıtlı bir köprüyle TAP, yayın alanını genişletebilir ve ARP'yi çalıştırabilir, ancak istemcinin ne görebileceğini değiştirir, aynı çerçevelemeyi destekleyen uç noktalar gerektirir ve çakışan bir önek için onarım değil, ağ modelinin yeniden tasarımıdır. Yönlendirilmiş bir kurulumu adres planı hatasını iyileştirmek için TAP'a geçirmek küçük bir sorunu daha büyüğüyle değiş tokuş eder.

Sonuç çıkarmadan önce ARP isteğinin nerede göründüğünü ve hangi sistemin gönderdiğini kaydedin. Gönderen size hedef hakkında ne düşündüğünü söyler, tünelin ne yaptığını değil.

Çakışamayan bir havuz tasarlayın

Her bağlı önekin ve her duyurulan saha önekinin dışında bir havuz seçin, ardından onu her iki yönde de erişilebilir kılan yolları ekleyin. Planın kullanılmayan bir bölümünde 10.8.0.0/24 gibi bir aralığı düşünmek kolaydır ve ona ulaşması gereken LAN, VPN sunucusuna işaret eden statik bir yol alır. Tahsisi, duyurulan yolları, izin verilen kaynak adreslerini ve güvenlik duvarı kurallarını birlikte değiştirin, çünkü bunlar dört ayar değil tek bir tasarımı anlatır.

Sunucudaki Source NAT, havuzu LAN'dan yönlendirilebilir bir adresin arkasına saklayabilir ve meşru bir geçiş aracıdır. Kaynağı da yeniden yazar, bu yüzden LAN bağlantıları tek tek istemcilere atama ve istemci başına kural uygulama yeteneğini kaybeder.

Kabul için gerçek istemcinin fiilen atanmış adresini ve bir LAN ana bilgisayarından gerçek bir uygulama isteğini kullanın, ardından yanıtın kabloyu değil planlanan ağ geçidini izlediğini doğrulayın.