1194 portu zaten kullanımda: o OpenVPN soketi kime ait?
Adresin kullanımda olduğu hatası yerel bağlamaya aittir. Bağlantı noktalarını değiştirmeden veya yanlış süreci durdurmadan önce taşıma, adres ve ad alanını karşılaştırın.
Aynı sunucu profilini iki kez başlatın ve ikinci süreç 1194 portu için adresin zaten kullanımda olduğu hatasıyla çıkar. Olağan durumda çakışmayı tanılama başlatması oluşturmuştur ve özgün örnek istemcilere hâlâ tam olarak hizmet vermektedir. Bu hikâye bu raporların büyük bir kısmını açıklar ve herhangi bir şeyi yeniden başlatmadan önce bunu tanımakta yarar var. Aynı zamanda çözümün en ucuz sürümüdür.
Hata yerel bir bağlamayı anlatır ve ötesinde hiçbir şeyi değil. Bir sağlayıcının portu engellediğine, bir istemcinin yanlış parola gönderdiğine veya sertifika zincirinin bozuk olduğuna dair kanıt değildir.
Tam bağlama hatasını okuyun
Bu ailedeki iki hata farklı anlamlara gelir ve bunları karıştırmak sizi yanlış katmana gönderir. "Adres zaten kullanımda" başka bir soketin istediğiniz uç noktayı tuttuğunu söyler. "Adres kullanılamıyor" istediğiniz adresin bu ana makinede henüz bulunmadığını söyler, bu bir hazır olma sorunudur, kopya değil.
systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager
Herhangi bir şeyi değiştirmeden önce hata metnini kopyalayın, belirttiği adres ve port dahil. Bir arayüzün belirmesini bekleyen hizmet ikinci hatayı tekrar tekrar günlüğe yazar ve ardından adres var olduğunda başarıyla bağlanır; ilk hatayı günlüğe yazan hizmet ise kopya çözülene kadar asla başarılı olamaz. Hangisini gördüğünüzü not etmek hiçbir maliyet getirmez ve boşa giden bir arayüz arayışını önler.
Soketi envanterleyin, portu değil
Port numarası eksik bir envanterdir. Uç nokta bir taşıma, bir adres ailesi, yerel bir adres ve bir porttur, hepsi tek bir ağ ad alanı içinde. Aynı numaradaki UDP dinleyicisi ve TCP dinleyicisi farklı soketlerdir ve farklı ad alanlarındaki aynı numaradaki iki süreç asla karşılaşmaz.
ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'
Önce profilin gerçekten kullandığı taşımayı çalıştırın. Sonra yalnızca numaraya değil yerel adres sütununa bakın: joker karakterli bağlama her yerel adresi kapsar, bu yüzden belirli bir adres isteyen ikinci bir süreç, yazdırılan dizeler farklı olsa bile onunla çakışabilir. Soket yeniden kullanım seçenekleri ve platform kuralları kesin sonucu belirler, bu nedenle bu her dağıtıma uyguladığınız bir kural değil bir gözlem olmalıdır.
Hangi sürecin ona sahip olduğunu bulun
Sayısal uç noktalar ve süreç bilgileri, ayrıcalıklarınız izin verdiğinde sahibi belirler ve ihtiyacınız olan şey sahibidir, programın adı değil. İki OpenVPN süreci farklı profiller çalıştırabilir ve dinleyiciyi tutan süreç en az beklediğiniz olabilir.
sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194
Bulduklarınızı hizmet yöneticisi, bir kapsayıcı çalışma zamanı veya önceki testten kalan bir terminal süreciyle karşılaştırın. Süreç ayrıntılarının olmaması soketin sahibi olmadığının kanıtı değildir; genellikle sorgunun yeterli izin olmadan çalıştığı anlamına gelir. Aynı şekilde yalnızca TCP listesi bir UDP çakışmasını ortadan kaldırmaz, bu yüzden hatada adı geçen taşımayı inceleyin. Yalnızca süreç adı hangi profilin yüklendiğini asla söylemez ve uç noktayı belirleyen profildir.
Tek sahip veya iki tasarlanmış örnek
Dağıtım tek bir sunucu amaçlıyorsa tek bir yaşam döngüsü sahibi tutun ve onu izlemek için ikinci bir kopya başlatmak yerine o örneğin günlüğünü veya yapılandırılmış kaydı okuyun. Kontrollü bir ön plan çalıştırması gerçekten gerektiğinde, yönetilen örneği bilerek durdurun ve bunu yapmadan önce hizmet verdiği istemcileri hesaba katın.
İki örnek amaçlanıyorsa onlara ayrı dinleyiciler ve diğer her şeyi ayrı verin: adres havuzları, sanal arayüzler, yönlendirme politikası ve yapılandırma sahipliği. Tek başına farklı bir port soketten başka hiçbir şeyi ayırmaz ve iki sunucu yine aynı havuz ve aynı yollar için kavga eder.
Üç kısayol anılmaya değer çünkü bu hatayla ilgili her tartışmada görünürler. Suçlu gibi görünen rastgele bir PID'i öldürmeyin. Mesajı susturmak için soket paylaşımını etkinleştirmeyin. Bir sunucu profilini istemci tarzı bağlanmamış bir yapılandırmaya geçirmeyin çünkü bu bağlama hatasını ortadan kaldırır; sunucu, özgün çakışmadan teşhis edilmesi daha zor bir biçimde erişilemez hale gelir.
Portu değiştirmek yalnızca yeni dinleyici onaylanmış bir tasarımın parçası olduğunda meşru bir yanıttır; buna yönlendirme kuralı ve istemci uç noktası da dahildir. Bunlar güncellenmediyse çakışmayı kimsenin bulamayacağı bir yere taşımış olursunuz.
Bağlamayı her şeyden önce doğrulayın
Sınırlı düzeltmeden sonra amaçlanan örneğin etkin olduğunu, dinleyicisinin beklediğiniz taşımada göründüğünü ve bir istemcinin bağlanabildiğini doğrulayın. Başarılı bir bağlama yalnızca yerel soket aşamasını tamamlar; tünel açıldıktan sonra kimlik doğrulama veya trafik hakkında hiçbir şeyi onaylamaz.
ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f
Soket mevcutsa ve istemci hâlâ başarısız oluyorsa kalan sorun aşağı yöndedir ve bağlama hatası artık tarihtir. Bu ayrım, tam mesajı önce okumanın tüm amacıdır: bir hata, bir katman, bir sahip. Böyle okuyun ve sonraki belirti tahminden değil bilinen bir durumdan başlar.