VPN'iniz neden kesintiden daha uzun sürede toparlanıyor

Wi-Fi otuz saniye önce geri geldi ve VPN hâlâ kapalı, bu yüzden istemci bozuk görünüyor. Çoğu zaman yalnızca kendi yeniden deneme takvimini izliyordur ve o takvim ağın az önce geri geldiğini bilmez. Bu boşluk tüm hikâyedir: toparlanma süresi, kesinti artı istemcinin hâlihazırda kabul ettiği herhangi bir bekleme süresidir. Her zamanlayıcıyı düşürmek bir yanıttır, hangi zamanlayıcının önemli olduğunu anlamak ise diğeri.

Üç koşul ayarlamanın yardımcı olup olmayacağını belirler: hangi aşama yavaş, hata hiç yeniden denenebilir mi ve istemci ağın geri döndüğünü nasıl öğrenir.

Tek gibi görünen üç bekleme

Uç nokta çözümlemesi, IKE veya TLS görüşmesi, paket yeniden iletimi ve yeni bir deneme başlatma ayrı zamanlayıcılara sahip ayrı olaylardır. strongSwan, IKE için yeniden iletim geri çekilmesini belgeler ve OpenVPN farklı anlamlara sahip kendi yeniden deneme denetimlerine sahiptir. Bir sayıyı birinden diğerine kopyalamak mekanizmaların uyuştuğunu varsayar, oysa uyuşmazlar. Hangi aralığa baktığınıza karar vermeden önce günlük sırasını okuyun.

Günlükteki sessiz bir dakika mutlaka donmuş bir süreç değildir. Ayarlandığı şeyi tam olarak yapan üstel bir geri çekilme olabilir.

Hangi aşama aslında yavaş?

Günlük, kimlik doğrulama hatasıyla başarısız olan denemeler gösteriyorsa hiçbir zamanlayıcı değişikliği yardımcı olmaz, çünkü kimlik bilgisi yanlıştır. Denemeler hiç yapılmıyorsa istemci bekleme penceresindedir ve çözüm takvimdir. Denemeler yapılıp zaman aşımına uğruyorsa sorun erişilebilirlik veya eksik dinleyicidir ve daha hızlı yeniden denemek yalnızca günlüğü doldurur. Bu üç durumun her birinin farklı bir sorumlusu vardır ve yalnızca biri zamanlama sorunudur.

Bir sayıya dokunmadan önce hatayı sınıflandırın.

Zamanlayıcıyı düşürmek ne zaman yardımcı olur, ne zaman olmaz

Baskın maliyet kısa ve sık bir kesintiden sonra beklemekse yeniden deneme üst sınırını düşürün, örneğin erişim noktaları arasında hareket eden bir dizüstü bilgisayar. Hatalar uzun veya seyrekse ona dokunmayın, çünkü saldırgan yeniden deneme, yoğunlaştırıcının yanıt vermeye en az muktedir olduğu anda yük ekler. Her iki durumda da tek bir parametreyi değiştirin, kaydedin ve iyileştiğini varsaymak yerine bir sonraki toparlanmayı ölçün.

Her profile kopyalanan çok düşük bir zaman aşımı, ölçüm olmadan ayarlamanın olağan son durumudur.

İstemciyi suçlamadan önce hazır oluşu denetleyin

İstemci, bir şey deneyene kadar ağın kullanılabilir olduğunu genellikle göremez. Bir tutsak portal, DHCP yenilemesi veya rota değişikliği onu tüm bunlar olmadan önce belirlenmiş bir takvimde bekletmeye bırakabilir. İşletim sisteminin ağ durumu değişikliğini ve istemcinin sonraki denemesini aynı saatte izleyin, kimin beklemesi olduğunu göreceksiniz. Hızlı sürüm, ağ hazır olayının zaman damgasını ve ardından gelen ilk denemenin zaman damgasını not etmektir.

Bekleme sırasında doğrudan trafiğin hâlâ engellendiğini de doğrulayın, çünkü trafik sızdıran daha hızlı bir yeniden bağlanma iyileştirme değildir.

Neyi kaydetmeli

Hangi zamanlayıcının değiştiğini, hangi değerden hangi değere ve sonrasında toparlanmanın nasıl göründüğünü yazın. İstemci sürümünü de not edin, çünkü varsayılanlar sürümler arasında kayar ve belgelenmemiş çok düşük bir zaman aşımı profili okuyacak sonraki kişiyi şaşırtır.

Bu kayıt, bir sonraki yazılım yükseltmesini deney yerine karşılaştırmaya dönüştürür.