Özyinelemeli yönlendirme: tünel kendi paketlerini yakaladığında
Bir tünel kendisini oluşturan paketleri yakalayabilir. Varsayılan yol değişmeden önce ve sonra sunucuya giden yolu karşılaştırın, ardından o yolun sahibini düzeltin.
Tünel ayağa kalkıyor, günlük tamamlanmış bir el sıkışması gösteriyor ve bir saniye sonra aynı oturum ölüp döngü içinde yeniden bağlanıyor. Bu örüntünün belirli bir nedeni var: sunucuya giden yol artık tünelin içini gösteriyor, bu yüzden tüneli taşıyan paketler tünelin içinden gönderiliyor. Kimlik doğrulamada hiçbir şey değişmedi, bu yüzden kimlik bilgilerini yeniden girmek bir fark yaratmıyor. Yol değişmeden önceki ve sonraki dış yolu karşılaştırın, özyineleme görünür hale gelir.
Önce dış yolu denetleyin
Oyunda iki paket var, bir değil. İç paket uygulamaya aittir ve şifrelenmelidir; dış paket ise sunucuya adreslenmiştir ve ona tünele bağlı olmayan bir yoldan ulaşmalıdır.
ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints
Tünel ayağa kalktıktan sonra çekirdeğe sunucunun adresine giden yolu sorun, varsayılan yol değiştikten sonra bir kez daha sorun. Tünel aygıtına inen bir sonraki atlama özyinelemenin ta kendisidir ve herhangi bir paket yakalaması olmadan görülür. Arabirime bağlama, işaretler veya ağ ad alanı sıradan bir aramayı eksik bırakabilir, bu yüzden istemcinin kendi kullandığı bağlamı kullanın. Yanıt doğru görünüyor ama oturum hâlâ döngüdeyse, yalnızca ana tabloyu değil yönlendirme ilkesinin kurallarını okuyun.
Oturum neden bir an ayakta kalır
El sıkışma yeni yol kurulmadan önce tamamlanır, bu yüzden ilk saniyeler sağlıklı görünür. İstemci varsayılan yolu eklediği anda bir sonraki dış paket onu izleyerek geçmesi gereken arabirime girer. Sunucu hiçbir şey görmez, istemci yeniden gönderir ve deneme ya zaman aşımına uğrar ya da oturumu öldürüp baştan başlar.
Bu sıralama, tünelin neden dizüstü bilgisayarda çalışıp yönlendiricide başarısız olduğunu ve arızanın neden bağlantı anında değil trafik başladığında sık başladığını açıklar. Döngüyü de açıklar: her yeniden başlatma, yol bunu olanaksız kılmadan önce oturumu yeniden kurar.
Uç noktanın istisnasının sahibini bulun
Desteklenen istemciler kendi istisnalarını kendileri düzenler: özgün ağ geçidi üzerinden sunucuya bir ana makine yolu ya da dış soketi tünelin dışında tutan bir işaret. Soru, başka bir şeyin onu kaldırıp kaldırmadığı ya da geçip geçmediğidir.
Yol tabanlı IPsec'te hangi paketlerin tünele girdiğine karar veren ilke seçicilerini inceleyin ve eşin adresinin bunların dışında bırakıldığını doğrulayın. WireGuard'da arabirimin güvenlik duvarı işareti ve ilke kuralları taşıma paketlerini tünelin dışında tutar, bu yüzden elle eklenen bir varsayılan yol bu düzeni bozabilir. İkinci bir VPN profili veya varsayılan yolu yeniden yazan bir yönetim betiği sık görülen suçludur. Tek tek eklenen geniş atlama kuralları olağan sonuçtur ve bir yönlendirme hatasını kimsenin sürdüremeyeceği bir tabloya dönüştürürler.
Ağ değişikliğinden sonra yeniden denetleyin
Bir Wi-Fi ağ geçidi üzerinden giden ana makine yolu, makine başka bir ağa taşınana kadar doğrudur. Sonra aynı belirti hiçbir yapılandırma değişikliği olmadan geri döner.
Uç noktanın adresini, bağlanmadan önceki ve sonraki yolu ve her birinin kullandığı arabirimi not edin. Bu üç olgu genellikle istemci hatasını geçilmeden ayırır ve bunları toplayan kişi ayrıldıktan sonra da kalır.
Yeni ağda yeniden bağlanın ve okumayı yineleyin. İstisna yine yoksa düzeltme onu barındıran profile aittir, kesinti sırasında yazılan tek seferlik bir komuta değil.