İkinci bir VPN tüneli birinciyi neden bozar?

İkinci bir VPN istemcisini tek bir müşteri ağına ulaşmak için kurmak bu işin başlamasının olağan yoludur ve iki istemci de başarı bildirirken ilk tünel kararır. Her istemci bir varsayılan rota kurdu, ikincisi daha özgüldü, ve çekirdek artık ilk tünelin kendi dış bağlantısı dışındaki her şey için onu izliyor. Hiçbir şey çökmedi ve hiçbir profil yanlış değil. Bir rota diğerinin yerini aldı, çözüm ise varsayılan rotanın hangi tünele ait olacağına karar vermektir.

Belirti: ikinci istemci sessizce kazanıyor

OpenVPN: redirect-gateway def1 seçeneği 0.0.0.0/0 üzerine yazmaz. 0.0.0.0/1 ve 128.0.0.0/1 ekler: ikisi birlikte her IPv4 adresini kapsar ve her önek uzunlukta sıradan bir varsayılanı yener. Özgün varsayılan tabloda kalır ve normal trafik için kullanılmaz olur, VPN sunucusuna giden ana bilgisayar rotası tünelin kendi dış paketlerini yakalamasını önler. İki istemci de bunu yapar ve ikincisi kendi çiftini yalnızca daha sonra kurar.

Bu yüzden ilk tünel bağlantısı kesilmiş değil ölü görünür. Arayüzü ayakta, denetim kanalı canlı ve artık hiçbir uygulama trafiği ona ulaşmıyor. Ters şikâyet de aynı eksik push'tan gelir: bağlanan ama hiçbir şey göndermeyen telefon genellikle redirect-gateway'i hiç duyurmamış bir sunucuyla konuşur, bu yüzden aygıt kendi varsayılanını korur ve yalnızca havuza ulaşır.

İkinci istemci bağlanmadan önce ve sonra rota anlık görüntüsü alın. Tabloda görünen iki yarım rota tüm değişikliktir ve her iki şikâyeti de açıklar. Belirtinin görünmesi için tablodaki başka hiçbir şeyin hareket etmesi gerekmez. Bu yüzden ikinci istemciyi kaldırmak birinciyi anında geri getirir.

Hangi tünelin gerçekten kazandığını okuyun

Kazananı istemcilerin başlama sırasından veya sistem tepsisindeki simgeden çıkarmayın. Çekirdeğe iki özel ağın dışındaki bir hedef için hangi rotayı kullanacağını sorun ve dönen arayüzü okuyun.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

İlk ikisi Linux yanıtı, son ikisi Windows eşdeğeridir. İki tünel de ayaktayken bunları çalıştırın, sonra birini koparıp yeniden çalıştırın. İki çıktı arasındaki fark, bir çözüm seçmeden önce ihtiyacınız olan olgudur ve herhangi bir istemcinin günlüğünü okumaktan daha kısa sürer.

Sonucu, arayüz adı ve eşleşen önekle birlikte kaydedin. İkinci VPN birinciyi bozdu diyen bilet belirtinin tanımıdır, kimsenin üzerine gidebileceği bir yönlendirme ifadesi değildir. Arama bunu bir sonraki mühendisin tek komutla yeniden üretebileceği bir olguya dönüştürür.

Windows: bir profilin varsayılana sahip olmasını engelleyin

Windows kayıtlı profiller tutar ve yerleşik istemci birinin diğerine bağlı olmasına izin verir, böylece ikinci bağlandığında birinci otomatik olarak ayağa kalkar. En son bağlanan profil varsayılanı elinde tutma eğilimindedir, bu yüzden pratik sahibi ilk değil son aramadır. Her profile kendi push rotalarını verin ve varsayılana sahip olmaması gereken için split tunneling'i açın.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Split tunneling bunu değiştirir: tabloya yalnızca sunucunun push ettiği önekler girer ve varsayılan ilk tünelde kalır. İki sunucu da varsayılan rota push ederse tasarım yine başarısız olur, çünkü o zaman son bağlantı kazanır ve istemci tarafındaki hiçbir ayar bunu değiştirmez. Sunucu tarafındaki push'u düzeltin veya tek sahibi kabul edin.

Uygulamayla tetiklenen profiller başka bir özelliktir ve bilinmeye değer: bir Windows profili adlandırılmış çalıştırılabilir dosya başladığında başlayabilir ve trafik filtreleri ne taşıyacağına karar verir. Bu bir güvenlik duvarı kuralı değil profil ayarıdır ve varsayılan rota çatışmasından farklı bir sorunu çözer.

Linux: ikinci tüneli ana tablonun dışında tutun

Bir makinede iki openvpn --config örneği çalıştırmak iki istemciyi de aynı tabloya koyar ve üç seçenek onları artan yalıtımla ayırır. En hafifi ikinci istemcinin tabloyu hiç düzenlemesini engellemektir: açık rotalarla route-nopull veya yalnızca amaçladığınızı kuran bir route-up betiği. O zaman ikinci tünel tam olarak adlandırdığınız önekleri taşır ve başka hiçbir şeyi. O zaman hangi önekin nereye gideceğine sonradan keşfetmek yerine siz karar verirsiniz.

Politika yönlendirme orta seçenektir. Bir kural tek bir kaynak adres veya güvenlik duvarı işareti için ayrı bir tablo seçer ve o tablo ikinci tünelin rotalarını taşır. Ters yol filtreleme burada tuzaktır, çünkü tablonun seçeceğinden farklı bir arayüze gelen yanıt atılır, bu yüzden tünelin bozuk olduğu sonucuna varmadan önce rp_filter ayarını kontrol edin.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Ağ ad alanları en ağır ve en temiz seçenektir. İkinci istemciyi ip netns içinde başlatın, ona bir veth çifti verin ve kullanmak için o ad alanına girin. Girişim ortadan kalkar çünkü her ad alanı tek bir tabloyu paylaşmak yerine kendi tablolarına sahiptir; iki tünel haftalarca ayakta kalacaksa bu ek kurulum buna değer.

Uygulama başına ve zincirleme ayrı bir sorun olarak

Bazen ikinci tüneli yalnızca bir program kullanmalıdır. Linux'ta kullanıcı, cgroup veya bağlantı noktasına göre politika yönlendirme bu sonucu verir ve tek bir hedef varsayılana hiç dokunmadan bir arayüze sabitlenebilir. Soketini tek bir arayüze sabitleyen uygulama yönlendirme tablosuna hiç başvurmaz, bu nedenle bir başlatıcı kendi ayarlarında bir adres seçilene kadar fiziksel bağdaştırıcıyı kullanmaya devam edebilir.

Zincirleme, iki tüneli yan yana çalıştırmaktan farklı bir işlemdir. A'yı B üzerinden zincirlemek, iç sunucunun adresinin dış tünelin içinden erişilebilir olması gerektiği anlamına gelir. Dış istemci ayrıca iç istemcinin şifreli paketlerini sızıntı sanmamalıdır. Sanal makine içindeki tek istemci kaba ama güvenilir sürümdür; ikisi aynı ana bilgisayardaysa yukarıdaki yönlendirme işi artı iç sunucuya doğru hiçbir zaman iç tünele girmeyen bir dış yol gerekir.

Varsayılanın sahibini, her tünelin taşıdığı önek listesini ve DNS yolunu yazın. Bu üç olgu bir sonraki olayı soruşturma yerine başvuruya dönüştürür.