VPN üzerinden yalnızca bir özel alt ağ nasıl gönderilir

Tünelden yalnızca bir özel alt ağ geçirip geri kalan her şeyi normal yolunuzdan göndermek, yanlış yapmanın çok sayıda yolu olan küçük bir istektir. Sonucu belirleyen şey split tunneling etiketli onay kutusu değil, kararın nerede uygulandığıdır: istemcinin kendi yönlendirme tablosunda, sunucunun ittiği bir yolda ya da iki ucun müzakere ettiği bir politikada. Yanlış katmanı seçerseniz ya hiç istemediğiniz tam bir tünel ya da karşı tarafın kabul etmeyi reddettiği bir tünele giden yol elde edersiniz. Herhangi bir yapılandırmayı açmadan önce üç koşullu bir test kullanır, sonra aşağıdaki mekanizmalardan birini seçerim.

Tasarımı belirleyen üç koşul

Birincisi, ağ sahibinden tam öneki ve maskeyi almanız gerekir. 10.x ağı bir önek değildir; 10.20.0.0/16 önektir. Ev LAN'ınız, bir Docker köprüsü veya çalıştırdığınız başka bir VPN ile çakışmadığını doğrulayın, çünkü çakışma yolu belirsizleştirir ve çekirdek amaçlamadığınız kaydı seçer.

İkincisi, dönüş trafiğine kim yanıt veriyor. Bir paketi tünele yönlendirmek onu yalnızca VPN sunucusuna ulaştırır. Alt ağ, istemci havuzunuza geri dönüş yolu olmayan başka bir yönlendiricinin arkasındaysa, sunucu trafiği maskelemek zorundadır ya da o yönlendirici havuzunuzu öğrenmelidir. İstemci tarafındaki hiçbir yol eksik bir dönüş yolunu düzeltmez.

Üçüncüsü, uygulama noktası. Bazı istemciler bir yol kurar ve gerisini işletim sistemi yapar. Diğerleri bir politika müzakere eder ve ağ geçidinin kabul etmediği bir politika hiç tünel üretmez: paketler belirgin bir hata olmadan düşürülür. Bir şey yazmadan önce bu ikisinden hangisinin sizin durumunuz olduğunu belirleyin.

WireGuard: AllowedIPs yönlendirme tablosudur

İstemcide AllowedIPs tünele girebilecek hedefleri listeler ve wg-quick her kaydı sıradan bir yola dönüştürür. Yani bu işin istemci yarısı tek satırdır.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Şimdi aynı istemci için sunucunun kaydıyla karşılaştırın. O kayıt sunucunun istemciye ne göndereceğini açıklar, bu genellikle istemcinin tünel adresidir, özel alt ağ değil.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Bu ikisini yer değiştirmek en sık gördüğüm hatadır. 10.20.0.0/16 kaydını sunucunun peer bölümünün altına koymak, tüm alt ağın o istemcinin arkasında olduğunu beyan eder ve bu izin değil, siteden siteye bir iddiadır. Hiçbir peer'ın AllowedIPs değeriyle eşleşmeyen paketler sessizce düşürülür, bu yüzden yanlış bir kayıt tam olarak bir güvenlik duvarı sorunu gibi görünür.

Yolları kendiniz yönetiyorsanız Table = off ayarını [Interface] altında yapın ve istediğiniz yolu ekleyin. O zaman hiçbir şey otomatik eklenmez, bu yüzden yol arayüzü kaldıran şeyin içinde yer almalıdır.

OpenVPN: yolu itin, sonra yerine ulaştığından emin olun

Normal bir sunucuda değişiklik, sunucu yapılandırmasında istemci havuzunun yanındaki tek bir direktiftir.

push "route 10.20.0.0 255.255.0.0"

İstemci bağlanınca onu ekler. Hata modu, aynı profil redirect-gateway değerini de ittiğinde ya da birisi zaten route-nopull eklediğinde ortaya çıkar: ilki oturumu tam bir tünele dönüştürür, ikincisi sizinki dahil itilen her yolu atar.

Tam tünelli bir sunucuya karşı dar davranışa ihtiyaç duyan bir istemci yalnızca istemediği kısımları yok saymalıdır. OpenVPN 2.4 ve sonrasında pull-filter tam bunun için vardır.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Adres ailelerini ayrı tutun: itilen IPv4 yolu, IPv6'ya çözülen bir iç hizmet için hiçbir şey yapmaz ve o hizmet tünel üzerinden başarısız olurken her şey yolunda görünür.

