Ien programma troch in VPN stjoere sûnder de hiele masine

De VPN-klant ferbynt, de browser wurket, en it iene kommando dêr’t jo echt om jouwe giet noch altyd troch jo thúsferbining. Of it tsjinoerstelde bart: de tunnel pakt de standertrûte en de lokale bestânsserver ferdwynt fan it buroblêd. Ik kaam dit tsjin by in build-agent dy’t in ynterne artefakt-spegel berikke moast wylst de rest fan ’e host op it kantoar-LAN bleau, en de klant bea krekt twa karren: al it ferkear of neat. It fersyk is yn beide rjochtingen itselde, dit programma en net de hiele masine, en de measte klanten hawwe dêr gjin kontrôlefakje foar, om’t de rûte-tabel nea witten hat wat in programma is.

Wêrom’t de rûte-tabel jo programma net sjen kin

As in proses in pakket stjoert, siket de stapel it bestimmingsadres yn ’e rûte-tabel. Noch de namme fan it útfierbere bestân, noch de poarte komt yn dy syktocht. Domeinnammen mislearje om deselde reden: in tunnel fiert ferkear nei in adres, en as in namme ienris yn in adres oplost is, is rûtebepaling de iennige hefbeam dy’t de kearn noch hat. Dêrom betsjut „VPN allinnich foar dizze side“ úteinlik in proxy, en „VPN allinnich foar dit programma“ ien út in lyts samling meganismen.

Gjin fan dizze is in rûte per proses. Elk ferpleatst de beslissing nei in laach dy’t it programma, de brûker of de eigen konfiguraasje fan ’e applikaasje sjen kin.

Ien bestimming is noch altiten in rûte, gjin programmaregel. Op macOS is it gewoane resept it ôffinkje „Al it ferkear oer VPN stjoere“ weihelje en in hostrûte taheakje: sudo route add -host internal-tuner.example -interface ppp0, wer fuorthelle mei sudo route delete -host internal-tuner.example -interface ppp0. Lês earst de namme fan ’e ynterface út ifconfig, om’t ppp0 mar in foarbyld is. Jokertekens wurkje net yn in hostrûte, dus in tsjinst dy’t mei ferskate nammen praat hat ien ynfier per namme nedich, en de regel beslacht elk proses op ’e masine, net dat jo yn ’t sin hiene.

Bin it socket oan it adres fan ’e tunnel

As jo de klant beheare, is binen de goedkeapste selektearder. In socket bûn oan it lokale adres fan ’e tunnel giet troch dy ynterface nei bûten salang’t dêr in rûte nei de bestimming bestiet, en al it oare op ’e masine hâldt syn normale paad. It fynske is dat it binen it boarneadres kiest wylst de rûte-tabel noch altiten de útgong kiest. Binen allinnich ferpleatst gjin ferkear dat gjin rûte yn ’e tunnel hat, en dat is de flater efter de measte berjochten „ik haw it bûn en it giet noch altyd de ferkearde kant út“.

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

Ark fan heger nivo biede itselde idee: curl --interface 10.8.0.2, CURLOPT_INTERFACE yn PHP en it argumint source_address yn ’e HTTP-klanten fan Python. It adres moat by de tunnel hearre, en in typflater hjir mislearret as in gewoane ferbiningsflater, net as in klacht oer rûtebepaling. Binen oan in apparaatnamme ynstee fan in adres is in Linux-foarrjocht en giet net oer nei Windows of macOS, dêrom jouwe draachbere skripts it adres troch.

Linux: keppelje de eigner, net de programmanamme

De kearn kin de eigner-brûker fan in socket keppelje, dus in ta wijd akkount wurdt de selektearder. Set de tunnel yn syn eigen rûte-tabel en stjoer dêr allinnich it ferkear fan dat akkount hinne:

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

Dit wurket allinnich as de tunnel noch net de standertrûte is. Start de klant mei --route-nopull, of filter de treaune trochstjoering mei --pull-filter ignore "redirect-gateway" op OpenVPN 2.4 en letter, en foegje dan sels de tabelynfier ta. Oars bestean beide standerten en wint dy mei de legere prioriteit. De bewuste ferzje dêrfan is de standertrûte nei de gateway fan ’e tunnel wize, of dat út in ôfskiedingsskript wei dwaan: it hâldt ferkear bûten it ynternet as de tunnel falt, mar dat is in needstop, gjin selektearder, en it bliuwt oant immen it fuorthellet.

