OpenConnect kopmuş bir VPN'i ne kadar süre yeniden denemeli?

--reconnect-timeout tek bir dar soruyu yanıtlar: tünel düştükten sonra bu istemci süreci pes edip çıkmadan önce ne kadar süre denemeye devam eder. OpenConnect kılavuz sayfası bu seçeneği, kaybolan bir bağlantıyı veya yanıt vermeyi bırakan bir eşi izleyen yeni denemeler için belgelenmiş 300 saniyelik varsayılanla kaydeder ve bu sayı çalışan tek bir istemci için bir son tarihtir, VPN'in erişilebilir kaldığının kanıtı değildir. Ayrıca süreci canlı tutmaya yönelik bir politika da değildir ve karışıklığın çoğu burada başlar.

Üstüne ikinci bir mekanizma oturunca karışıklık artar. İstemciyi yeniden başlatan bir gözetleyici, ağ geçidine ping atan bir sınayıcı ve yerleşik yeniden deneme penceresi hep birlikte tek bir hataya tepki verebilir ve olay o zaman kimsenin uzlaştıramadığı üç zaman çizgisi üretir.

Yeniden bağlanma penceresi gerçekte neyi sınırlar

Erişim ağının birkaç saniye kaybolduğunu düşünün. İstemci bağlantının düştüğünü görür ya da ölü eşin yanıtlarını duymayı bırakır ve elinden geldiği kadar durumu tutarak oturumu yeniden kurmaya başlar. Denemeler ağ geçidi yeniden kabul edene ya da pencere tükenene kadar sürer ve tükenen pencere sıfır olmayan bir çıkışla sonlanır. Yaşam döngüsünün sahipliğinin süreci gözeten tarafa geçtiği yer, zaman aşımı değeri değil, tam da bu çıkıştır.

Pencere, sınayıcının ne sıklıkta çalıştığı hakkında hiçbir şey söylemez ve kimlik doğrulamayı uzatamaz. Ağ geçidi oturumu iptal ettiyse ya da hesap artık yeni bir ikinci faktör istiyorsa, daha uzun beklemek eski oturumu yeniden geçerli kılmaz. Yeni bir deneme ancak yol geri döndüğünde, ağ geçidi oturumu hâlâ tanıdığında ve istenen kimlik bilgileri kullanılabilir kaldığında başarılı olur; bu yüzden sayıyı canlılık aralığı değil, son tarih olarak okuyun.

Pencere, çalışırken uygulamaların ne yaptığını da düzenlemez. Platforma ve hatanın ne kadar ilerlediğine bağlı olarak istemci, yollar hâlâ kuruluyken ya da yollar kaldırıldıktan sonra yeniden bağlanıyor olabilir. Bu yüzden kesintinin ortasında verilen bir istek hızla başarısız olmak yerine zaman aşımına kadar asılı kalır.

Gözetleyici yeniden başlatmaları ile istemci denemeleri iki katmandır

Çalışan istemci kendi penceresini harcasın, hizmet yöneticisi de çıkışa tepki versin. systemd altında yeniden başlatma politikası olan ön plandaki bir istemci tam olarak bu bölünmeyi verir: sınırlı bir süre deneme, sonra tek bir yeniden başlatma kararı. Sonuç, sonradan hâlâ yeniden kurabileceğiniz tek bir zaman çizgisidir.

Arka planda çalışan bir istemci artı arayüz göremediğinde başka bir kopya başlatan bağımsız bir yoklayıcı, yanlış giden kalıptır. O zaman iki süreç aynı aygıt düğümü, yollar ve çözümleyici ayarları için yarışır. Gerçekten bir artalan süreci istiyorsanız, seçeneği istemcinin gerçekte başladığı komut satırına koyun:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

O satırdaki iki ayrıntı ağırlık taşır. --background süreci ayırır, böylece pid dosyası onun üzerindeki tek güvenilir tutamak olur ve zaman aşımı yalnızca aynı süreç yaşadığı sürece harcanır; onu öldüren gözetleyici devam etmek için bütçe bırakmaz.

