Bir alt ağ neden hâlâ VPN varsayılan rotasını atlıyor

VPN'i tam tünele geçirirsiniz, trafiğin çoğu uyar, sonra bir adres doğrudan yanıt verir — bir yazıcı, bir NAS, 10.x üzerinde bir atlama sunucusu. Bariz okuma tünelin sızdığıdır, bu yüzden varsayılan rotanın metriğini düşürürsünüz ve hiçbir şey değişmez. O başarısız deneme ipucudur: varsayılan rota bir yedektir, bir hüküm değil. Rota araması metrikleri karşılaştırmadan önce en uzun eşleşen öneki alır, bu yüzden /24, hangi sayıyı eklerseniz ekleyin /0'a karşı kazanmaya devam eder. Bu sıra netleştiğinde sızıntı genellikle birinin bilerek kurduğu bir rota ya da istemcinin hiç kapsamayı amaçlamadığı bir önektir.

Varsayılan rota gerçekte ne vaat eder

0.0.0.0/0, sıfır bit özgüllükle her IPv4 hedefine uyar. Bir ana bilgisayarın tablosunun daha iyi tanımlamadığı her şeye ulaşabilmesi için vardır. 192.168.1.0/24'e giden rota 24 eşleşen bit taşır, bu yüzden 192.168.1.40 için biri metrikleri, yönetimsel mesafeyi veya istemcinin öncelik alanı dediği şeyi karşılaştırmadan önce kazanır. Aynı kural Linux FIB'de, Windows yönlendirme tablosunda ve macOS'un arkasındaki BSD yığınında geçerlidir.

Normal bir LAN'da bu davranış bir özelliktir. Yerel alt ağ doğrudan bağlıdır, tünel sizin gezinmenizi taşırken yazıcı çalışmaya devam eder ve hiçbir şey yanlış yapılandırılmamıştır. Sorulmaya değer soru o tek adresin neden doğrudan gittiği değil, hangi tablodaki hangi önekin ona uyduğu ve onu oraya kimin koyduğudur.

Yarı varsayılanlar veya varsayılan girdi neden dokunulmamış görünebilir

En temiz örnek redirect-gateway def1 OpenVPN'dedir. Varsayılanınızı silip değiştirmek yerine 0.0.0.0/1 ve 128.0.0.0/1 ekler. Birlikte bu çift tüm IPv4'ü kapsar, her önek /0'dan uzundur ve ikisi de yönlendiricinin varsayılanını yerinde bırakarak onu yener. Ardından bir rota listesi çalıştırın, özgün varsayılan hâlâ oradadır, hâlâ ağ geçidinizi gösterir; yalnızca internet hedefleri için hiç seçilmez.

WireGuard'ın wg-quick'i aynı sonuca ilke tabanlı yönlendirmeyle ulaşır. AllowedIPs 0.0.0.0/0'ı kapsadığında kendi tablosunu oluşturur, işaretli paketleri oraya gönderir ve ana tablonun sıfır uzunluklu önekini yok sayan bir kural ekler. Ana tablo varsayılan girdisini korur ve kurallar, arayüzün sahip olduğu trafik için önce tünel tablosuna sorulacağına karar verir.

Her iki tasarım da tünelin dışında tam olarak bir rota gerektirir: özgün ağ geçidi üzerinden VPN sunucusunun kendi adresine bir ana bilgisayar rotası. O olmadan istemci tüneli kuran paketleri tünelin içinde taşımaya çalışır ve bağlantı hiçbir zaman tamamlanmaz. Bu yüzden katı bir tam tünel profilinde bile tablonuzda tünel olmayan bir rota normaldir. Sorgulanmaya değer rotalar, gerçekten önemsediğiniz hedefleri kapsayanlardır.

Metrikler beraberliği, önekler kazananı belirler

Metrikler yalnızca hedefle eşit derecede iyi eşleşen adaylar arasında karşılaştırılır. Linux'ta ip route get 10.20.5.9 kazananı tablosuyla birlikte yazdırır, ip route show table all adayları listeler, herhangi bir yarı varsayılan ve bir kuralın işaret ettiği herhangi bir tablo dahil. Windows'ta Find-NetRoute -RemoteIPAddress 10.20.5.9 seçilen rotayı ve kaynak adresi döndürür, Get-NetRoute ham tabloyu gösterir — ancak etkin maliyet rota metriği artı arayüz metriğidir, bu yüzden yavaş bir bağdaştırıcı kazanıyor gibi görünen bir beraberliği kaybedebilir.

Göreceğiniz şeylerin çoğunu üç durum kapsar:

