Tek masaüstünde iki VPN istemcisi: ne çakışır ve ne çalışır

İkinci istemciniz bağlanır, birincinin kaynakları çözümlenmez olur ve kayıt, iş VPN'inin kişisel olanı bozduğunu söyler. Arıza anlamında hiçbir şey bozulmamıştır: iki istemci de tasarlandıkları işi yaptı ve makinenin yalnızca bir yönlendirme tablosu var. Çakışma, her istemcinin kendisine ait saydığı dört kaynak üzerinedir. Bunları sırayla ele alın; düzeltme genellikle bir onarım değil, tasarım tercihi olur.

Adım 1: çıkışın hangi istemciye ait olduğunu bulun

Bir şeyi değiştirmeden önce mevcut çıkış kararını okuyun. Genel bir adres için yol araması, paketin şu anda hangi arayüzü ve hangi sonraki atlamayı kullanacağını söyler ve bu, kimin kazandığının cevabıdır. Bunu istemcilerin oluşturduğu arayüz adlarıyla karşılaştırın; bu adlar genellikle ürün ya da protokol adını taşır. Arama beklemediğiniz tünele işaret ediyorsa çakışmayı çoktan buldunuz.

ip route get 1.1.1.1
ip route show default
route print

Bazı istemciler varsayılan yolu hiç değiştirmez; adres uzayının alt yarısı için bir, üst yarısı için bir olmak üzere iki yarım eklerler ve bunlar birlikte her şeyi kapsar. Bu, özgün varsayılan yolu görünür bırakır ve elle onarım doğru görünürken trafik hâlâ tünelden çıkar. Yalnızca varsayılan girdinin varlığını değil, metriği ve önek uzunluğunu okuyun.

İki istemci aynı metrikle aynı öneki talep ediyorsa durun. Çekirdek birini seçer, diğeri ise hiçbir şey taşımadan bağlı görünür.

Adım 2: çözümleyiciyi ve çakışan önekleri denetleyin

DNS ikinci çakışmadır ve belirgin bir belirti üretir: adresler çalışırken adlar başarısız olur. Her istemci kendi çözümleyicisini dayatır ve son yazan, sonraki sorgular için kazanır. İstemcinin ayarlar sayfasını okumak yerine çözümleyici hizmetine her bağlantı için ne kullandığını sorun.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Ardından iki ağın kullandığı özel önekleri karşılaştırın. İki taraf da aynı aralıktan dağıtıyorsa istemci tarafındaki hiçbir düzenleme bunu düzeltmez, çünkü makine hangi 10.0.0.0/8 hedefinin hangi tünele ait olduğunu söyleyemez. Bir taraf yeniden numaralandırılmalı ya da çevrilmelidir ve bu bir yapılandırma değişikliği değil, ağ sahipleriyle konuşmadır. Çakışma, dürüst cevabın tasarımın değişmesi gerektiği olduğu tek durumdur.

Önekler çakışıyorsa burada durun. Bu listede sonrasındaki her şey çakışmadıklarını varsayar.

Adım 3: kalıcı olan bir ayırma deseni seçin

Güvenilir desenler iki istemciyi aynı yönlendirme tablosuna karşı çalıştırmaktan kaçınır. Her iki özel ağa ulaşan bir bölünmüş tünel ilkesi olan tek bir istemci en basitidir; hedefler çakışmıyorsa ve ilkenin sahibi kabul ediyorsa. Sanal makine veya ağ ad alanı bir sonraki adımdır, çünkü her biri kendi tablosunu ve kendi çözümleyicisini alır.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Ad alanı, ikinci işletim sistemi olmadan sanal makineyle aynı ayırmayı verir, ancak pürüzlü kenarları vardır: tünel aygıtı içine taşınmalı ve uygulama içinde başlatılmalıdır. Ayrı bir fiziksel aygıt, yönetilen bir iş istemcisinin yanındaki kişisel VPN için genellikle en az şaşırtıcı seçenektir. Bir tüneli diğerinin içine yığmak bir ayırma deseni değildir; iç uç noktanın dış tünel üzerinden erişilebilir kalması gerekir ve bu düzen üstüne MTU ile gecikme sorunları ekler.

Bir desen seçin ve nedenini yazın. Bir uygulama için ad alanını geri kalanı için bölünmüş tünelle karıştırmak, özgün çakışmayı ayıklaması daha zor bir biçimde yeniden yaratır.

Adım 4: iki ağı da aynı oturumdan doğrulayın

Her özel ağda bir kaynağı, uygulamanın gerçekten çalıştığı ortamdan test edin; uygulama bir ad alanı içinde çalışıyorsa kendi kabuğunuzdan değil. Çıkış arayüzünü, çözümlenen adresi ve yanıt kodunu birlikte denetleyin, çünkü üçünden birindeki başarı diğerlerindeki hatayı gizleyebilir. Yeniden başlatmadan sonra yineleyin, çünkü istemcilerin başlama sırası kimin kazanacağını belirler. İnsanların kaydetmeyi unuttuğu kısım tam olarak bu sıradır.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Her ağ için istemci sürümlerini, arayüzleri, çözümleyici durumunu ve önekleri kaydedin. Bir istemci güncellenip yönlendirme davranışını değiştirdiğinde, o kayıt beş dakikalık bir düzeltme ile yeniden kurma arasındaki farktır. Sonraki kişi, hangi tünelin önce kalktığına dair hafızanızı paylaşmayacaktır.

Liste, varsayılan yola sahip arayüzü, her adın kullandığı çözümleyiciyi, ikinci tüneli ayıran deseni ve yeniden başlatmadan sonra her ağ için bir isteğin sonucunu söyleyebildiğinizde tamamdır. Bundan azı, bugün tesadüfen çalışan bir yapılandırmadır.