Amaçlı bağlantı kesintilerinin kendi sinyaline ihtiyacı vardır. Planlı bir duraklama ile gerçek bir kesinti saf bir gözlemciye aynı görünür ve ikisi de «bağlı değil» diye okunur. Duraklamayı gözetleyicinin durdurma işlemi ya da sarmalayıcının anladığı bir işaret üzerinden yürütün; böylece bilinçli bir duruş kimsenin istemediği bir yeniden başlatmayı tetiklemez.

Devri yeniden deneme döngüsüyle yarıştırmamak

Gözetimsiz toparlanma, yanında kimse yokken yenilenen kimlik bilgilerine bağlıdır. Yalnızca etkileşimli bir masaüstü oturumu içinde açılan bir anahtarlık ya da her zaman yazılan kod isteyen bir jeton, yol geri geldiğinde istemciyi kimlik doğrulama aşamasında bırakır. Pencereyi uzatmadan önce bu iş akışını düzeltin, çünkü daha uzun bir pencere yalnızca aynı engellenmiş isteme daha fazla başarısızlık süresi verir.

Sunucu doğrulaması, istemleri azaltmak için gevşetilmemelidir. Ağ geçidini doğrulayan pin ya da güven çapası, otomatik yeniden bağlanmayı güvenli kılan şeydir ve sertifika sorusundan kaçınmak için onu devre dışı bırakmak, görünür bir kesintiyi görünmez bir kesintiyle değiştirir. Doğrulanmış kimliği koruyun ve bunun yerine istemi onarın; herhangi bir ağ geçidine bağlanmaya razı bir istemci, durup bekleyenden daha kötüdür.

Arayüzün varlığı da sağlık sinyali değildir. Tünel aygıtı arkasında ölü bir oturumla var olabilir ve başlatıcı süreç hiç tünel olmadan var olabilir. Bu gözlemlerin hiçbiri gerçek bir isteğe dayanmaz. Sağlık, kullanıcının ihtiyaç duyduğu şeyden gelmelidir; örneğin tünelden bilinen bir iç hizmete giden bir istekten.

Kesinti sırasında ve sonrasında ne doğrulanmalı

Dört olayı ayrı testler olarak çalıştırın: pencereden kısa bir kesinti, ondan uzun bir kesinti, bir kimlik doğrulama hatası ve amaçlı bir durdurma. Her biri farklı ve öngörülebilir bir durumda bitmelidir ve ilk ikisi arasındaki sınır, bir değer seçmenin tüm nedenidir.

Denetimleri dışa dönük tutun, çünkü süreç tablosu tek başına çok az şey kanıtlar. pid'in kısa kesinti boyunca sabit kalıp kalmadığını izleyin, ardından uzun olanın ardından gittiğini ve bir kez değiştirildiğini doğrulayın:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Kısa kesinti sırasında istemcinin gerçekten yeniden denediğini, erken çıkmadığını ve yollar ile çözümleyici girdilerinin yinelenmeden geri geldiğini doğrulayın. Daha uzun kesinti için temiz bir çıkış ve ardından tam olarak bir yeniden başlatma olduğunu doğrulayın. Kimlik doğrulama hatası için istemcinin onu reddetmeye devam edecek bir ağ geçidine karşı boşuna dönmediğini doğrulayın. pid'in birikmek yerine tek bir değere döndüğüne dair bir denetim ekleyin.

Amaçlı durdurma için sağlık URL'si erişilemez kalmalı ve süreç kapalı kalmalıdır. Ardından döngüyü uygulama tarafından kapatın: aynı istek tünel yokken başarısız olmalı ve geri geldikten sonra politikanızın beklediği kaynak adresinden başarılı olmalıdır. Yeşil tünel simgesi kanıt değildir, ancak tamamlanmış bir istek kanıttır.