OpenVPN hâlâ eski rotaları mı itiyor? Neyi yüklediğine bakın

Bir rota eklersiniz, hizmeti yeniden başlatırsınız, yeniden bağlanırsınız ve istemcinin tablosu tıpkı eskisi gibi görünür. İki farklı şey doğru olabilir: sunucu düzenlemenizi hiç yüklemedi ya da istemci aldığını hiç kurmadı. Semptomdan başka ortak noktaları yok, bu yüzden ilk adım hangi durumda olduğunuzu bulmaktır.

Aşağıdaki karşılaştırma süreçten dışarı doğru ilerler, çünkü hangi dosyanın yürürlükte olduğunu yalnızca süreç bilir.

Düzenlediğiniz dosya ve sürecin okuduğu dosya

unit ve onun ürettiği komut satırıyla başlayın. systemd ana bilgisayarında systemctl cat openvpn@server, ExecStart satırını yazdırır ve örnek unit genellikle yapılandırma yolunu örnek adından türetir, bu nedenle openvpn@office olarak başlatılan bir arka plan süreci, openvpn@server olarak başlatılandan farklı bir dosya okur. Bunu çalışan sürecin argv'siyle karşılaştırın. Bir yapılandırma yönetim aracı, değişikliği kaybetmenin başka bir yolunu ekler: doğru dosyayı unit'in hiç söz etmediği bir konuma yazabilir ve o zaman başarılı bir dağıtım hiçbir şey yapmamış gibi görünür.

Zaman damgaları bunu hızla çözer: dosya sürecin başlangıç zamanından daha yeniyse süreç onu okumuş olamaz. Yönlendirici aygıt yazılımı üçüncü bir durum ekler, çünkü birçok model ayarlarını flash bellekte tutar ve açılış sırasında yapılandırmayı yeniden kurar, bu da diskteki bir dosyayı düzenlemeyi tamamen yanlış katman yapar.

Sunucunun ittiği ve istemcinin kurduğu şey

İtilen rotanın iki süzgeçten geçmesi gerekir. Sunucuda yorumlanmış bir blokta ya da adı uyuşmayan istemciye özel bir dosyada değil, yüklenen yapılandırmada bulunmalıdır. İstemcide pull etkin olmalı ve hiçbir pull-filter seçeneği atmamalıdır. verbosity 4 ile bağlanın ve istemcinin bildirdiği itilen seçenekleri okuyun: rota bu listede görünüyorsa sunucu üzerine düşeni yapmıştır ve kurmamayı istemci seçiyordur.

İstemciye özel dosyalar sık görülen bir karışıklık kaynağıdır. Sertifikanın common name'ine göre adlandırılan bir dosya seçenekleri yalnızca o istemciye iter ve tek karakterlik bir uyuşmazlık itmeyi sessizce durdurur, iki tarafta da hata görünmez. Sunucu bağlantı sırasında gördüğü common name'i günlüğe yazar, bu yüzden bu değeri dosya adıyla karşılaştırın, istemcinin adı olduğunu düşündüğünüzle değil.

İtilen önek ile dönüş rotası farklı sorunlardır

Yerel internet yolunu korumak için redirect-gateway seçeneğini bilerek yok sayan bir istemci, ikinci ve ilgisiz bir boşluk yaratır. Sunucunun yoklamaları tünel adresine ulaşır ama yanıtlar hiç gelmez, çünkü sunucunun tünel IP'sine gönderilen yanıt istemcinin olağan varsayılan ağ geçidinden yönlendirilir. Burada suç itilen alt ağ rotasında değildir; eksik olan, sunucunun tünel ağının trafiğini tünel aygıtından geri gönderen bir rotadır.

Bu rotayı istemciye eklemek, sunucunun başlattığı yoklamalara verilen yanıtları düzeltir. İtilen alt ağ rotasının yerini tutmaz ve bunun tersi de doğrudur, çünkü ikisi zıt hareket yönlerini tanımlar.

İki uçtaki tabloları karşılaştırın

Her değişiklikten sonra yeniden bağlanın ve istemcinin tablosunda itilen öneki ve tünel aygıtını okuyun. Ardından iki yönde de sınayın: istemciden itilen alt ağdaki bir ana bilgisayara ve o ana bilgisayardan istemciye geri. Var olan ama trafik taşımayan bir rota üç şeyden birini gösterir: karşı taraf iletmiyor, bir güvenlik duvarı akışı düşürüyor ya da yanıtın dönüş yolu yok.

Üç tanımlayıcıyı bir arada tutun: yapılandırma yolu, unit veya örnek adı ve sınadığınız istemci kimliği.

Bu üçü, bir sonraki olayı yeni bir soruşturma yerine beş dakikalık bir denetime dönüştürür ve tünel başkasının sorunu olduğunda bir iş arkadaşının ihtiyaç duyduğu şey de bunlardır.

Yeniden başlatmayı atlatan bir rota sorunu çoğu zaman hiç de yönlendirme sorunu değildir; arıza, okumayı sürdürdüğünüz tablonun yukarısındadır.