De sterkere ferzje is in netwurk-namme romte. Meitsje it oan, rin de klant derbinnen en start de applikaasje mei ip netns exec. Neat bûten de nammeromte sjocht de tunnel-ynterface, dus de applikaasje kin net by ûngelok weromfalle op ’e rûte fan ’e host. De kosten binne echt: de nammeromte hat in veth-pear nedich om it fysike netwurk te berikken en in eigen resolver-bestân, om’t de mount-namme romte de oplossingsynstellingen fan ’e host net dielt.

Twa flatermodi ferklearje de measte lekken. Namme-oplossing bart noch altiten yn ’e resolver fan ’e host, dus it fersyk giet bûten de tunnel om sels as de TCP-ferbining nei binnen giet. En IPv6 hat syn eigen ip -6 rule nedich, om’t in v4-regel it net beslacht.

Windows en macOS: behein de firewall of jou in proxy oer

Windows hat ek gjin rûte-selektearder per applikaasje, mar syn firewall-regels kinne ta in profyl beheind wurde, en in VPN-adapter kin as „iepenbier“ klassifisearre wurde wylst it thús-LAN „privee“ bliuwt. Meitsje útgeande blokkearregels foar it programma yn ’e profylen „privee“ en „domein“, lit „iepenbier“ iepen, en de applikaasje kin it netwurk allinnich troch de tunnel berikke. Set earst de netwurk-kategory fan ’e ferbining, en befêstigje dan dat de regel yn it monitorpaneel fan ’e firewall oerienkaam. It is in blokkade, gjin rûte: hy mislearret sletten as de tunnel falt, en hy kin in applikaasje dy’t de firewall negearret net stopje.

macOS folget deselde logika mei oare ark. In SOCKS-harker berikt fia SSH is de minst yngeande opsje, om’t ssh -D 1080 user@host ien lokale poarte makket en allinnich applikaasjes dy’t dêrfoar konfigurearre binne dat paad nimme. In regel pf kin in programma blokkearje op brûker of groep, mar hy kin de tunnel noch altiten net foar dat programma allinnich kieze. Tunnelblick kin hielendal net op domein filterje, om’t rûtes mei adressen wurkje; brûkers fan OpenConnect gripe nei vpn-slice as de server in te brede foarheaksel-list treaut.

Twa omwegen dekke wat de ark fan it platfoarm misse. Browser-útwreidings dy’t de proxy per domein wikselje binne it praktyske antwurd foar „allinnich dizze side“, om’t se op ’e applikaasjelaach wurkje dêr’t nammen noch bestean; se dekke ien browser en fierder neat. De grove oplossing is de klant fan ’e leveransier yn in firtuele masine rinne litte, sadat de gast de rûteferoaring besit wylst de host syn paad hâldt, tsjin de kosten fan twa netwurkstapels om te ûnderhâlden.

In SOCKS-sprong foar ark sûnder biningsopsje

De measte applikaasjes kinne nei in HTTP- of SOCKS-proxy rjochte wurde sels as se neat fan ynterfaces witte. In SSH-klant leveret ien sûnder feroaring oan ’e serverkant:

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

Alles dat konfigurearre is om dy poarte te brûken giet by de bastion nei bûten, wylst de rest fan it buroblêd syn normale ferbining hâldt. In lokale eksimplaar fan 3proxy bûn oan it adres fan ’e tunnel docht itselde foar ien poarte sûnder SSH, en stunnel beslacht ien poarte ferpakt yn TLS. De grinzen binne praktysk: in proxy fiert allinnich protokollen dy’t witte hoe’t se him brûke moatte, UDP hat in SOCKS5 UDP-assoasjaasje nedich dy’t de „SOCKS5“-ynstelling fan in protte klanten net oansette, en DNS moat troch de proxy oplost wurde (socks5h yn curl), oars lekt de namme nei de lokale resolver.

Hâld de harker op loopback, útsein as in oare masine him nedich hat.

Kontrolearje it paad mei in opname, net mei in statusberjocht

Statusfinsters fan applikaasjes beskriuwe de ynstelling, net it pakket. Meitsje opnamen op beide ynterfaces en fergelykje:

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

As de ferbining op ’e fysike ynterface ferskynt sûnder byhearrende ynfier op ’e tunnel, is de selektearder net fan krêft, wat de klant ek berjochtet. Kontrolearje IPv6 en de resolver apart, en kontrolearje op in twadde paad lykas in help-proses of in erfd systeem-proxy.

Kies dan de grins dy’t by de eask past: in proxy is genôch foar ien side, in UID-regel is genôch foar ien akkount, in firewall-profyl is genôch as de ferbining sletten mislearje moat, en in nammeromte is de iennige opsje dy’t de tunnel foar alles bûten ferstoppet.