ARP'yi devre dışı bırakmak VPN'inizi bozar mı? Dış atlama noktasında bozabilir

{Aynı bağlantıda iki paket yolculuk eder ve farklı kurallara uyarlar. Biri tünelin taşıdığı özel pakettir ve sanal arayüz bunu herhangi bir Ethernet başlığı olmadan işler. Diğeri makineden erişim bağlantısı üzerinden çıkan şifreli pakettir ve bunun hâlâ donanım adresine çözülen yerel bir sonraki atlamaya ihtiyacı vardır. Bu ikisini karıştırmak, insanların adres çözümlemesini yanlış arayüzde kapatıp sonra tünel neden hiç başlamıyor diye şaşmalarının nedenidir.}

{Birinin içinde diğeri, iki teslim modeli}

{Yönlendirilmiş kipteki sanal arayüz IP paketlerini kabul eder. Ethernet başlığı, yayın alanı ve içinde çözülecek adresi yoktur, bu yüzden iç paketi tünelin kendisi teslim eder. Erişim ağında olanlar ayrı bir teslim katmanıdır.}

inner packet: private address -> tunnel device -> the VPN process
outer packet: endpoint address -> access route -> next-hop hardware address

{Bu dış paket bir Ethernet arayüzünden çıkarken sıradan bir unicast çerçevedir ve sonraki atlamasının hedef donanım adresine ihtiyaç duyar. Adres çözümlemesi bunu sağlar ve sonraki atlama genellikle uzak sunucu değil yerel ağ geçididir. Aramanın uç nokta için değil ağ geçidi için olduğunu anlamak teşhisin büyük kısmıdır. Bir şeyi değiştirmeden önce iki adresi de yazın.}

{Gerçekten önemli olan komşuyu bulun}

{Yönlendirme tablosuna uç noktanın hangi sonraki atlamayı kullandığını sorun, ardından o atlama için komşu tablosunu inceleyin. Uç noktanın kendisi orada nadiren görünür, çünkü yerel bağlantıda değildir.}

ip route get 198.51.100.20
ip neigh show 192.168.0.1

{Kayıt mevcutsa ve erişilebilirse dış yol sağlamdır ve arıza başka yerdedir. Kayıt yoksa veya başarısız durumdaysa bakılacak yer bağlantı, ağ geçidi adresi ya da çözümlemeyi engelleyen bir ilkedir. Tüneldeki şifre ayarlarını değiştirmek iki durumda da yardımcı olamaz. Komşu tablosunun bildirdiği durum dizesini not edin, çünkü süren bir denemeyi kalıcı bir arızadan ayırır.}

{Öğrenilmiş bir kayıt bağımlılığı gizleyebilir}

{Önbelleğe alınmış bir kayıt, onu oluşturan şey ortadan kalktıktan sonra bir süre daha çalışır, bu yüzden bir değişiklikten dakikalar sonra yapılan test yanlış nedenle geçebilir. Çözümlemenin gereksiz olduğu sonucuna varmadan önce kaydın eskimesini bekleyin ya da onu bilerek silin.}

{Ters hata da aynı sıklıkta: çözülmemiş bir kayıt tünelin bozuk olduğunun kanıtı sayılır. Pratikte yerel segmente, yinelenen bir adrese ya da yanıtı taşıyan çerçeveleri düşüren bir bağlantı noktası güvenlik kuralına işaret eder. VPN yapılandırmasına dokunmadan önce anahtar bağlantı noktasını denetleyin.}

{Zamanlamayı kanıt olarak okuyun. Çözülüp sonra tekrar tekrar süresi dolan bir kayıt, titreyen bir bağlantıya ya da tek adrese yanıt veren iki aygıta işaret eder; hiç çözülmeyen bir kayıt ise ağ geçidi adresine ya da erişim bağlantı noktasındaki filtrelemeye işaret eder.}

{Dinamik çözümleme ile sabit kayıt arasında karar verin}

{Dinamik çözümleme bir nedenle varsayılandır: ağ geçidi değiştirildiğinde donanımı izler ve kimseyle koordinasyon gerektirmez. Statik kayıt, ağ bilinçli olarak yönetildiğinde ve adres ile donanım adresinin eşleştirilmesi belgelenmiş bir tasarımın parçası olduğunda savunulabilir.}

{Her durumda seçimi dış paketi taşıyan erişim arayüzüne uygulayın. O arayüzde çözümlemeyi kapatmak tüneli sağlamlaştırmaz; istemcinin onu taşıyan ağ geçidine ulaşma yeteneğini kaldırır ve arıza yerel bir adresleme sorunu gibi değil, ölü bir VPN gibi görünür.}

{Diğer yığını da aklınızda tutun}

{IPv6 adres çözümlemesini aynı biçimde kullanmaz; komşu keşfini kullanır. Katman sorusu değişmeden kalır: gerçek dış paket yerel bir sonraki atlamaya nasıl ulaşır ve yanıtın güncel olduğunu ne kanıtlar.}

{Tasarımı tamam ilan etmeden önce aynı iki olguyu diğer yığında da denetleyin, çünkü iki aileyi de taşıyan bir tünelin dikkate alınacak iki dış yolu vardır. Hangisini doğruladığınızı ve hangisini varsaydığınızı kaydedin.}