Tüm makineyi kapsamadan tek bir uygulamayı VPN'den geçirme

VPN istemcisi bağlanır, tarayıcı çalışır ve gerçekten önemsediğiniz tek komut hâlâ ev bağlantınızdan çıkar. Ya da tersi olur: tünel varsayılan rotayı kapar ve yerel dosya sunucusu masaüstünden kaybolur. Bunu, makinenin geri kalanı ofis LAN'ında kalırken dahili bir yapıt aynasına ulaşması gereken bir derleme aracısında yaşadım ve istemci tam olarak iki seçenek sundu, tüm trafik ya da hiçbiri. İstek iki yönde de aynıdır, bu program ve tüm makine değil, ve çoğu istemcide bunun için bir onay kutusu yoktur, çünkü yönlendirme tablosu bir programın ne olduğunu hiç bilmedi.

Yönlendirme tablosu programınızı neden göremez

Bir süreç paket gönderdiğinde, yığın hedef adresi yönlendirme tablosunda arar. Ne çalıştırılabilir dosyanın adı ne de bağlantı noktası bu aramaya girer. Alan adları da aynı nedenle başarısız olur: bir tünel trafiği bir adrese taşır ve bir ad bir adrese çözüldüğünde çekirdeğin elinde kalan tek kol yönlendirmedir. Bu yüzden "VPN yalnızca bu site için" sonunda bir vekil sunucu anlamına gelir ve "VPN yalnızca bu program için" küçük bir mekanizma kümesinden birini.

Bunların hiçbiri süreç başına rota değildir. Her biri kararı programı, kullanıcıyı veya uygulamanın kendi yapılandırmasını görebilen bir katmana taşır.

Tek bir hedef hâlâ bir rotadır, program kuralı değil. macOS'ta olağan yöntem "Tüm trafiği VPN üzerinden gönder" işaretini kaldırıp bir ana makine rotası eklemektir: sudo route add -host internal-tuner.example -interface ppp0, ardından şununla kaldırılır sudo route delete -host internal-tuner.example -interface ppp0. Önce arabirim adını şuradan okuyun: ifconfig, çünkü ppp0 yalnızca bir örnektir. Ana makine rotasında joker karakterler çalışmaz, bu yüzden birkaç adla konuşan bir hizmet her ad için bir girdi gerektirir ve kural makinedeki her süreci kapsar, aklınızdakini değil.

Soketi tünelin adresine bağlayın

İstemciyi kontrol ettiğinizde bağlama en ucuz seçicidir. Tünelin yerel adresine bağlanan bir soket, orada hedef için bir rota olduğu sürece o arabirimden çıkar ve makinedeki diğer her şey normal yolunu korur. İncelik şurada: bağlama kaynak adresi seçer, yönlendirme tablosu ise çıkışı seçmeye devam eder. Tek başına bağlama, rotası olmayan trafiği tünele taşımaz; "bağladım ama yine yanlış yoldan çıkıyor" bildirimlerinin çoğunun arkasındaki hata budur.

import socket
s = socket.socket()
s.bind(("10.8.0.2", 0))
s.connect(("build.internal.example", 443))

Üst düzey araçlar aynı fikri sunar: curl --interface 10.8.0.2, CURLOPT_INTERFACE PHP'de ve source_address argümanı Python'un HTTP istemcilerinde. Adres tünele ait olmalıdır ve buradaki bir yazım hatası yönlendirme şikayeti olarak değil, sıradan bir bağlantı hatası olarak başarısız olur. Adres yerine aygıt adına bağlamak bir Linux ayrıcalığıdır ve Windows ya da macOS'a taşınmaz, taşınabilir betiklerin adresi geçirmesinin nedeni budur.

Linux: program adını değil sahibi eşleştirin

Çekirdek bir soketin sahip kullanıcısını eşleştirebilir, bu yüzden ayrılmış bir hesap seçici olur. Tüneli kendi yönlendirme tablosuna koyun ve yalnızca o hesabın trafiğini oraya gönderin:

ip rule add uidrange 1001-1001 lookup 100
ip route add default dev tun0 table 100

Bu yalnızca tünel zaten varsayılan rota değilse çalışır. İstemciyi --route-nopull ile başlatın veya itilen yönlendirmeyi --pull-filter ignore "redirect-gateway" ile OpenVPN 2.4 ve sonrasında süzün, sonra tablo girdisini kendiniz ekleyin. Aksi hâlde iki varsayılan birlikte bulunur ve önceliği düşük olan kazanır. Bunun bilinçli sürümü varsayılan rotayı tünel ağ geçidine yöneltmek ya da bunu bir bağlantı kesme betiğinden yapmaktır: tünel düştüğünde trafiği internetten uzak tutar, ama bu bir öldürme anahtarıdır, seçici değildir ve biri kaldırana kadar kalır.

