SSH VPN'de her dakika mı düşüyor? Sorun keepalive değil

SSH bağlanıyor, yaklaşık bir dakika çalışıyor ve sonra her seferinde yaklaşık aynı aralıkla donuyor. Yaygın açıklama boşta kalma zaman aşımıdır, bu yüzden insanlar MTU'yu düşürür ve istemci keepalive'larını ayarlar. Üzerinde çalıştığım WireGuard bağlantısı bunların hepsini zaten yaşamıştı: daha küçük tünel MTU'su, client-alive ayarları, yapılandırılmış tünel keepalive'ı. Kesintiler değişmeden devam etti. Neden asimetrik bir LAN yolu çıktı ve bu kalıp tanınmaya değer çünkü zamanlayıcı tabanlı her düzeltmeyi yeniyor.

Bir keepalive, ana makinenizin hâlâ göndermeye istekli olduğunu kanıtlar. Hiçbir zaman içinden geçmeyen bir yanıtı durum tutan bir cihaza gösteremez.

Mit: keepalive'lar sessiz bir kesintiyi düzeltir

SSH keepalive'ları tek bir iş için vardır: sessizliği sayan bir şeyin boştaki oturumu toplamasını engellemek. Bunu iyi yaparlar. Bir yönde ilk paketi görüp sonra yanıtı hiç görmeyen durum tutan bir cihazın sorununu çözmezler, çünkü istemcinin gönderdiği hiçbir şey yanıtın hangi arayüzü kullandığını değiştirmez.

MTU değişikliği diğer popüler düzeltmedir ve aynı başarısızlık moduna sahiptir. MTU'yu düşürmek parçalanmaya ve yol MTU sorunlarına yardımcı olur, bir rotaya hiçbir şey yapmaz. Zamanlayıcılarınız ve MTU'nuz zaten makul ise ve kesinti hâlâ tekrarlanan aralıkta ise, aralık size bir yerde bir zaman aşımından bahsediyor, paket boyutundan değil. Aralığı not edin ve yoldaki her cihazdaki durum zaman aşımlarıyla karşılaştırın.

İşaret, düzenlilikle birlikte oturumun o aralık içinde kullanılabilir kalmasıdır. Boşta kalma zaman aşımları hiçbir şey olmadığında vurur; bu ise siz yazarken vurur.

Ek ağ geçidi gerçekte ne yapar

Dizüstü bilgisayarı ve VPN ağ geçidini aynı LAN'a koyun, ayrı bir LAN güvenlik duvarını varsayılan ağ geçidi yapın. Dizüstü bilgisayar VPN'e giden trafiği güvenlik duvarına gönderir, güvenlik duvarı onu ağ geçidine iletir ve ağ geçidinin yanıtları doğrudan LAN üzerinden dizüstü bilgisayara döner. O ikinci bacak güvenlik duvarından hiç geçmez, bu yüzden durum tablosu yarım bağlantı tutar.

Aşağıdaki adresler bu düzeni yansıtır:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

Yönlendirmeler ve durum işleme daha sonra çalışan bir el sıkışmayı hemen değil, sonra ölen bir bağlantıya dönüştürür. Gecikme, durum girdisinin yaşlanması veya daha katı bir denetimin başarısız olmasıdır, bu yüzden aralık bu kadar mekanik görünür.

Bunların hiçbiri istemci yapılandırmasında görünmez, bu yüzden onun arayışı genellikle yanlış dosyada başlar.

Tek bir bilinçli yol seçin

Yukarıdaki düzen için uzak alt ağı doğrudan VPN ağ geçidine yönlendirmek yarım bağlantıyı ortadan kaldırır:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

Bunlar örnek adreslerdir. Sonraki atlama LAN'ınızda erişilebilir olmalı, önek amaçlanan uzak ağ olmalı ve ikinci komut ona güvenmeden önce sonucu gösterir. Ağ geçidi alt ağınızda değilse, bu rota istediğiniz düzeltme değildir.

Güvenlik duvarı o sistemler arasındaki trafiği denetlemek içinse, etrafından yönlendirme yanlış tasarımdır. Bunun yerine iki yönün de sınırı geçmesini sağlayın ve dönüş yolunun eşleşmesi için her taraftaki rotaları yapılandırın. Amaç tek bir bilinçli yol, daha az durum denetimi değil.

Netgate'in asimetrik yönlendirme üzerine notlar aynı arayüz düzeyindeki asimetriyi ve yarattığı durum sorunlarını açıklar, bu yüzden durum işlemeyi küresel olarak gevşetmeden önce okuyun. Bu duruma benzeyen zamanlanmış kopmalar kendi başlarına kanıt değildir. Makaleyi tek bir başarısızlık modunun açıklaması olarak ele alın, sonra küresel durum politikasını değiştirmeden önce kendi ağınızın ona uyduğunu kanıtlayın.

İki uçtan test edin

Dizüstü bilgisayarın hedefe doğru rotasını ve hedefin dizüstü bilgisayara doğru dönüş rotasını okuyun; bunlar iki ayrı karardır ve muhtemelen yalnızca biri yanlıştır. Ağ geçidinin kendisinden başarılı olan bir ping sorunu tamamen gizleyebilir, çünkü rotası zaten doğru olan makineden çıkar. Gerçek oturumun iki ucunun gördüğü şekilde iki yöne de ihtiyacınız var.

Düzeltmeden sonra SSH'yi yeniden açın ve oturumu eskiden başarısız olan aralığın çok ötesine kadar açık tutun. Sonra rotayı onaylanmış ağ yapılandırmasında kalıcı yapın, çünkü tek seferlik bir komut yeniden başlatma planı değildir ve sorun bir sonraki yeniden başlatmada yeni bir gizemle geri döner.

Asimetri ne zaman sorun değildir

Asimetrik yönlendirme birçok ağda normaldir ve tanım gereği bozuk değildir. Durum izleme, çeviri veya politika görmedikleri bir yolu görmeye bağlı olduğunda sorun olur ve bunların her birinin farklı bir çözümü vardır. Etrafında yeniden tasarım yapmadan önce orta cihazın gerçekte ne gerektirdiğini kontrol edin.

Kalıcı yanıt iki yolu, ikisini de görmesi gereken cihazı ve bunu mümkün kılan rotayı adlandırır. Cihazı adlandıramıyorsanız nedeni henüz bulamadınız.