Eşit maliyetli yollar VPN arızalarını neden görünmesi zor hale getirir
Birden fazla tünel aynı maliyeti paylaştığında her akış farklı birini seçebilir. Başarılı bir ping, uygulamanızın gerçekte kullandığı yol hakkında hiçbir şey söylemez.
Bir kullanıcı, dahili uygulamanın bir makineden çalıştığını ve başka bir makineden başarısız olduğunu bildiriyor; oysa ağ geçidinden çalıştırdığınız ping her iki durumda da başarılı. Aynı maliyette birden fazla tünel olduğunda bu bir çelişki değildir. Her akış kendi sonraki atlama noktasına yerleştirilir, bu yüzden testiniz ve kullanıcının oturumu yalnızca farklı yollar kullanıyor olabilir. Aşağıdaki inceleme, herhangi bir şey değiştirilmeden önce bu seçimi yeniden üretir.
Tek ping, birden çok olası yol
Bir rotanın aynı maliyette birden fazla sonraki atlaması olduğunda yönlendirici her paket için birini seçmek zorundadır. Çoğu uygulama paketin alanlarını karma işleminden geçirir; genellikle kaynak ve hedef adresleri protokol ve bağlantı noktalarıyla birlikte, böylece yanıtlar aynı yolda kalır. Farklı uygulamalar, hatta bir uygulamanın farklı bağlantıları farklı karmalar üretir.
Ağ geçidinden yapılan bir tanılamanın bu kadar az kanıtlamasının nedeni budur. Ağ geçidinin kendi testi kendi adreslerine ve bağlantı noktalarına, dolayısıyla kendi karmasına sahiptir. Sağlıklı tünele düşebilirken kullanıcı bozuk tünele düşmeye devam eder.
Platform sonraki atlamayı nasıl seçer
Seçimi tahmin etmek yerine yeniden üretin. Çekirdeğe, başarısız oturumla aynı kaynak ve hedef için hangi rotayı kullanacağını sorun. Bu arama, sıradan bir hedef aramasının yok saydığı alanları içerir. Çalışan bir istemciden de çalıştırın ve iki yanıtı karşılaştırın:
ip route get 10.20.5.7 from 10.20.0.14Daha yeni iproute2 sürümleri protokolü ve hedef bağlantı noktasını da kabul eder; bu, karma bunları içerdiğinde önemlidir. Bu çıktıyı çalışan bir istemciden yapılan aynı aramayla karşılaştırın; fark, eksik olan kanıtınızdır.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
Başarısız akışı izleyin, rota tablosunu değil
Rota tablosu iki tüneli de listeler ve tanım gereği doğru görünür. Soru, seçildikten sonra her tünelin paketle ne yaptığıdır. İkisinin de aynı korunan ön ekleri, aynı iletme iznini ve aynı istemciye ulaşan bir dönüş yolunu taşıdığını doğrulayın.
Ortadaki durum tutan cihazlara dikkat edin. Bir istek bir tünelden çıkıp yanıt diğerinden dönerse, özgün akışı hiç görmemiş bir güvenlik duvarı veya NAT onu düşürür. İki tünel de trafiği doğru iletiyor ve bağlantı yine de başarısız oluyor.
Yol başına MTU’yu da kontrol edin. Ek kapsülleme içeren bir yol kullanılabilir boyutu küçültür ve bir tünelde başarılı olan aktarım diğerinde tam olarak küçük olanın kırıldığı boyutta takılır.
Her seferinde bir yolu karşılaştırın
Tasarımın bakıma izin verdiği yerlerde bir tüneli hizmetten çıkarın ve kullanıcının görevini yineleyin. Arıza kaybolursa sorun çıkardığınız yola aittir ve sonraki adım, yönlendirme tablosunu yeniden incelemek yerine yapılandırmasını komşusununkilerle karşılaştırmaktır.
Tekrarlanan pingleri değil, gerçek uygulamayı karşılaştırın. Arızanın belirli bir sonraki atlamayı, paket boyutunu veya yeniden bağlanma sonrası bir geçişi izleyip izlemediğini kaydedin; çünkü bu üç örüntü farklı onarımlara işaret eder.
Son olarak, yolların neden eşdeğer sayıldığını ve bir arızanın birini hizmetten nasıl çıkarması gerektiğini yazın. Çok yollu yönlendirme yalnızca yollar gerçekten birbirinin yerine geçebiliyorsa güvenlidir ve bu, varsayılacak değil doğrulanacak bir tasarım ifadesidir.