Aynı anda iki VPN istemcisi: varsayılan yolu kim kazanır?

İki VPN istemcisini aynı anda çalıştırmak bir yönlendirme tartışmasıdır, gizlilik ayarı değil. Hangi tünel daha belirgin yolu elinde tutuyorsa trafiği o alır, diğeri bağlı kalır ama boşta durur. Kurumsal ağ geçidi o zaman kişisel çıkıştan gelen bir bağlantı görür, oysa makinenizdeki kurumsal istemci hâlâ her bağdaştırıcıyı görür. Bu iki gerçekten hangisinin önemli olduğuna karar vermek bütün alıştırmadır.

Yönlendirme tablosu tek bir kazanan seçer

Tabloyu kurumsal istemci başlamadan önce ve sonra yakalayın, yalnızca hedefi değil arayüz sütununu okuyun. Dış tünelden gelen düz varsayılan yol kolayca yerinden edilir, çünkü /1 çifti /0'dan daha belirgindir. Birebir 0.0.0.0/1 ve 128.0.0.0/1 çifti tüm IPv4 uzayını iki yarıda kapsar ve herhangi bir tek varsayılanı yener. Kurulduktan sonra dış tünel hâlâ bağlı görünür ve hiçbir şey taşımaz.

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

İlke tabanlı yönlendirme ana tabloyu tamamen atlayabilir, bu yüzden hem kuralları hem yolları okuyun. İşaretli trafiği başka bir tabloya gönderen kural, ana tabloya bakılmadan önce kazanır. Böylece bir uygulama fiziksel bağlantıda kalırken geri kalan her şey tüneli kullanır.

ip rule show

Windows bunu metriklerle çözer

Windows'ta kazanan, hedef için en düşük metriğe sahip yoldur ve iki istemci farklı metriklerle varsayılan yol kurabilir. Tabloyu ve arayüz yapılandırmasını birlikte okuyun, çünkü daha düşük metrikli bağdaştırıcı her zaman beklediğiniz olmayabilir. Arayüz metriğini de ayarlayan bir istemci tek bir yol eklemeden varsayılanı kaydırabilir. Kaybeden bağdaştırıcı açık kalır ve basitçe hiçbir şey almaz.

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

İki çıktıyı karşılaştırın ve 0.0.0.0/0 sahibi arayüzü adlandırın. İki istemci de onu talep ediyorsa metriğe karar verilir, bu yüzden bağlantı sırası testi makineler arasında tutarsız görünebilir. Hiçbir çıktı varsayılan ağ geçidi göstermiyorsa istemci tam tünelde çalışmıyor ve zincir argümanı anlamsızdır.

İki gözlemci, iki farklı görüş

Uzak ağ geçidi dış çıkıştan gelen bir bağlantıyı ve istemcinin tüneli ne ilettiğini görür. Yerel istemci bağdaştırıcıları, yolları ve başka bir tünelin varlığını görür, çünkü bunları oluşturma yetkisiyle çalışır. Bu görüşleri ayırmak asıl meseledir; istemcinin fark edemeyeceğini iddia etmek değil.

İstemcinin istediğini sayabildiğini varsayın ve bunun yerine ağ geçidinin görüşüne göre planlayın. İstemcinin kör kalmasına bağlı bir tasarım, kırılmaya bir güncelleme uzaklıktadır.

DNS ve IPv6 zincirin sızdığı yerlerdir

DNS hangi çözümleyici ayarı kazanırsa onu izler ve bu paketlerin izlediği yol olmak zorunda değildir. Kurumsal tünelden ulaşılan kurumsal çözümleyici tasarımla tutarlıdır; dışından ulaşılan yerel çözümleyici tutarlı değildir ve tünelin gizlemesi gereken adları açığa çıkarır. IPv6 ikinci sızıntıdır: çift yığınlı bir ana makine, tünelin yalnızca IPv4 üzerinden taşıdığı hedeflere IPv6 kullanmayı sürdürür. Aileleri ayrı ayrı denetleyin, çünkü yalnızca IPv4 tüneli IPv6 yolları veya çözümleyicileri hakkında hiçbir şey söylemez.

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

İkinci bir tüneli üst üste yığmak yerine çözümleyiciyi ve IPv6 yolunu bilerek düzeltin. Çift kapsülleme MTU'ya da mal olur, bu yüzden zincir kalktıktan sonra sayfalar takıldığında önce daha küçük iç MTU denenmelidir. Hızlı yanıt veren bir çözümleyici, doğru olduğunun kanıtı değildir.