İstemciyi açılışta başlatıyorsunuz, birim etkin bildiriyor ve tünel yok. Doğal sonuç hizmetin başlamadığı, doğal çözüm onu yeniden başlatmaktır. İkisi de bir kuralı hak edecek kadar sık yanlıştır: yeniden deneyen çalışan bir istemci dışarıdan tam olarak bozuk bir istemci gibi görünür. Fark sürecin ne yaptığındadır, birimin durumunda değil.

Mit: başlatılmış hizmet çalışan bir tünel demektir

Etkin bir birim sürecin başlatıldığını ve çıkmadığını kanıtlar. Profilin yüklendiğini, sertifikanın kabul edildiğini veya karşı ucun yanıt verdiğini kanıtlamaz. Paketlenmiş bir istemci dakikalarca yeniden deneme döngüsünde oturabilir, systemd ise başarıdan başka bir şey bildirmez. Durum ile davranış arasındaki bu boşluk konunun tamamıdır.

Ters durum da aynı ölçüde yaygındır. Süreç bir anahtarı okuyamadığı için çıkmış olabilir ve birim sonra nedenini söylemeyen bir hata durumu bildirir. İki durumu ayırmak için günlük gerekir.

Birimin durumu yerine o örneğin günlüğünü okuyun. Neden satırı günlükte, durum etiketinde değil.

Mit: yeniden deneme ayarları her arızayı kapsar

Ad çözümleme ve taşıma yeniden denemeleri ayrı varsayılanları olan ayrı denetimlerdir. resolv-retry uzak bir ana makine adının yinelenen aramalarını yönetir ve belgelenen varsayılan süresiz denemeye devam eder. connect-retry denemeler arasındaki aralığı belirler, connect-retry-max ise her uzak girdinin kaç kez deneneceğini sınırlayabilir. Bunlardan herhangi birini değiştirmeden önce günlüğün hangi aşamayı adlandırdığını kontrol edin.

Bunların hiçbiri bozuk bir profil, okunamayan özel anahtar veya reddedilen hesap için geçerli değildir. Onlar düzeltme gerektirir ve onları yeniden denemeye devam eden istemci ilerlemez.

Onaylanmamış bir sertifikayı sonsuza kadar yeniden denemek doğrulamayı kaldırmak için gerekçe değildir. Hatayı okumak için gerekçedir.

Mit: bir başlatıcı yeter, o yüzden bir tane daha ekleyin

Zaten NetworkManager veya paketlenmiş bir birim tarafından yönetilen bir bağlantının ikinci bir başlatıcıya ihtiyacı yoktur. Aynı yollar için yarışan iki süreç yinelenen arayüzler, kafa karıştıran günlükler ve kimsenin göremediği nedenlerle sürekli inip kalkan bir tünel üretir. İkinci kopya genellikle birincisi yavaş olduğu için geçici çözüm olarak gelir.

Tünelin hangi bileşene ait olduğuna karar verin, herhangi bir şey eklemeden önce. Sonra diğer başlatıcıyı devre dışı bırakıp ummak yerine kaldırın.

Sahip, yeniden denemelerin ve kimlik bilgilerinin nereden geldiğini de belirler, bu yüzden bu karar herhangi bir ayardan önce gelir. Sahiplik tam da bu nedenle önce gelir.

Gerçekte neyin sıraya ihtiyacı var

Sıra yapılandırılmış bir adresi bekleyebilir ve garanti ettiği tek şey budur. network-online.target etkinleştirmeyi yönetici ağı hazır sayana kadar geciktirir ve hazır tanımı yöneticiye bağlıdır. VPN ana makine adının çözülüp çözülmediği, dinleyicinin yanıt verip vermediği veya bir yakalama portalının cihazı içeri alıp almadığı hakkında hiçbir şey söylemez.

Bağımlılık eklemeden önce kurulu birimi ve varsa drop-in dosyalarını okuyun. Her ağ hizmetinde geniş bir After= gerçekten ihtiyaç duyduğunuz bağlantıyı kurmadan açılışı geciktirir.

Test edebildiğiniz bağımlılığı sıraya koyun, geri kalan her şeyi bir hazırlık yoklamasıyla denetleyin. Tüneli açan bir yoklama tahmin eden bir zamanlayıcıdan iyidir.

Tünel ilk kez kalktıktan sonra ne olur

Açılış pek çok olaydan biridir. Erişim bağlantısı değişir, bir portal oturumu sona erer, eş yeniden başlar. İçsel yeniden bağlanmayı hizmet yöneticisinin işlediği süreç çıkışından ayırın, çünkü ikisinin sahibi farklıdır ve bıraktıkları kanıt farklıdır.

Etkileşimli kimlik doğrulama, gözetimsiz toparlanmayı kısıtlar. Arka plan birimi masaüstü anahtarlığını açmaz veya MFA istemine yanıt vermez, bu yüzden hizmet bağlamı için onaylanmış kimlik bilgisi düzenini izleyin.

Tünel kapalıyken uygulamaların ne yapabileceğine ayrıca karar verin. Yeniden deneme bir bağlantıyı geri getirir, engelleme politikası ise o boşlukta doğrudan trafiğe izin verilip verilmediğine karar verir.

İlgili makaleler