Uygulama tabanlı ve hedef tabanlı split tunneling: hangisi seçilmeli

Uygulama tabanlı ve hedef tabanlı split tunneling aynı iş için iki ayar değildir. Biri hangi sürecin paket gönderdiğini sorar; diğeri o paketin nereye gittiğini sorar. İlk soru için kurulmuş bir kural, trafik bir yardımcı süreçten geldiğinde sessizce başarısız olur; ikinci soru için kurulmuş bir kural ise bir ana makine adı hiç listelemediğiniz bir adrese çözüldüğünde başarısız olur. Gereksinime uyan nesneyi seçin, sonra bunu iki test paketiyle kanıtlayın: biri tüneli kullanmalı, diğeri kullanmamalı.

İki kural farklı katmanlarda eşleşir

Uygulama kuralı ağ katmanının üstünde, işletim sisteminin gönderene verdiği kimliğe karşı uygulanır. Android'de bu bir paketin arkasındaki UID'dir ve VPN hizmeti her UID için trafiğin tünele girip girmediğine karar verir. Hedef hakkında hiçbir şey sorulmaz, bu nedenle seçilen uygulama her yere ulaşabilir ve başka hiçbir uygulama iç ağa ulaşamaz.

Hedef kuralı doğrudan pakete uygulanır. Tünel arayüzü bir dizi öneke sahiptir, yönlendirme tablosu eşleşen trafiği oraya gönderir ve gönderen süreç önemli değildir. Bu yüzden hedef kuralı kimsenin listeye eklemeyi hatırlamadığı bir hizmeti, yazıcıyı veya toplu işi kapsar ve bu yüzden istemcisi sürece hiç bakmayan bir platformda yalnızca bu program olarak ifade edilemez.

Uygulama kuralları mobil istemcilere ve yönetilen aracılara uygundur

Android seçimi doğrudan sunar: VpnService.Builder.addAllowedApplication() ve addDisallowedApplication() paket adlarını alır ve kararı her UID için uygular, Android'in VPN geliştirici kılavuzunda açıklandığı gibi. iOS'ta paket tanımlayıcılarına dayanan uygulama başına VPN kurallarıyla eşdeğeri vardır ve bunlar genellikle elle yazılmak yerine bir MDM profiliyle dağıtılır.

Masaüstü istemcileri zayıf noktadır. Çoğu Windows ve macOS VPN istemcisi hedefe göre yönlendirir ve süreç başına seçici hiç sunmaz, çünkü tünel sürücüsü süreçleri değil paketleri görür. Planınız bir dizüstü bilgisayarda tek bir uygulamayı tünele sokmaya bağlıysa, bunun etrafında tasarım yapmadan önce istemcinin gerçek yeteneklerini kontrol edin; belki bir hedef listesi ile ikinci bir makine arasında seçim yapıyorsunuz.

İnsanların gözden kaçırdığı bir sonuç: bu platformlarda bir uygulama kuralını rotalarla taklit edemezsiniz. Uygulamanın sunucusu için bir ana makine rotası eklemek, tarayıcı ve güncelleyici dahil herkesin trafiğini o sunucuya tüneller.

Hedef kuralları alt ağ listelerine ve site erişilebilirliğine uygundur

WireGuard modeli açık hale getirir. AllowedIPs kripto anahtar yönlendirmesidir: hedefi bir eşin listesine giren iç paket o eşe şifrelenir, geri kalan her şey normal yoldan şifrelenmeden çıkar. Adlandırılacak bir süreç ve neyin dahil olduğuna dair bir belirsizlik yoktur.

OpenVPN aynı yere itilen yönlendirme tablosu üzerinden ulaşır. route-nopull sunucunun rota dikte etmesini durdurur, ardından istemci tarafındaki route 10.20.0.0 255.255.0.0 vpn_gateway tam olarak ofis önekini kapsar. IPv6 bu istemcilerin her birinde ayrı bir ifadedir ve onu unutmak, doğru görünen bir IPv4 bölünmesinin etrafından sızmanın en yaygın yoludur.

Ana makine adı bir rota değildir. Profil bir alan adı alanı sunuyorsa, onu istemcinin bir kez çözdüğü bir ad olarak ele alın, kalıcı bir adres aralığı olarak değil; içerik dağıtım ağları ve yük dengeleyiciler yarın farklı adresler verecektir.

İki modelin kırıldığı yerler: yardımcılar, paylaşılan hizmetler, çözümleyiciler

Yardımcı süreçler uygulama kurallarını kırar ve bu bir sunucu arızası gibi görünür. Bir tarayıcının güncelleyicisi, çökme raporlayıcısı, SYSTEM olarak çalışan bir eşitleme hizmeti ve başka bir pakete gömülü WebView ayrı kimliklerdir, bu yüzden tarayıcıyı tünele sokmak gerçek isteği tünelin dışında bırakabilir. Tersi de aynı derecede kafa karıştırıcıdır: tünellenmiş bir süreç içindeki paylaşılan kitaplığı çağıran hariç tutulmuş bir uygulamanın trafiği yine tünelden geçer.

Hedef kuralları paylaşılan hizmetlerde ve adlarda kırılır. Dosya paylaşımları, yazıcılar, iç DNS ve lisans sunucusu adreslerde yaşar, bu yüzden tek uygulamalık bir tünel tarayıcıya erişim verirken bağlı sürücü ölü kalır. Bu kapsam farkı hiçbir modelde hata değildir, ama tek uygulamalık bir tünelin neden bu kadar sık VPN açık ve paylaşım gitti durumunu ürettiğinin nedeni budur.

Çözümleyiciler ikisini de keser. İstemci iç DNS sunucuları ayarlarsa ama işletim sistemi genel bir çözümleyiciye HTTPS üzerinden DNS kullanırsa, yanıt tünelin dışından gelir ve hedef kuralı hiç eşleşmeyebilir. Kuralın yanlış olduğu sonucuna varmadan önce hangi çözümleyicinin gerçekten yanıt verdiğini kontrol edin ve istemci tarafında tünel çözümleyicisini kurup kurmadığını doğrulayın. DNS'i tünelin dışında bırakan bir bölünme yönlendirme tablosunda kusursuz görünür ve yine de her iç adda başarısız olur.

Yordam: seç, uygula, doğrula

Menüden değil gereksinimden başlayın. Amaç yalnızca bu uygulamanın tüneli kullanabilmesiyse, uygulama kurallarına ve bunları destekleyen bir platforma ihtiyacınız var. Amaç bu ağlara tünel üzerinden erişilebilmesiyse, öneklere ihtiyacınız var. Yanıt ikisiyse, bunları iki ayrı denetim olarak uygulayın ve hangisinin hangi arızadan sorumlu olduğunu yazın.

İfade edebileceğiniz en dar biçimi uygulayın, sonra istemcinin durum simgesi yerine yönlendirme tablosuna sorarak doğrulayın:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

İlk iki satır gerçek bir hedefin kullanacağı arayüzü adlandırır; wg show yapılandırılmış önek listesini yazdırır; Windows'ta Find-NetRoute paket gönderildiğinde yığının yanıtlayacağı sorunun aynısını yanıtlar. Arayüz tünel ise kural eşleşti.

Ardından hariç tutulması gereken ikinci paketi başka bir uygulamadan aynı hedefe test edin. Bilete istemci sürümünü, kural türünü, önek veya paket listesini ve gözlenen iki sonucu kaydedin. Tam da bu sonuç çifti, bir sonraki mühendise ilkenin yanlış yapılandırıldığını mı yoksa trafiğin hiç ona ait olmadığını mı söyler.