Çalışan bir VPN neden yine de yanıtta zaman aşımına uğrar
Bir isteğin özel bir sunucuya ulaşması alışverişin yalnızca yarısıdır. Yanıtının tünel istemcisini amaçlanan ağ geçidi, yol veya çeviri üzerinden bulması gerekir.
İstek gelir, sunucu onu kaydeder ve istemci yine de zaman aşımı bildirir. Bu bileşim şu anlama gelir: yanıt geri dönüş yolunu bulamadı, ve bu, iki uçtan aynı anda doğrulayabileceğiniz birkaç arızadan biridir. Kontrolleri sırayla yapın ve biri başarısız olduğunda durun.
İsteğin nereye geldiğiyle başlayın
Başka bir şeyi incelemeden önce paketin hizmete ulaştığını doğrulayın. Sunucu tarafındaki bir günlük kaydı, bir bağlantı sayacı veya uzak uçta izin verilen bir yakalama aynı soruyu yanıtlar; bunların yokluğu sizi yanıta doğru değil tünele geri gönderir. Bu, yönlendirme sorununu dönüş yolu sorunundan ayıran kontroldür.
İstek hiç gelmediyse burada durun. Tünel, özel öneke giden yönlendirme veya erişim kuralı konudur ve yanıt yolu henüz ilgili değildir. Sunucunun gördüğü kaynak adresini de not edin. Bu ya istemciye verilen havuz adresidir ya da çevrilmiş bir adrestir ve bu fark sonraki kontrollerden hangisinin geçerli olduğunu belirler.
Yanıtın havuza bir yolu olmalı
Uzaktan erişim istemcisi genellikle bir havuzdan adres alır ve özel ağın o havuza dönüş yoluna ihtiyacı vardır. Varsayılan yolu kendi ağ geçidine işaret eden bir sunucu, paketi o ağ geçidine verir; ağ geçidi havuzun nerede olduğunu bilmez, bu yüzden yanıt orada ölür. İstemci zaman aşımı görür çünkü hiçbir şey geri gelmemiştir ve bu, hiç çıkmamış bir istekten ayırt edilemez.
Sunucunun kendi alt ağı için kullandığı yolu değil, istemci adresi için seçtiği yolu denetleyin. Bu iki arama farklı yanıtlar üretebilir ve burada önemli olan ikincisidir. Çeviri alternatif tasarımdır ve sunucunun gördüğünü değiştirir. Dönüş yolunu basitleştirebilir ve ayrıca özgün istemci adresini sunucu günlüklerinden kaldırır; bu da o alan üzerine kurulmuş her kuralı veya raporu etkiler.
Sunucudaki yakalamayı ağ geçidindeki yakalamayla karşılaştırın
Sunucudan çıkanı ağ geçidine gelenle karşılaştırın. Sunucunun giden arayüzündeki yakalama ile tünel ağ geçidindeki yakalama sorunun farklı yarılarını yanıtlar ve aralarındaki boşluk kaybın yerini gösterir.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
Ağ geçidinin kendi ürettiği istek, istemci testinin zayıf bir yerine geçenidir; çünkü başka bir adresten gelir ve başka kurallarla karşılaşır. Bu yüzden ağ geçidinden başarılı bir ping ile istemciden başarısız bir istek aynı anda doğru olabilir.
Yolda birkaç yönlendirici varsa, havuza yolu gereken her birini denetleyin. Sahadan sahaya tasarım, uzak önekin birden fazla cihazda bilinmesini gerektirir ve ağ geçidinin kendisi tünel ile yerel ağ arasında iletmelidir; strongSwan'ın yönlendirme notları bunun sysctl ve güvenlik duvarı tarafını kapsar.
Havuzu, öneki ve sorumluyu kaydedin
Nota dört olgu girer: istemcinin aldığı havuz, gereken özel önek, yanıttan sorumlu yönlendirici ve varsa çeviri kuralı. Bunlarla sonraki bir ağ geçidi değişikliği soruşturma değil karşılaştırmadır.
Ardından sıradan bir istemci ve uygulamanın gerçek hesabıyla yeniden test edin. Uygulama ayrıcalıklarını genişletmek bir paketin dönüş yolunu onaramaz ve bu tanılama sırasında yapılan hesap değişikliği sonraki karşılaştırmayı karıştırır. Tasarım çeviriye dayanıyorsa, sunucu günlüklerinin okunduğu yerde belgeleyin. Denetim izinde tanımadık bir kaynak adresi gören kişi, eşlemeyi bir kayıttan yeniden keşfetmek zorunda kalmamalıdır.