Bir VPN birimi neden ağdan önce başlar ve sonra ölür

Bağlantının adresi olmadan başlayan bir birim rastgele görünen bir biçimde başarısız olur. Sırayı günlükten kanıtlayın, ardından beklemeyi ve yeniden denemeyi ekleyin.

Makineyi başlatın, oturum açın ve tünelin yükseldiğini ve birkaç saniye sonra öldüğünü öğrenin. Profil sorunsuzdu, sertifika sorunsuzdu ve geriye kalan tek iz o önyüklemenin günlüğüdür. Genellikle olan şey bir yarıştır: birim, makinenin bir adresi olmadan önce başladı ve bildirdiği sıra göründüğü anlamı taşımıyordu. Aşağıdaki her şey, bu yarışı kanıtlardan kanıtlamak ve düzgün bir şekilde kapatmakla ilgilidir.

Hedef bir buluşma noktasıdır, yönetici değil

network-online.target ağın ne olduğu hakkında hiçbir fikre sahip değildir. Bağlantı kullanılabilir olana kadar başlangıcı geciktirmesi gereken hizmeti toplayan bir koordinasyon noktasıdır ve tanımı makineye sahip olan ağ yöneticisine devreder. Çoğu masaüstünde ve sunucuda bu, NetworkManager veya systemd-networkd tarafından sağlanan bir bekleme hizmeti anlamına gelir. Hiçbirini etkinleştirmezseniz hedefin bekleyecek bir şeyi olmaz, bu yüzden bir şey onu içeri çektiği anda tamamlanır ve bu DHCP yanıtından çok önce olabilir. Biriminizdeki sıra satırı dürüsttü ve yine de işe yaramazdı.

Dolayısıyla ilk soru biriminizin ne bildirdiği değildir. Bu makinede bir şeyin gerçekten beklemeyi yapıp yapmadığıdır.

Birim dosyası yerine son önyüklemeyi okuyun

Birim dosyaları niyeti tanımlar ve günlük ne olduğunu tanımlar. Yalnızca o önyüklemeyi isteyin, her mesaj tek bir saatte oturacak şekilde monoton zaman damgalarıyla. Sonra iki satır bulun: tünel biriminin başlamaya başladığı an ve adresin göründüğü veya bekleme hizmetinin bittiği an. Bu iki sayıyı sıralayın; yarış ya doğrulanır ya da dışlanır.

Bağımlılık görünümü bunu doğrular. Tünel birimi için kritik bir zincir herhangi bir bekleme hizmeti içermiyorsa, o yolda hiçbir şey başlangıcı geciktirmedi ve hedef varsaydığınız işi yapmadı. İki görünüm, tek sonuç.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Beklemeyi ekleyin, sonra yeniden denemeyi

Paketlenmiş bir birimi düzenlemek yerine drop-in kullanın, böylece bir paket güncellemesi değişikliği sessizce atmasın. İki yönerge önemlidir: birim hedeften sonra sıralanmalı ve hedefi aynı işleme çekmelidir. Yalnızca sıralama hedefi çağırmaz; bunu istek yapar.

OpenVPN istemcisinin paketlenmiş birimi ikisini de zaten taşır. Elle yazılmış birimler genellikle birini ya da hiçbirini taşır; bu, bir şey eklemeden önce kontrol etmeye değer.

[Service]
Restart=on-failure
RestartSec=15

Neden sabit bir uyku tuzaktır

ExecStartPre içindeki bir uyku sıra düzeltmesi gibi hissettirir ve ek adımlarla bir gecikme gibi davranır. Sağlıklı olanlar da dahil her önyüklemeyi yavaşlatır ve bağlantı seçtiğiniz sayıdan daha uzun sürdüğünde yine kaybeder.

Daha kötüsü, bekleme hizmetinin çalışıp çalışmadığını gizler, bu yüzden sonraki arıza aynı sorunun farklı zamanlaması olarak değil, tamamen yeni bir sorun olarak görünür. Kısa bir yeniden başlatma gecikmesi daha iyi araçtır: sağlıklı bir önyüklemede hiçbir maliyeti yoktur ve kaybedilen yarışı bir denemeye daha dönüştürür. Aralığı ölçülü tutun ve birimin başarılı olmasına izin verin. Sonsuza kadar yeniden başlıyorsa profil bozuktur ve ne kadar yeniden deneme yapılırsa yapılsın bu değişmez, bu yüzden aralığı yükseltmek yerine günlüğü okuyun.

Sıra doğruyken adlar yine de başarısız olduğunda

Tünel rotası olan etkin bir birim, sıralamanın işini yaptığı ve kalan hatanın bir katman yukarıda olduğu anlamına gelir. Olağan biçim, bağlantı ya da çözümleyici onu tutmaya hazır olmadan önce tünelin up betiğinin uyguladığı bir çözümleyici ayarıdır. Arıza sırasındaki çözümleyici durumunu tünel birimini yeniden başlattıktan sonraki durumla karşılaştırın.

Yeniden başlatma aramaları düzeltiyorsa, yanlış DNS sunucusu değil başlangıç sırası kusuru var ve bu ikisi farklı düzeltmeler gerektirir. Sonra her şeyi hizmeti yeniden başlatmak yerine soğuk önyüklemeyle kanıtlayın, çünkü yeniden başlatma zaten ayakta olan bir ağa karşı çalışır ve tam olarak kovaladığınız kusuru gizler. Bağlantıyı kasıtlı olarak yavaşlatarak tekrarlayın ve yalnızca ağ hızlıyken çalışan bir birimi hâlâ bozuk sayın.

İlgili makaleler