Daha güçlü sürüm bir ağ ad alanıdır. Oluşturun, istemciyi içinde çalıştırın ve uygulamayı ip netns exec ile başlatın. Ad alanının dışında hiçbir şey tünel arabirimini görmez, böylece uygulama kazara ana makine rotasına dönemez. Bedeli gerçektir: ad alanının fiziksel ağa ulaşmak için bir veth çiftine ve kendi çözümleyici dosyasına ihtiyacı vardır, çünkü bağlama ad alanı ana makinenin çözümleme ayarlarını paylaşmaz.

İki arıza kipi sızıntıların çoğunu açıklar. Ad çözümleme hâlâ ana makinenin çözümleyicisinde olur, bu yüzden TCP bağlantısı içeri girse bile sorgu tünelin dışına çıkar. IPv6 ise kendi ip -6 rule kuralına ihtiyaç duyar, çünkü bir v4 kuralı onu kapsamaz.

Windows ve macOS: güvenlik duvarını kapsamlayın veya bir vekil verin

Windows'un da uygulama başına rota seçicisi yoktur, ama güvenlik duvarı kuralları bir profile kapsamlanabilir ve bir VPN bağdaştırıcısı Genel olarak sınıflandırılabilirken ev LAN'ı Özel kalır. Program için Özel ve Etki Alanı profillerinde giden engelleme kuralları oluşturun, Genel'i açık bırakın ve uygulama ağa yalnızca tünelden ulaşabilsin. Önce bağlantının ağ kategorisini ayarlayın, sonra güvenlik duvarının izleme bölmesinde kuralın eşleştiğini doğrulayın. Bu bir engellemedir, rota değil: tünel düştüğünde kapalı olarak başarısız olur ve güvenlik duvarını yok sayan bir uygulamayı durduramaz.

macOS aynı mantığı farklı araçlarla izler. SSH üzerinden erişilen bir SOCKS dinleyicisi en az müdahaleci seçenektir, çünkü ssh -D 1080 user@host tek bir yerel bağlantı noktası oluşturur ve yalnızca onu kullanacak şekilde yapılandırılmış uygulamalar bu yolu izler. Bir pf kuralı bir programı kullanıcıya veya gruba göre engelleyebilir, ama yine de tüneli yalnızca o program için seçemez. Tunnelblick alan adına göre hiç süzgeç uygulayamaz, çünkü rotalar adreslerle çalışır; OpenConnect kullanıcıları sunucu çok geniş bir önek listesi ittiğinde vpn-slice aracına başvurur.

İki geçici çözüm platform araçlarının kaçırdığını kapsar. Vekili alan adına göre değiştiren tarayıcı eklentileri "yalnızca bu site" için pratik yanıttır, çünkü adların hâlâ var olduğu uygulama katmanında çalışırlar; bir tarayıcıyı kapsarlar, başka hiçbir şeyi değil. Kaba çözüm, satıcı istemcisini bir sanal makinede çalıştırmaktır; konuk rota değişikliğine sahip olur, ana makine kendi yolunu korur, bedeli iki ağ yığınını bakımda tutmaktır.

Bağlama seçeneği olmayan araçlar için SOCKS atlaması

Çoğu uygulama arabirimler hakkında hiçbir şey bilmese de bir HTTP veya SOCKS vekiline yöneltilebilir. Bir SSH istemcisi sunucu tarafında hiçbir değişiklik olmadan bir tane sağlar:

ssh -N -D 127.0.0.1:9999 [email protected]

O bağlantı noktasını kullanacak şekilde yapılandırılmış her şey siperde çıkar, masaüstünün geri kalanı normal bağlantısını korur. Tünelin adresine bağlı yerel bir 3proxy örneği SSH olmadan tek bir bağlantı noktası için aynısını yapar ve stunnel TLS ile sarılmış tek bir bağlantı noktasını kapsar. Sınırlar pratiktir: bir vekil yalnızca onu kullanmayı bilen protokolleri taşır, UDP birçok istemcinin "SOCKS5" ayarının etkinleştirmediği SOCKS5 UDP ilişkilendirmesini gerektirir ve DNS vekil tarafından çözülmelidir (socks5h curl'de) yoksa ad yerel çözümleyiciye sızar.

Başka bir makine ihtiyaç duymuyorsa dinleyiciyi geri döngüde tutun.

Yolu durum iletisiyle değil yakalamayla doğrulayın

Uygulama durum pencereleri ayarı anlatır, paketi değil. İki arabirimde de trafiği yakalayın ve karşılaştırın:

tcpdump -i any -n port 443
ss -tnp | grep 443

Bağlantı fiziksel arabirimde görünüp tünelde eşleşen bir girdi yoksa, istemci ne bildirirse bildirsin seçici yürürlükte değildir. IPv6'yı ve çözümleyiciyi ayrı ayrı denetleyin ve yardımcı bir süreç ya da devralınan bir sistem vekili gibi ikinci bir yol arayın.

Sonra gereksinime uyan sınırı seçin: bir site için vekil yeterlidir, bir hesap için UID kuralı yeterlidir, bağlantının kapalı olarak başarısız olması gerektiğinde güvenlik duvarı profili yeterlidir ve ad alanı tüneli dışındaki her şeyden saklayan tek seçenektir.