• Aynı hedef, /24'e karşı /0: metrikler ne derse desin /24 önek uzunluğunda kazanır.
• Aynı hedef, farklı metrikli iki /24: daha düşük etkin metrik kazanır.
• Aynı hedef, iki tablo, biri bir ilke kuralıyla seçilmiş: kural önce tabloyu seçer ve önek karşılaştırması onun içinde olur.

Üçüncü durum bu raporların çoğunun bittiği yerdir. Linux'un ip rule veya bir Windows VPN trafik filtresi trafiği hiç tünel varsayılanını tutmamış bir tabloya gönderebilir ve ana tablo her zaman kusursuz görünür.

Bu atlatmanın sahibi genellikle kimdir

Tablodan değil, profilden başlayın. Split-tunnel yapılandırmaları ve uygulama başına VPN ayarları adlandırılmış önekleri kasıtlı olarak tünelin dışında bırakır; bir özel alt ağı koruyup genel gezinmeyi doğrudan bırakan bir iş profili tasarlandığı gibi davranır ve onu geçersiz kılmak, uygulamak için inşa edildiği ilkeyi bozar. Microsoft'un VPN yönlendirme kılavuzu tünele zorlanan trafik ile açık istisnalar arasında aynı çizgiyi çeker, bu da onu herhangi bir şeyi düzenlemeden önce yararlı bir çapraz kontrol yapar.

Sonra kalıntıları arayın. Artık var olmayan bir arayüze veya önceki ağdan bir adrese işaret eden bir rota, dock istasyonları, USB bağdaştırıcıları ve konteyner köprüleri gelip gittikten sonra ortaya çıkar. Bir kez silmek son değildir: NetworkManager bağlantı profilleri, netplan dosyaları ve Windows'un kalıcı rotaları onu sonraki bağlantıda veya önyüklemede yeniden kurar, bu yüzden herhangi bir şeyi düzenlemeden önce ona sahip olan dosyayı veya profili bulun.

Sonra IPv6'yı ayrıca denetleyin. ip -6 route ve Get-NetRoute -AddressFamily IPv6 ayrı durum, ayrı varsayılanlar ve ayrı istemci davranışı tutar. Yalnızca IPv4 denetimi, sessizce yerel bir IPv6 yolunu tercih eden çift yığınlı bir ana bilgisayar hakkında hiçbir şey söylemez ve tek başına bu, bir istemciyi split-tunnel gibi gösterebilir.

Uygulamanın kendi akışıyla doğrulayın

Uygulamanın gerçekte kullandığı hedefi not edin, sonra sisteme o uygulamanın bağlandığı kaynak adresten hangi yolu izleyeceğini sorun. ip route get 10.20.5.9 from 192.168.1.40 Linux'ta buna yanıt verir; Find-NetRoute -RemoteIPAddress 10.20.5.9 artı yerel adres Windows'ta bunu yapar. Sonucu profilin iddia ettiğiyle karşılaştırın. Tarayıcının genel IP sayfası tek bir protokolde tek bir hedefi test eder ve şikâyeti başlatan özel adres hakkında hiçbir şey söylemez.

Farkı açıklayan en dar nesneyi düzeltin. İstisna onaylıysa öneki yazın ve bırakın; değilse varsayılanın metriğini düşürmek yerine rotayı kaldırın veya tünel üzerinden açık daha dar bir rota ekleyin. Metriği düşürmek daha uzun bir öneki geçemez ve iki /1 rotası internet yoluna sahipken varsayılanı düzenlemek de hiçbir şeyi değiştirmez.

Sonra tüneli yeniden bağlayın ve aynı sorguyu yineleyin. İstemciler her bağlantıda rotaları yeniden kurar, bu yüzden yalnızca bir sonraki el sıkışmaya kadar süren bir değişiklik sınanmamıştır. Yol hâlâ ayrışıyorsa kalan şüpheliler bir ilke kuralı, ikinci bir tablo veya istemci tarafında bir filtredir — varsayılan rota değil.

• Uygulamanın gerçekte kullandığı hedefi ve kaynak adresi adlandırın.
• Kazanan rotayı ip route get veya Find-NetRoute ile yazdırın.
• İnternet yoluna bir /1 çiftinin mi yoksa bir ilke tablosunun mu sahip olduğunu denetleyin.
• /0'dan uzun ve hedefle eşleşen her öneki listeleyin.
• IPv6 denetimini ayrıca yineleyin.
• Kalan rotayı onu kuran dosyaya, profile veya filtreye kadar geri izleyin.
• Düzeltildi demeden önce yeniden bağlanın ve sorguyu tekrar çalıştırın.

Yedisi de profille uyuşuyorsa tünel tam olarak yapılandırıldığı şeyi yapıyordur ve düzeltme metriğe değil profile aittir.