OpenVPN rota metriği: seçilen rota neden yine de kaybediyor

Profide bir rotaya metrik eklediniz, yeniden bağlandınız ve trafik hâlâ yanlış arayüzden çıkıyor. Sorun nadiren sayıdır. Metrik yalnızca işletim sisteminin zaten karşılaştırdığı adayları sıralar; daha belirgin bir önek ya da daha önceki bir ilke tablosu, herhangi bir metrik okunmadan önce karar verir.

Önce profili, sonra kurulu tabloyu, en sonunda seçim kurallarını inceleyin. Bu sıra, istemcinin rotayı kurma biçimiyle örtüşür ve sizi karşılaştırmaya hiç girmeyen bir değeri ayarlamaktan alıkoyar.

Rota satırını alan sırasına göre okuyun

Bir Community OpenVPN 2.6 istemcisi IPv4 için route satırında dört alan kabul eder: ağ, ağ maskesi, geçit ve isteğe bağlı metrik. Geçit konumu, özel vpn_gateway anahtar sözcüğünün yazıldığı yerdir. Bu, bu bağlantı için VPN tarafındaki bir sonraki atlama noktasıdır; bir yönlendirme tablosu numarası ve fiziksel yönlendiriciniz değildir. Bunu kaçırırsanız satırın geri kalanı, ne yaptığına dair yanlış bir fikirle okunur. Ağ seçenekleri başvurusu dört alanın hepsini belgeler.

Özel bir hedef için satır şöyle olabilir:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Açık 30 o rotaya uygulanır, 50 ise profildeki sayı belirtmeyen diğer tüm rotalar için varsayılan olarak kalır. Satırı soldan sağa okumak, hangi değerin nerede geçerli olduğunu anlamaya yeter.

route-metric bir varsayılandır, sıralama değil

route-metric kendi numarasını taşımayan rotalar için yedek değeri belirler. Bir rotayı başka hiçbir şeyin üstüne çıkarmaz ve açık metriklerle kurulmuş rotaları yeniden sıralamaz.

Bu ayrım, profil iki biçimi karıştırdığında önemlidir. Üstteki tek bir route-metric satırı yetkili görünür ve suçu ona atmak kolaydır; oysa trafiği gerçekten taşıyan rota, üç satır aşağıda kendi metriğini taşıyor olabilir.

Bir rotanın belirli bir yolu tercih etmesini istiyorsanız sayıyı o rotaya koyun. Oluşturulmuş bir profilde tutarlı bir varsayılan istiyorsanız route-metric kullanın ve tek tek satırları olduğu gibi bırakın. İkisini sebepsiz karıştırmak, bir profilin kimsenin açıklayamadığı bir rotayla sonuçlanma biçimidir.

İstemcinin ne kurduğuna bakın

Yeniden bağlantı tamamlandıktan sonra profile değil, çekirdeğe sorun.

ip route show istemcinin eklediği rotaları listeler, ip route get 172.20.5.10 ise daha faydalı soruyu yanıtlar: bu hedef gerçekte hangi rotayı, hangi kaynak adresle kullanır. Hedef tabloda yoksa istemci onu kurmamıştır.

Yerel bir direktif, sunucudan gelen bir push ya da başka bir ağ yöneticisi aynı öneki ekleyebilir veya kaldırabilir ve son yazan kazanır. Çalışırken uç noktaya giden rotayı göz önünde tutun, çünkü bağlantının kurduğu tünelden geçmeyen bir uzak sunucu yoluna ihtiyacı vardır.

Daha küçük bir metrik neden yine de kaybediyor

Metrikler aynı hedefe giden rotaları karşılaştırır. Geniş bir öneki daha belirgin hâle getirmezler. redirect-gateway def1 devredeyken istemci 0.0.0.0/1 ve 128.0.0.0/1 rotalarını kurar ve bu iki önek tüm IPv4 uzayını 0.0.0.0/0 rotasından daha belirgin biçimde kapsar. Varsayılan rotadaki 1 metriği onları geçemez.

Aynı mantık birbiriyle örtüşen her çift için geçerlidir. /24, içindeki bir adres için /16'yı yener; eklenmiş sayılar ne olursa olsun, çünkü arama önce en belirgin eşleşmeyi seçer ve ancak ondan sonra eşitler arasında metrikleri karşılaştırır.

Metrik hatası gibi görünen ama olmayan kısım burasıdır. Herhangi bir sayıyı değiştirmeden önce iki adayın da önek uzunluğunu kontrol edin.

İlke kuralları tablodan önce çalışır

Linux'ta hangi yönlendirme tablosuna bakılacağına ip rule karar verir. Kurallar öncelik sırasına göre değerlendirilir, bu yüzden daha önceki bir tablo ana tablo hiç okunmadan bir rota döndürebilir. main içindeki bir metrik, ilk başvurulan tablodaki bir eşleşmeyi geçemez.

ip rule show kullanın ve ardından belirli tabloya sorun, örneğin ip route show table 100, o kuralın ne döndüreceğini görmek için. Bir VPN istemcisi veya konteyner çalışma zamanı bir kural eklediyse yanıt, okuduğunuz tabloda değil orada olabilir. Kaynak adres de önemlidir, çünkü bir kural kaynakla eşleşip aynı hedefi tünel trafiği ve LAN trafiği için farklı çözebilir.

Hedefi doğrulayın, sıralamayı değil

Tartışmayı bitiren test, amaçlanan alt ağ içindeki bir ana bilgisayara tek bir sorgu ve çekirdeğin seçtiği kaynak adresin kontrolüdür. Bu çift tasarıma uyuyorsa, liste temiz bir sıralama gibi görünmese de metrik işini yapıyordur.

IPv6 ve DNS'i bu kontrolün dışında bırakın. Bunlar farklı direktiflerle yapılandırılır ve farklı mekanizmalarla çözülür; çalışan bir IPv4 rotası ikisi hakkında da bir şey söylemez. Her seferinde bir katmanı değiştirin ve sorguyu yeniden çalıştırın.