OpenVPN'in bir rotadaki "File exists" hatası dosya sorunu değildir

Mesajın göründüğü yerden başlayın. Bir istemci bağlanır, tünel açılır ve ardından günlük, Linux'un rota ekleme komutunun File exists ile başarısız olduğunu bildirir. Bu cümlede hiçbir şey bir sertifikaya, anahtara veya yapılandırma dosyasına atıfta bulunmaz, sözcükler bunu ima etse de. Çekirdek kendi yönlendirme tablosunu tanımlıyor ve kurulmasını istediğiniz önekin zaten bir girdisi var.

İstemcinin kendi sırasını izleyin: ne istedi, tabloda zaten ne vardı, o girdiyi oraya kim koydu ve ancak ondan sonra neyin değiştirileceği. Her adım olası bir sahibi ortadan kaldırır.

İstemci gerçekte ne istiyordu

Hata öncesinde istemci eklemeyi planladığı rotayı kaydeder, genellikle hedef, ağ maskesi, ağ geçidi ve bazen metrik veya tablo olarak. O satır istektir. Ardından gelen hata çekirdeğin yanıtıdır ve ikisi yan yana okunmalıdır.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

Rota yardımcısının sıfırdan farklı çıkış durumu, altındaki metinden daha az bilgilendiricidir, çünkü farklı çekirdek yanıtları sıfırdan farklı durum üretir. Tam mesajı saklayın; mevcut bir girdi ile erişilemeyen bir ağ geçidi arasındaki ayrım, sonraki bölümlerden hangisinin geçerli olduğunu belirler.

Mevcut rotayı okuyun, yalnızca adresi değil

Tabloda aynı noktalı dörtlüyü aramak yeterli değildir. Bir rota nesnesi adres ailesi, tablo, hedef öneki, metrik, protokol ve çıkış aygıtıyla tanımlanır ve bir öneki paylaşan girdiler bu nitelikler farklı olduğunda yasal olarak bir arada bulunabilir. Çakışan şey metin değil, nesnenin tamamıdır.

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

Son komut ilk ikisinden farklı bir soruyu yanıtlar: neyin var olduğunu değil, çekirdeğin o hedef için şu anda hangi girdiyi seçeceğini. Her iki görünüm de yararlıdır ve bir sonuca varmadan önce karşılaştırmaya değecek kadar sık ayrışırlar. Aralarındaki uyuşmazlık ilginç olan durumdur, yuvarlama hatası değil.

Öneki, tabloyu, metriği ve aygıtı başarısız isteğin yanına yazın. Mevcut girdi aynı niteliklere ve aynı sonraki atlamaya sahipse, yinelenen bir talimatınız var, yönlendirme sorununuz değil.

Bir önekin sahip olabileceği dört sahip

Bağlı rotalar atanmış bir adresten gelir ve sistem o adres var olduğunda onları yeniden oluşturur. Bir DHCP istemcisi veya bağlantı yöneticisi, rotaları kendi yaşam döngüsünün parçası olarak kurar. Başka bir VPN istemcisi aynı öneki zaten taşıyor olabilir. Ve yerel bir kanca veya betik, başka hiçbir şeyin bilmediği bir rota ekleyebilir.

Her sahip farklı bir düzeltme gerektirir. Bağlı rota sizin silmeniz için değildir; kaldırılması tünel kullanılabilir olmadan önce yerel erişimi bozabilir ve çekirdek onu geri koyar. Yöneticiye ait rota o yönetici üzerinden değiştirilmelidir, sonraki yeniden bağlanmanın geri alacağı elle yazılmış ip route del ile değil.

Korunan bir arayüz aynı karışıklığı kolaylaştırır. Tünel aygıtı bir yeniden bağlanmadan sağ çıktığında, özel kurulum koduyla kurulan rotalar ikinci çalıştırmada hâlâ mevcut olabilir, bu yüzden temiz durum varsayan bir betik ikinci kez başarısız olur ve ilk kez çalışır. Ya eski girdiyi bilerek temizleyin ya da kurulum kodunu idempotent yapın.

block-local farklı bir soruyu yanıtlar

Bir profil tüm trafiği tünelden gönderdiğinde istemci yerel ağa ne olacağına karar vermelidir. block-local bayrağı yerel LAN'ı tünelden yönlendirerek bu kararı değiştirir ve LAN ağ geçidi için belgelenmiş istisnayı korur; bu, erişilebilirlik üzerinde görünür sonuçları olan bir trafik politikası seçimidir.

Bu, bir rota eklemenin neden mevcut girdi hatası döndürdüğünü açıklamaz ve bunu evrensel bir onarım olarak kabul etmek gerçek çatışmayı bir politika değişikliğinin arkasına saklar. Profil düzenlemesinden sonra yerel kaynaklarınız erişilemez hale gelirse, bu bayrak ilk kontrol edileceklerden biridir; rota ekleme başarısız olursa, cevap bu değildir.

Bunu hangi hedeflerin yerel kalacağına dair bilinçli olarak alınmış ve yazıya geçirilmiş bir karar olarak görün. Günlük endişe verici göründüğünde denenecek bir anahtar değildir.

Döngüyü kapatın: kopyayı kaynağında kaldırın

Girdiyi hangi sahibin tuttuğunu öğrendikten sonra, yinelenen talimatı tanımlandığı yerden kaldırın. Bu, profildeki bir route satırı, sunucudan gelen bir push veya artık çalıştırılması gerekmeyen bir kanca olabilir.

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

Ardından yeniden bağlanın ve üç şeyi doğrulayın: tünel açılır, amaçlanan hedef istediğiniz yola çözümlenir ve hata yerine yenisi gelmeden kaybolur. Yanlış seçilmiş bir yolla temiz günlük bir onarım değildir.

Önek bir tarafta yerel LAN, diğer tarafta uzak bir ağ anlamına geliyorsa, sorun kopya değil adres çakışmasıdır ve hiçbir silme iki anlamı aynı anda doğru yapmaz. Bu durum iki ağdan biri için farklı bir plan gerektirir. Herhangi birine dokunmadan önce hangi tarafın yeniden numaralandırılacağına karar verin.