OpenVPN hata vermeden mi başlamıyor? journal’a bakın

Komut dönüyor, servis başarısız görünüyor ve terminale bir açıklamaya benzeyen hiçbir şey ulaşmıyor. Bu sessizlik, insanların «OpenVPN başlamıyor» diye tanımladığı belirtidir ve neredeyse hiçbir zaman programın bir şey söylemeden öldüğü anlamına gelmez. Bu, mesajın okumadığınız bir kanala gittiği veya başlattığınız şeyin yapılandırdığınız şey olmadığı anlamına gelir. Profili şüpheli olarak görmeyi bıraktığınızda her iki durum da bir dakikadan kısa sürede teşhis edilebilir.

Çıktıyı dört yer emer: unit’in journal’ı, bağlantıya sahip olan eklenti, tünelin diğer ucu ve çalıştığını sandığınızdan farklı bir ikili dosya. Her birinin kendi kontrolü var.

Sessizlik, doğru kanala bakmadığınız anlamına gelir

Ön planda çalıştırma terminalinize yazdırır. Bir unit journal’a yazdırır ve başarısız bir unit, hata nasıl başlatıldığındaysa ve ona ne söylendiğinde değilse, herhangi bir şey yazmadan önce çıkabilir. Bu ayrım önemlidir: journal’da hiç kayıt olmaması sürecin hiç gerçekten çalışmadığı, bir kayıt ve ardından çıkış olması ise çalışıp bir şeyi reddettiği anlamına gelir.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Temiz bir çıkışı sinyalden ayırmak için systemctl show -p Result -p ExecMainStatus openvpn-client@office ekleyin. Bir 1 durumu ve Result=exit-code bir program kararıdır; Result=signal veya bir zaman aşımı bunun yerine ortama işaret eder ve hiçbir profil düzenlemesi bunu değiştirmez. Herhangi bir şeyi yeniden başlatmadan önce iki değeri de not edin, çünkü yeniden başlatma onları üreten geçici durumu siler.

Instance adı yolun bir parçasıdır

Paketlenmiş şablon unit’i bir dosya yolu almaz. Bir instance adı alır ve bu ad profili bulmak için bir dizine eklenir: office Debian ve Ubuntu paketlemesinde /etc/openvpn/client/office.conf olarak çözümlenir. office-v2.conf adlı bir dosya @office olarak başlatılsa bile hiç okunmaz ve unit sessizce çıkar çünkü kendi bakış açısından yapacak bir şey yoktu. Arama dizini client ve server modları arasında farklıdır, bu yüzden şablonu değiştirdiğinizde aynı hata tamamen başka bir yeri gösterir.

Bu uyuşmazlık sessiz hatanın en yaygın kaynağıdır ve profil iyi olduğu için profilde görünmez. Gerçekte ne olduğunu listeleyin ve paketlemenin beklediği herhangi bir uzantı dahil iki adı karakter karakter karşılaştırın.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Unit etkinleştirilmiş ama hiçbir instance listelenmemişse, etkinleştirmenin kendisi sonradan yeniden adlandırılan bir ada atıfta bulunabilir. Doğru instance’ı yeniden etkinleştirmek genellikle yeterlidir ve geride kalan eski unit dosyasını silmek, bir sonraki kişiyi şaşırtmaması için değerlidir. Geride kalan unit dosyası, birine sonradan bir saate mal olan küçük bir şeydir.

Eklenti tüneline sahip olduğunda terminal hiçbir şey görmez

Masaüstü applet’inden başlatılan bir bağlantı NetworkManager’a aittir ve OpenVPN çıktısı açtığınız herhangi bir shell yerine o servisin journal’ına gider. İstemciyi elle çalıştırıp hiçbir şey görmemek bu düzenlemede beklenir, çünkü elle çalıştırılan süreç bağlantıyı taşıyan süreç değildir.

Journal’da ona sahip olan servisi arayın, sonra ayrıştırmayı okuyabileceğiniz bir ayrıntı düzeyinde yeniden üretin. Aşağıdaki iki komut aynı hatanın farklı sahiplerine bakar.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

Bağımsız çalıştırma mesajları okumak içindir, yönetilen bağlantının yerine geçmek için değil ve ikisi sonrasında farklıdır: DNS entegrasyonu, rotalar ve ömür eklentiye aittir. Bağımsız çalıştırmada bir ayrıştırma hatasını düzeltmek, applet kontrolü devraldığında ad çözümlemesini otomatik olarak düzeltmez, bu yüzden iki gözlemi ayrı tutun.

İki ikili dosya, tek PATH

Elle oluşturulmuş bir kurulum /usr/local altındaysa shell çağrısında kazanır, çünkü /usr/local/sbin Ubuntu’nun varsayılan PATH’inde /usr/sbin öncesinde gelir. Bir unit sizin PATH’inizi kullanmaz; ExecStart içinde yazılı olan mutlak yolu çalıştırır. Dolayısıyla terminalinizde çalışan sürüm ile servis olarak başarısız olan sürüm gerçekten farklı programlar olabilir.

Herhangi bir şeyi yeniden oluşturmadan önce ikisini karşılaştırın. Üçüncü komut tartışmayı belirleyendir.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Bir ortam farkı daha aynı yerde saklıdır. Paketlenmiş bir unit, /run altında systemd’nin onun için oluşturduğu bir çalışma zamanı dizinine dayanır; bu ayarı atlayan elle yazılmış bir yedek unit, tek bir dosya açmadan önce başarısız olabilir ve hata OpenVPN mesajı olmayan genel bir ret gibi görünür.

İstemcinin bildiremediği hatalar

Bazı sonuçlar uzak uçta kararlaştırılır. HTTP durumuyla yanıt verip bağlantıyı kapatan bir ağ geçidi size kendi durumunu söylemiştir ve yararlı sonraki adım sizin yerel dosyalarınız değil, onun günlüğü veya kimlik bilgisinin arkasındaki hesaptır. O senaryoda yerel olarak hiçbir şey bozuk değildir ve telafi için profili düzenlemek bir sonraki teşhisi zorlaştırır. İstemci yapılandırmasına dokunmadan önce o günlüğü okuyun.

Bir başka sessiz durum doğru çalışan bir istemcidir. İstemci modundaki bir tünel hiçbir zaman bir bağlantı noktasında dinlemez, bu yüzden açık bir dinleyici bekleyen bir kontrol hiçbir şey bildirmez ve hata gibi görünür. Boş bir bağlantı noktası listesinden sonuç çıkarmadan önce hangi modu başlattığınızı doğrulayın.

Katmanları sırayla işleyin: unit var mı ve instance adı doğru mu, journal’a veya --log dosyasına bir şey ulaştı mı, hangi ikili dosya ve profil gerçekten çalıştı ve hata yerel mi uzak mı. Her yanıt bir katmanı kaldırır. Profilden başlamak, hiç açılmamış olabilecek bir dosyayı yeniden yazmak demektir.