Özel alt ağ VPN sunucusunda değil de başka bir istemcinin arkasındaysa sunucuya bildirilmelidir. client-config-dir aracılığıyla her istemci için iroute 10.20.0.0 255.255.0.0 içeren bir dosya ekleyin, ayrıca eşleşen route değerini de ekleyin ki diğer istemciler yolu öğrensin. iroute olmadan sunucunun o öneki tam o tünelden göndermek için hiçbir nedeni yoktur.

IPsec: trafik seçicileri anlaşmalıdır

IPsec'te itilecek bir yol yoktur. İki uç tünelin içinde hangi adreslerin yaşadığını müzakere eder ve anlaşılan seçicilerin dışındaki trafik ne şifrelenir ne de ondan geçirilir. strongSwan istemcisinde seçiciler açıktır.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Ağ geçidi iki tarafta da 0.0.0.0/0 ile yapılandırılmışsa, IKEv2 daralması genellikle alt SA'yı iki önerinin kesişimine indirir; istenen sonuç budur. Bazı ağ geçitleri bunun yerine yapılandırdıkları seçicilerle eşleşmeyen öneriyi reddeder ve günlük o zaman yönlendirme şikayeti yerine başarısız bir alt SA gösterir. Bu olduğunda değişiklik ağ geçidine aittir, çünkü istemci yolu karşı tarafın kabul etmeyeceği bir seçici için tünel oluşturamaz.

Windows'ta yerleşik istemci aynı kararı iki ayarın arkasına saklar. Tünel bölme açık olmalı ve önek profile kaydedilmelidir.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Öneki kaydetmek, yeniden bağlanmadan sonra onu ayakta tutan şeydir; elle eklenen bir yol bunu yapmaz.

Uç noktayı ve DNS'i kararın dışında tutun

VPN uç noktası tünel olmadan erişilebilir kalmalıdır, yoksa tünel kendi içine çöker. Yalnızca 10.20.0.0/16 yönlendirildiğinde bu otomatiktir, çünkü uç nokta genel bir adrestir. Tam tünel profilinde böyle değildir ve istemcinin tünel kalkmadan önce uç noktaya açık bir ana bilgisayar yolu olması gerekir.

DNS, bir yol itmesinin sizin yerinize vermediği ikinci karardır. İç adlar genellikle yalnızca özel ağın erişebildiği bir çözümleyici üzerinden çözülür. Sunucu bir DNS sunucusu itiyorsa her ad oradan geçer; itmiyorsa iç adlar ya başarısız olur ya da amaçlamadığınız bir şeye genel olarak çözülür. Bölünmüş DNS, iç çözümleyicide tek bir arama etki alanı tutar ama bu istemci desteğine bağlıdır, bu yüzden onu yönlendirmenin yan etkisi değil ayrı bir iş olarak ele alın.

Doğrulayın, sonra yeniden başlatın ve tekrar doğrulayın

Üç sonda yönlendirme sorusunu kapsar. Çekirdeğe uzak bir adresin nereye gideceğini sorun, alt ağın içinden bir şey alın, sonra sıradan bir genel isteğin hâlâ normal bağlantınızdan çıktığını doğrulayın.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

İlk satır bir arayüz adı verir. Fiziksel arayüzünüzü adlandırıyorsa yol hiç yerleşmemiştir. Windows'ta Find-NetRoute -RemoteIPAddress 10.20.5.7 aynı soruyu yanıtlar ve son sonda hâlâ VPN sunucusunun değil, sizin olağan adresinizi göstermelidir.

Sonra yeniden başlatın. Elle eklenen yollar kaybolur, profilden, itilen bir yapılandırmadan ya da AllowedIPs değerinden gelen yollar geri gelir. Dar erişim yeniden başlatmadan önce çalışıp sonra başarısız oluyorsa hata yönlendirmede değil, tünelin nasıl başladığındadır.

Bitmiş demeden önce dört şeyi doğrulayın: önek ağ sahibinden geldi ve yerel hiçbir şeyle çakışmıyor, dönüş yolu var ya da onun yerini bir maskeleme kuralı alıyor, yapılandırdığınız mekanizma platformunuzda yönlendirmeyi uygulayan mekanizma ve aynı sondalar temiz bir yeniden başlatmadan sonra da geçiyor. StrongSwan'ın yönlendirme notları dönüş yolu sürekli başarısız olan kısımsa okumaya değer.