SIGKILL sonrası OpenVPN DNS'i kalıyor: önce sahibini denetleyin

OpenVPN istemcisi öldürüldükten sonra DNS çözümlemeyi bırakır ve ilk dürtü /etc/resolv.conf dosyasını yeniden yazmaktır. Bu değişiklik, gerçek eski durum başka bir yerde dururken çalışan bir çözümleyiciyi bozabilir. Önce netleştirilmesi gereken soru, tünelin kurduğu DNS ayarlarının kime ait olduğu ve temizliği atlayan çıkışın gerçekten önemli olup olmadığıdır.

Onarımı üç koşul belirler: süreci sonlandıran sinyal, ayarları alan çözümleyici bileşeni ve tünel bağlantısının hâlâ var olup olmadığı. Bu sırayla yanıtlayın, düzeltme genellikle küresel bir dosyaya dokunmadan gelir.

Ne tür bir çıkış olduğunu belirleyin

Community sürümünde OpenVPN için hem SIGINT hem de SIGTERM düzgün çıkış istekleridir. SIGKILL yakalanamaz: engellenemez veya işlenemez, bu yüzden hiçbir kapatma yordamı çalışma şansı bulamaz. Ön plandaki bir uçbirimde normal Ctrl+C SIGINT üretir, beklemekten vazgeçen bir gözetleyici ise genellikle SIGKILL'e yükselir. Fark önemlidir çünkü yalnızca ikinci durum kancaların atlandığını garanti eder.

screen veya tmux içinde çalıştırmak Ctrl+C'nin hangi sinyali gönderdiğini değiştirmez. Uçbirimin genellikle ne yaptığını değil, sürecin gerçekte ne aldığını denetleyin.

Tüneli bir hizmet veya bağlantı yöneticisi çalıştırıyorsa, pid'i öldürmek yerine o tek bağlantıyı sahibi aracılığıyla durdurun. Yönetici süreci yeniden başlatabilir ve size yeni bir tünel ile kafa karıştırıcı bir çözümleyici durumu bırakabilir. Bağımsız bir süreç yalnızca temizliğin çalışması için olağan bir sonlandırma isteğine ihtiyaç duyar.

Çözümleyicinin kime ait olduğuna karar verin

systemd-resolved, resolvconf tarzı bir betik ve düz dosya yeniden yazımı üç farklı sahiptir. Birincisi bağlantı başına ayarları bellekte tutar ve arayüz kaybolduğunda onları düşürür. İkincisi bir şey kaldırana kadar süren kayıtlar tutar. Üçüncüsü bir dosya yazar ve geri yüklemeyi onu yazana bırakır.

Bir onarım komutu seçmeden önce sahibini belirleyin. Aynı belirtinin hangisinin kullanıldığına bağlı olarak üç farklı doğru yanıtı vardır.

NetworkManager tarafından yönetilen bir VPN çözümleyici değişikliklerine zaten sahip olabilir. Üstüne ikinci bir yardımcı eklemek aynı bağlantı için yarışan iki sahip yaratır ve kaybedenin durumu sonraki yeniden bağlanmada yeniden ortaya çıkar. Bir yönetici sorumluysa ayarı betikte değil yöneticide düzeltin.

down kancası ne yapabilir ve ne yapamaz

Betik down TUN/TAP aygıtı kapatıldıktan sonra bir kez çalışır. down-pre eklemek bu sırayı tersine çevirir ve canlı bağlantıya ihtiyaç duyan yardımcıların istediği gibi, aygıt hâlâ varken betiği çalıştırır.

Hiçbir yönerge bir kancanın SIGKILL sonrasında çalışmasını sağlamaz. Ayrıcalıklar da down-pre ile geri yüklenmez: arka plan hizmeti bir user veya group düzeyine inerse ya da bir chroot ortamına girerse, kanca bunun bıraktığı erişimle çalışır. Çağrılan bir kanca yine de çözümleyiciyi güncelleyemeyebilir. OpenVPN başvurusu sinyalleri ve geri çağırma yaşam döngüsünü kapsar.

Sürecin çıkış durumunun yanında kancanın kendi hatasını denetleyin. Eksik temizlik ve başarısız temizlik çözümleyicide aynı, günlüklerde farklı görünür.

Gerçekte kalan durumu denetleyin

systemd-resolved kullanan bir sistemde resolvectl status hangi bağlantının hâlâ VPN'in DNS sunucularını veya yönlendirme alanlarını taşıdığını gösterir. O bağlantı gitmiş bir bağlantıya ya da hâlâ ayakta olan başka bir tünele ait olabilir.

Kaybolan bir arayüz bağlantı başına yapılandırmasını beraberinde götürür, bu yüzden atlanan bir kanca temiz DNS ile bir arada bulunabilir. Bağlantı hâlâ kayıtlıysa ve yalnızca durdurulan bağlantıya aitse, sahibi olan yönetici onu kaldırmalıdır. Daha eski bir betik küresel bir çözümleyici dosyasını yeniden yazdıysa, bunun yerine o betiğin belgelenmiş geri yükleme adımını arayın.

Başka bir bağlantıyı çalmadan kurtarın

Bağlantı başına ayarlar sizin yönetiminizdeyse, resolvectl revert bağlantının adını alır ve o arayüz için çalışma zamanı DNS yapılandırmasını temizler. Bu bir profil düzenlemesi değil çalışma zamanı eylemidir, bu yüzden kalıcı bağlantı yapılandırması dokunulmadan kalır. Yanlış bağlantıyı adlandırırsanız çalışan bir tünelin DNS'ini temizlersiniz, bu yüzden ad durum çıktısından alınır.

Düzenlemeden önce /etc/resolv.conf öğesinin yönetilen bir sembolik bağlantı olduğunu doğrulayın, ardından istemciyi normal olarak bir kez daha durdurun ve DNS'e yeniden bakın. İkinci duruş temizliyorsa, önceki sorun yapılandırma değil zorunlu çıkıştı.