İki saniyelik donma: sorun VPN miydi yoksa Wi-Fi mi?

Kendiliğinden düzelen iki saniyelik bir donma, tünel yeniden müzakere etmiş olsun ya da radyo tökezlemiş olsun aynı görünür. Hiçbir şeyin düşmemiş olması da mümkündür ve bu olasılığı önce test etmeye değer. Kısa bir kayıp patlaması, yeniden müzakere ve uygulama takılması klavyedeki kişiye aynı hissi verir. Üç durumdan yalnızca biri tünel yapılandırması değiştirilerek düzeltilir.

İki kayıt, bir değil

Alttaki bağlantıya ne olduğunu ve ayrı olarak tünelin kendisinin ne yaptığını yazın. Ardından uygulamanın duraklamasını iki kaydın karşısına koyun. Bunlar bazen çakışan bağımsız olay dizileridir ve üçünü birden bağlantı kopması olarak adlandırmak, yanıtı en baştan varsaymak demektir.

Dakikada bir kez yoklayan bir izleyici iki saniyelik kesintiyi göremez. O günü sağlıklı diye bildirmek teknik olarak doğru, pratikte faydasızdır. Alıntıladığınız her sonucun yanına örnekleme aralığını yazın.

Uygulama donarken erişim bağlantısı ne yaptı

Örnekleme aralığı ve zaman aşımı, izleyicinin neyi gözlemleyebileceğini belirler, bu yüzden ikisini de sonucun yanına kaydedin. Cihaz her altmış saniyede örnek aldığında kayıtlı kesinti yokluğu pek bir şey ifade etmez. Ardından zaman damgalarıyla üç yeri yoklayın: yerel yönlendirici, basit yoldan ulaşılan onaylı bir dış sunucu ve tünelin arkasındaki bir kaynak.

Önce yolları doğrulayın, çünkü ortak bir hedef kendisi tünelden yönlendirilebilir ve o zaman erişim yolunu değil tüneli ölçer. Kesintiyi gerçekten tarihlendiren kanıtlar bir katman aşağıdadır: yönlendiricideki bağlantı olayları, modemdeki yeniden eşitleme kayıtları ve değişen WAN adresi. Kümülatif hata sayacı bir şeylerin ters gittiğini söyler, ne zaman olduğunu asla söylemez. Bu kayıtları tek başına okumak yerine olay penceresiyle ilişkilendirin.

ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address show

Dün artan bir sayaç bu sabahki donma hakkında hiçbir şey açıklamaz. Korelasyonu kullanıcının bildirdiği pencereyle sınırlayın.

Yeniden başlatma kaydını arayın

Kaybolan bir UDP datagramı tek başına Community OpenVPN'in yeni bir TLS müzakere başlatmasına neden olmaz. Yeniden başlatma davranışı ping-restart ayarını izler ve yürürlükteki değer sunucu tarafından dayatılmış olabilir; 2.6 kılavuzu bu zamanlayıcıları tanımlar. Teslimat bir an kesilir, eşik hiçbir zaman aşılmaz ve günlük boş kalır. Bu yüzden günlükte duraklamanın çevresinde yeniden başlatma satırı, yeni bağlantı veya değişmiş oturum tanımlayıcısı arayın. Üçünden hiçbiri görünmüyorsa tünel muhtemelen hiçbir şey yapmadı ve zamanlayıcı hiçbir zaman sorun olmadı.

Her keepalive'ı kısaltmak algılamayı daha hızlı gösterir ve küçük bir tökezlemenin yeniden bağlanmaya dönüştüğü çizgiyi kaydırır. Her yeniden bağlanma bir kimlik doğrulama turu ve yolların yeniden kurulması maliyetindedir. Zamanlayıcıyı uzatmak, ölü bir yolun hâlâ canlı göründüğü daha uzun bir pencereden başka bir şey satın almaz. İkisi de bedeli olan ayar kararlarıdır, bedava iyileştirmeler değil.

Olmayan bir olay da kanıttır ve insanların atladığı tür tam da budur, çünkü günlükte hiçbir şey ona dikkat çekmez. Yaptığınız aramayı yazın, yalnızca sonucu değil.

Neyin düzeltileceğine karşılaştırma karar versin

İki kayıt yan yana geldiğinde atama genellikle kendini yazar. İki yolda da yönlendirici bağlantı olayı varsa konu erişim bağlantısıdır. Sessiz bir tünel ve kullanılabilir basit bir yol varsa konu müzakeredir.

Her satır bir ipucudur, hüküm değil: uç noktalar ICMP önceliğini düşürür ve iki hedef mutlaka aynı yolu paylaşmaz. Karşılaştırmanın mümkün olması için istemci, ağ geçidi ve uygulama saatlerini hizalı tutun. İki sütuna sığan bir satır bir gözlem daha gerektirir, karar değil.

İncelemeden geçen bir rapor dört şeyi yanıtlar: donma ne kadar sürdü, hangi yollar yanıt vermeye devam etti, tünel o saniyede ne kaydetti ve izleyici ne sıklıkta örnek alıyor. Bu dört olgu, sonraki okuyucunun bir özete güvenmek yerine gözlemi yeniden üretmesini sağlar. Çalışma süresi yüzdesi tam da önemsediğiniz aralığı gizler; "VPN düştü" ifadesi de öyle.