OpenVPN DHCP yenilemesinden sonra düşüyor: uç nokta rotasını koruyun

Tünel bağlanır, sonra erişim bağlantısındaki kira yenilemesi onu öldürür ve günlük rotayı değil zaman aşımını suçlar. VPN yapılandırmasında hiçbir şey değişmedi ve ipucu da bu: dışında bir şey değişti. Bir DHCP olayı adresi veya ağ geçidini yeniden yazdı ve tünelin uç noktasını erişilebilir tutan ana makine rotası artık var olmayan bir sonraki atlamayı gösteriyor. Bu, yönlendirme sorunu olmadan önce bir sahiplik sorunudur.

Belirtiyi yarım varsayılan rotalarla karşılaştırın

redirect-gateway def1 ile OpenVPN, varsayılan rotayı değiştirmek yerine 0.0.0.0/1 ve 128.0.0.0/1 rotalarını kurar. Birlikte bu ikisi tüm adres alanını kapsar ve 0.0.0.0/0 rotasını yalnızca önek uzunluğuyla yener. Bu yüzden daha belirgin bir eşleşmesi olmayan her hedef tünele girer.

Uç noktanın bir istisnaya ihtiyacı var. OpenVPN, yarım varsayılanlar girmeden önce özgün erişim ağ geçidi üzerinden sunucu adresine bir ana makine rotası ekler, böylece kapsüllenmiş paketler dışarı çıkabilir. Bu istisna kaybolduğunda veya artık var olmayan bir sonraki atlamayı koruduğunda, tünelin kendi dış paketleri bir yarım varsayılanla eşleşir ve tünele geri gönderilir. Sonuç, bir sonraki keepalive veya el sıkışmada ölen bir bağlantıdır ve günlükte yönlendirme hatasına benzeyen hiçbir şey yoktur.

Başka bir şeye dokunmadan önce tablonun şeklini doğrulayın. ip route show her iki yarıyı ve sunucu adresi için bir ana makine rotasını listelemeli; ana makine rotası yoksa, soruşturmanın geri kalanı için belirgin bir başlangıç noktası vardır.

Yarım varsayılanlar metrik değişmeden neden kazanır

Daha düşük bir metrik daha uzun bir öneki yenmez. /1 rotaları kazanır çünkü çekirdek önce en belirgin rotayı eşleştirir, bu yüzden varsayılan rotadaki metriği yükseltmek tünele giden trafiğin nereye gittiği konusunda hiçbir şeyi değiştirmez. Metriklerin peşinden koşmak bu teşhisteki en yaygın yanlış dönüştür.

Seçimi ip route get 203.0.113.10 ile kontrol edin ve gerçek sunucu adresini koyun. Yanıt, çekirdeğin gerçekte kullanacağı arayüzü ve sonraki atlamayı adlandırır; bu, bir tabloyu okuyup üzerine düşünmekten daha bilgilendiricidir.

Bu komutu tünel başlamadan önce, çalışırken ve kira olayından sonra çalıştırın. Tek komuttan üç yanıt ve ayrışma noktası görünür hale gelir.

Bir değil üç anlık görüntü alın

Erişim adresini, erişim ağ geçidini, uç noktanın hedefini, seçilen rotayı ve varsa politika kurallarını üç anda toplayın: erişim bağlantısı yapılandırıldıktan sonra, VPN bağlandıktan sonra ve kira veya operatör olayından sonra. Her anlık görüntü bir avuç komuttur ve ancak birlikte anlam taşırlar. Arızadan sonraki tek bir anlık görüntü geçişi değil durumu kaydeder. Komutları küçük bir betiğe yazın ki her anlık görüntü aynı şekilde alınsın.

Anlık görüntüleri zaman damgalarıyla tek bir dosyada tutun, çünkü sonra ilginç soru sıralamadır. DHCP olayı OpenVPN rotasını yenilemeden önce mi sonra mı geldi? Yanıt, kimin düzeltmesi gerektiğini belirler. Yanlış saatten gelen zaman damgası hiç olmamasından kötüdür, bu yüzden yönlendirme tablosuna sahip ana makineden alın.

Uç nokta adres yerine ad olarak yapılandırıldığında, her anlık görüntüde onu da çözümleyin. Erişim bağlantısındaki bir DNS değişikliği, hiçbir rotaya dokunmadan uç noktayı taşıyabilir.

İstisnayı hangi bileşenin yenilediğine karar verin

dhcpcd sisteminde kancalar kanca dizininden ve çıkış kancasından çalışır ve yönetici modu kapsam olarak arayüz başına moddan farklıdır. Kanca ne yaparsa yapsın idempotent olmalıdır, çünkü yenilemeler dalgalar halinde gelebilir.

Güvenilir sahip, iki tarafı zaten bilen entegrasyondur: VPN bağlantısını yöneten bir ağ yöneticisi veya erişim bağlantısı kalktıktan sonra sıralanan bir birim. Bir kancanın eklediği statik rota, bir sonraki ağ geçidi değişikliğine kadar çalışır ve sonra tamamen aynı şekilde başarısız olur. Yine de kanca kullanıyorsanız, bugün gördüğünüzü sabit kodlamak yerine çalışma zamanında geçerli ağ geçidini okumasını sağlayın.

Sahibi yapılandırmanın içine kaydedin. Yeniden bağlanmayı ayıklayacak bir sonraki kişinin, istisna rotasından VPN'in değil bir kancanın sorumlu olduğunu bilmesi gerekir.

Yalnızca yeniden bağlanmayı değil yaşam döngüsünü test edin

dhcpcd -n eth0 ile veya kirayı bırakıp yeniden alarak yenilemeyi zorlayın, ardından uç nokta için ip route get komutunu yeniden kontrol edin. Bunu iki kez yapın, çünkü ikinci tur yinelenen rotalar ekleyen kancaları yakalar. Sonra yeniden başlatın, çünkü kalıcılık doğruluktan farklı bir özelliktir.

Bir yenilemeyi ve yeniden başlatmayı atlatan tünelin bir sahibi ve çalışan bir istisnası vardır. Yalnızca elle yeniden başlatmayı atlatanın ikisi de yoktur ve planlayamadığınız bir sonraki olayda başarısız olur.