Egy alkalmazás átirányítása VPN-en keresztül a teljes gép nélkül

A VPN-kliens kapcsolódik, a böngésző működik, és az az egyetlen parancs, amely igazán számít, még mindig az otthoni kapcsolatán keresztül megy ki. Vagy az ellenkezője történik: az alagút átveszi az alapértelmezett útvonalat, és a helyi fájlszerver eltűnik az asztalról. Ezzel egy build-ügynöknél találkoztam, amelynek el kellett érnie egy belső artefaktumtükröt, miközben a gazdagép többi része az irodai LAN-on maradt, és a kliens pontosan két választási lehetőséget kínált: minden forgalom vagy semmi. A kérés mindkét irányban ugyanaz, ez a program és nem a teljes gép, és a legtöbb kliensnek nincs erre jelölőnégyzete, mert az útvonaltábla soha nem tudta, mi az a program.

Miért nem látja az útvonaltábla a programját

Amikor egy folyamat csomagot küld, a verem az útvonaltáblában keresi a célcímet. Sem a futtatható fájl neve, sem a port nem kerül bele ebbe a keresésbe. A tartománynevek ugyanezen okból vallanak kudarcot: az alagút forgalmat visz egy címre, és mire egy név címmé oldódik, az útválasztás az egyetlen kar, amely még a kernel kezében van. Ezért a „VPN csak ehhez az oldalhoz” végül proxyt jelent, a „VPN csak ehhez a programhoz” pedig egyet egy kis mechanizmuscsoportból.

Ezek egyike sem folyamatonkénti útvonal. Mindegyik olyan rétegre viszi a döntést, amely látja a programot, a felhasználót vagy az alkalmazás saját konfigurációját.

Egyetlen cél még mindig útvonal, nem programszabály. macOS-en a szokásos recept a „Minden forgalom küldése VPN-en” jelölés levétele és egy gazdagép-útvonal hozzáadása: sudo route add -host internal-tuner.example -interface ppp0, amelyet ismét a sudo route delete -host internal-tuner.example -interface ppp0 távolít el. Először olvassa ki az interfész nevét a ifconfig kimenetéből, mert a ppp0 csak példa. A helyettesítő karakterek nem működnek gazdagép-útvonalban, ezért a több névvel beszélő szolgáltatásnak névenként egy bejegyzés kell, és a szabály a gép minden folyamatára kiterjed, nem arra, amelyre gondolt.

Kösse a socketet az alagút címéhez

Ha Ön irányítja a klienst, a kötés a legolcsóbb választó. Az alagút helyi címéhez kötött socket ezen az interfészen megy ki, amíg ott létezik útvonal a célhoz, és a gép minden más része megtartja a szokásos útját. A finomság az, hogy a kötés a forrás címet választja, miközben az útvonaltábla továbbra is a kijáratot választja. A kötés önmagában nem mozgatja azt a forgalmat, amelynek nincs útvonala az alagútba, és pontosan ez a hiba a legtöbb „bekötöttem, és mégis rossz felé megy ki” jelentés mögött.

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

A magasabb szintű eszközök ugyanezt az ötletet kínálják: curl --interface 10.8.0.2, CURLOPT_INTERFACE PHP-ban és a source_address argumentum a Python HTTP-klienseiben. A címnek az alagúthoz kell tartoznia, és az itteni elírás közönséges kapcsolódási hibaként vall kudarcot, nem útválasztási panasz. Az eszköznévhez kötés cím helyett Linux-kiváltság, és nem vihető át Windowsra vagy macOS-re, ezért a hordozható szkriptek a címet adják át.

Linux: a tulajdonost egyeztesse, ne a program nevét

A kernel egyeztetheti a socket tulajdonos felhasználóját, így egy dedikált fiók lesz a választó. Tegye az alagutat a saját útvonaltáblájába, és csak annak a fióknak a forgalmát küldje oda:

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

Ez csak akkor működik, ha az alagút nem már az alapértelmezett útvonal. Indítsa a klienst a --route-nopull kapcsolóval, vagy szűrje a küldött átirányítást a --pull-filter ignore "redirect-gateway" kapcsolóval OpenVPN 2.4 és újabb verzióin, majd maga adja hozzá a táblabejegyzést. Különben mindkét alapértelmezés létezik, és az alacsonyabb prioritású nyer. Ennek szándékos változata az alapértelmezett útvonalat az alagút átjárójára irányítani, vagy ezt leválasztó szkriptből megtenni: távol tartja a forgalmat az internettől, amikor az alagút elesik, de ez vészkapcsoló, nem választó, és addig marad, amíg valaki el nem távolítja.

