PiVPN profilinizi gerçekte hangi OpenVPN örneği kullanıyor?

PiVPN bir sunucu yapılandırması ve istemci profili yazar, sonra çıkar; trafiğinizi taşıyan süreç asla kendisi olmaz. Bu yüzden başarısız bir el sıkışma, yanlış uç noktaya bağlanan bir istemci ya da yeniden başlatmadan sonra bozuk dönen bir hizmet, kurulum aracının menülerinden açıklanamaz. Bu belirtiler şu anda çalışan OpenVPN arka plan sürecine, o sürecin gerçekte yüklediği yapılandırmaya ve işaret edildiği günlüğe aittir. Dört salt okunur komut bunu genellikle çözer ve hiçbiri sertifikalarınızı ya da anahtarlarınızı değiştirmez.

Yardımcı ve arka plan süreci farklı nesnelerdir

Karışıklığı açıklamak kolaydır: aynı dizinde yardımcının ürettiği dosya, sürecin okuduğu dosya ve bazen ikisinin eski bir kopyası bulunur. Yardımcı bir hazırlama betiğidir. Paketleri kurar, birim dosyalarını yazar ve bir istemci profili yazdırır, sonra işi biter. Geriye hizmet yöneticisindeki bir kayıt ve bir komut satırı kalır.

systemd ana makinesinde dizin listesinden değil etkin birimden başlayın. Ad paketlemeye bağlıdır: Debian ve Raspberry Pi OS imajları genellikle şablondan türetilmiş bir örnek sunar, örneğin openvpn-server@server, daha eski kurulumlar ise openvpn@server kullanır. Dosya adından tahmin etmek yerine yöneticiye hangisinin çalıştığını sorun.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Şu çıktıda ExecStart= satırını okuyun. Gerçekte çalıştırılan dosyayı ve yöneticinin gerçekten başlattığı seçenekleri, herhangi bir --config yolunu da kapsayarak adlandırır; yanında duran ve hiçbir komutun başvurmadığı bir yapılandırma dosyası çalışan tünelin parçası değildir.

Arka plan sürecinin çözdüğü yapılandırma zincirini izleyin

OpenVPN ayarları bulmak için dizini taramaz. Şu yolla verilen dosyayı okur: --config, içindeki her config yönergesini izler ve ardından komut satırı seçeneklerini uygular. Kılavuz 2.6 bu sırayı açıklar ve iki dosya kapı, aygıt ya da şifreleme konusunda anlaşmadığında bu önemlidir.

Önce gerçek çağrıyı dökün, sonra kimliği ve erişilebilirliği belirleyen yönergelere bakın. İki komut da salt okunurdur ve canlı bir sunucuda güvenlidir, yine de ikincisi herkese açık bir kayıtta istemeyeceğiniz yolları yazdırır.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Bir .ovpn dosyası ev dizininde istemci artefaktıdır. Sunucu arka plan süreci onu asla okumaz, bu yüzden sunucu tarafındaki el sıkışma arızasını düzeltmek için o dosyayı düzenlemek hiçbir şey kazandırmaz.

İçe aktarmalar diğer tuzaktır. Bir config satırı, seçenekleri o noktada işlenen ikinci bir dosyayı içeri çeker, bu yüzden sonraki tek değerli bir yönerge ana dosyanın söylediği görünen şeyi geçersiz kılabilir. Görünen dosya doğru görünüyor ama süreç hâlâ farklı davranıyorsa, bir şeyi değiştirmeden önce içe aktarılan dosyayı okuyun.

Günlüğü süreçle eşleştirin, hatırladığınız hatayla değil

İki günlük hedefi yaygındır ve yalnızca biri journal'dır. log-append ayarlandığında süreç o dosyaya yazar ve journal başlangıç satırlarının ötesinde çok az şey saklar. O olmadan journalctl olayların kaynağıdır.

journalctl -u openvpn-server@server -n 80 --no-pager

Bir bağlantı denemesini bir zaman aralığına bağlayın. İstemcinin uç noktasını not edin, sonra aynı saniyelerdeki sunucu olaylarını okuyun. Sertifika değişimine hiç ulaşmayan bir TLS el sıkışması erişilebilirliğe ya da protokol uyuşmazlığına işaret eder; kimlik doğrulama reddi ise tünel parametreleri zaten kararlaştırıldıktan sonra gelir.

Eski bir günlük kaydı beş dakika önce indirdiğiniz profil hakkında hiçbir şey kanıtlamaz. İstemci dosyasını yeniden üretin, bir kez bağlanın ve yalnızca o deneme sırasında görünen satırları okuyun.

Son genel hatayı değil ilk somut hatayı kaydedin. Bir bağlama hatası, yanıtsız dış alışveriş, sertifika reddi ve hesap reddi sizi her biri farklı bir katmana gönderir ve sondaki zaman aşımı çoğu zaman üstteki yararlı olayı gizler.

Tüneli yeniden kurmak tanılama adımı değildir

Cazip kısa yol ikinci, daha basit bir tünel kurmaktır: statik anahtar, sertifika yok, ek kimlik doğrulama yok. Çoğu zaman bağlanır ve yalnızca iki ana makinenin aralarında UDP ya da TCP geçirebildiğini kanıtlar. Sertifikayla kimlik doğrulanan kurulumun neden başarısız olduğu hakkında hiçbir şey söylemez ve korumanız istenen güvenlik modelini sessizce değiştirir.

Aynısı tls-auth ya da tls-crypt devre dışı bırakmak, verify-x509-name gevşetmek veya yeşil durum için ikinci faktörü bırakmak için de geçerlidir. Doğrulama kaldırıldığı için bağlanan bir tünel başka bir sistemdir, onarılmış değil.

Günlüğün adlandırdığı katmanda tek bir sınırlı değişiklik yapın, aynı birimi yeniden başlatın ve o tek bağlantı denemesini yineleyin. Bu karşılaştırmayı dürüst tutar ve geri alabileceğiniz bir değişiklik bırakır.

Sıradaki kişiye ne devredilmeli

Dört olguyu hâlâ elinizdeyken yazın: OpenVPN sürümü şuradan openvpn --version, etkin birim, içe aktarmalarıyla yapılandırma zinciri ve bir denemeyi kapsayan günlük penceresi. Bu dört olgu belirsiz bir şikâyeti yeniden üretilebilir bir duruma çevirir.

Paylaşmadan önce gizleyin. Özel anahtarlar, auth-user-pass dosyalar, statik anahtar malzemesi ve tam istemci paketleri bir kayda ait değildir; seçenek adları ve zincirin biçimi genellikle ikinci bir göz çifti için yeterlidir.

Zincir sağlamsa ve günlük hâlâ ağa işaret ediyorsa, sonraki adım istemci ile sunucu arasındaki yol, bir başka kurulum değil. Hikâyenin yardımcının hiç sahip olmadığı tek parçası budur.