Az erősebb változat egy hálózati névtér. Hozza létre, futtassa benne a klienst, és indítsa az alkalmazást a ip netns exec kapcsolóval. A névtéren kívül semmi nem látja az alagút interfészét, így az alkalmazás nem eshet vissza véletlenül a gazdagép útvonalára. Az ár valódi: a névtérnek veth-párra van szüksége a fizikai hálózat eléréséhez és saját feloldófájlra, mert a csatolási névtér nem osztja meg a gazdagép feloldási beállításait.

Két hibatípus magyarázza a legtöbb szivárgást. A névfeloldás továbbra is a gazdagép feloldójában történik, ezért a lekérdezés az alagúton kívülre megy, akkor is, ha a TCP-kapcsolat befelé halad. Az IPv6-nak pedig saját ip -6 rule kell, mert a v4-szabály nem fedi le.

Windows és macOS: szűkítse a tűzfalat, vagy adjon át proxyt

A Windowsnak sincs alkalmazásonkénti útvonalválasztója, de a tűzfalszabályai profilra szűkíthetők, és a VPN-adapter „nyilvánosként” osztályozható, miközben az otthoni LAN „privát” marad. Hozzon létre kimenő blokkolószabályokat a programhoz a „privát” és „tartomány” profilokon, hagyja nyitva a „nyilvános” profilt, és az alkalmazás csak az alagúton keresztül érheti el a hálózatot. Először állítsa be a kapcsolat hálózati kategóriáját, majd erősítse meg, hogy a szabály illeszkedett a tűzfal figyelőpaneljén. Ez blokk, nem útvonal: zárt állapotban vall kudarcot, amikor az alagút elesik, és nem tud megállítani egy alkalmazást, amely figyelmen kívül hagyja a tűzfalat.

A macOS ugyanezt a logikát követi más eszközökkel. Az SSH-n keresztül elérhető SOCKS-hallgató a legkevésbé beavatkozó lehetőség, mert a ssh -D 1080 user@host egy helyi portot hoz létre, és csak az erre beállított alkalmazások mennek ezen az úton. A pf szabály felhasználó vagy csoport szerint blokkolhat egy programot, de továbbra sem tudja kiválasztani az alagutat csak ahhoz a programhoz. A Tunnelblick egyáltalán nem tud tartomány szerint szűrni, mert az útvonalak címekkel dolgoznak; az OpenConnect felhasználói a vpn-slice eszközhöz fordulnak, amikor a szerver túl széles előtaglistát küld.

Két kerülőút fedi le azt, amit a platform eszközei elmulasztanak. A proxyt tartományonként váltó böngészőkiegészítők a gyakorlati válasz a „csak ez az oldal” kérésre, mert az alkalmazási rétegen hatnak, ahol a nevek még léteznek; egy böngészőt fednek le, és semmi mást. A durva megoldás a szállító kliensét virtuális gépben futtatni, hogy a vendég birtokolja az útvonalváltást, míg a gazdagép megtartja a maga útját, két karbantartandó hálózati verem árán.

SOCKS-ugrás a kötési lehetőség nélküli eszközöknek

A legtöbb alkalmazás HTTP vagy SOCKS proxyra irányítható akkor is, ha semmit nem tud az interfészekről. Az SSH-kliens egyet kínál a kiszolgáló oldalán végzett változtatás nélkül:

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

Minden, ami erre a portra van beállítva, a bastionnál lép ki, míg az asztal többi része megtartja a szokásos kapcsolatát. Az alagút címéhez kötött helyi 3proxy példány ugyanezt teszi egy portra SSH nélkül, és a stunnel egyetlen TLS-be csomagolt portot fed le. A korlátok gyakorlatiak: a proxy csak azokat a protokollokat viszi, amelyek tudják használni, az UDP-hez SOCKS5 UDP-társítás kell, amelyet sok kliens „SOCKS5” beállítása nem kapcsol be, és a DNS-t a proxynak kell feloldania (socks5h a curlben), különben a név kiszivárog a helyi feloldóhoz.

Tartsa a hallgatót loopbacken, hacsak egy másik gépnek nincs rá szüksége.

Rögzítéssel ellenőrizze az utat, ne állapotüzenettel

Az alkalmazás állapotablakai a beállítást írják le, nem a csomagot. Rögzítsen mindkét interfészen, és hasonlítsa össze:

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

Ha a kapcsolat a fizikai interfészen jelenik meg, és nincs hozzá tartozó bejegyzés az alagúton, a választó nincs hatályban, bármit is jelent a kliens. Ellenőrizze külön az IPv6-ot és a feloldót, valamint azt, hogy van-e második út, például segédfolyamat vagy örökölt rendszerproxy.

Ezután válassza ki a követelményhez illő határt: egy proxy elég egy oldalhoz, egy UID-szabály elég egy fiókhoz, egy tűzfalprofil elég, ha a kapcsolatnak zártan kell kudarcot vallania, és a névtér az egyetlen lehetőség, amely elrejti az alagutat minden kívülről.