Ingen brytar for å utelate denne appen: gje prosessen si eiga kjelde

Ruting samanliknar adresser, ikkje prosessnamn. Gje det utelatne programmet si eiga kjelde og tabell, eller flytt avgjerda til rutaren, der det er ærleg.

Eitt program skal bruke den vanlege sambindinga medan alt anna blir verande i tunnelen, og klienten har ingen brytar for det. Det finst heller ikkje noko skjult meny å finne. Ei rute blir vald frå felt inne i pakken, og pakken ber adresser og portar i staden for identiteten til prosessen som laga han, så ei utelating må uttrykkjast i eitt av desse felta. Fylg ein pakke éin gong, og dei tilgjengelege vala sluttar å vere mystiske.

Kvifor klienten ikkje kan tilby det

Destinasjonsruting samanliknar destinasjonsadressa med prefiks og held det lengste treffet. I det augneblinken ser kvar pakke lik ut, same kva som laga henne. Kjeldepolicy-ruting utvidar samanlikninga til kjeldadressa, og det er kroken kvar praktisk løysing brukar: endre kjelda, og ein annan tabell blir aktuell.

Portar hjelper ikkje. Ei utelating etter port måtte vurderast før destinasjonsoppslaget, og porten spelar inga rolle i den avgjerda. Alt som blir annonsert som portbasert utelating, utelèt eigentleg etter eit anna felt og skildrar det laust.

Ekte ruting per applikasjon finst der plattforma har lagt til maskineri for det, som filterkall på Windows eller VPN-tenestebindinga på Android. Ein skrivebordsinstans av OpenVPN leverer ingenting av dette, og ingen konfigurasjonsflagg finn det opp.

Linux: merk prosessen, rut deretter merket

Den reinaste tilnærminga knyter avgjerda til prosessen som eig socketen. owner-treffet verkar for lokalt generert trafikk i OUTPUT-kjeda, så eit merke som blir sett der kan velje ein eigen tabell:

iptables -t mangle -A OUTPUT -m owner --uid-owner 1001 -j MARK --set-mark 0x1
ip rule add fwmark 0x1 table 200
ip route add 192.168.1.0/24 dev eth0 src 192.168.1.0 table 200
ip route add default via 192.168.1.1 dev eth0 table 200

Pakkar frå brukar 1001 konsulterer då tabell 200 og forlèt via den vanlege gatewayen, medan hovudtabellen framleis sender alt anna inn i tunnelen. owner-treffet gjeld berre for lokalt genererte pakkar, som er nøyaktig den trafikken som tel her, og det kan ikkje klassifisere pakkar som blir vidaresende for ein annan vert. Stadfest med verktøya og ikkje med intensjonen: ss -tnp viser den lokale adressa og den eigande prosessen for etablerte samband, og ip route get 1.1.1.1 mark 0x1 viser kva tabell merket vel.

Eit nettverksnamnerom er det meir robuste svaret for eit sjølvstendig program, fordi kvar socket som blir oppretta der inne er bunden til det av konstruksjon, så hjelpeprosessar og underordna samband arvar åtferda utan å bli klassifiserte i det heile. Prisen er røyrleggjararbeid: eit veth-par, ei adresse i kvar ende og ei standardrute inne i namnerommet som peikar tilbake til verten.

ip netns add novpn
ip link add veth-host type veth peer name veth-ns
ip link set veth-ns netns novpn
ip addr add 10.200.0.1/24 dev veth-host
ip netns exec novpn ip addr add 10.200.0.2/24 dev veth-ns
ip netns exec novpn ip route add default via 10.200.0.1

Windows: destinasjonen avgjer framleis

Windows vel det utgåande grensesnittet ut frå destinasjonen, så eit program som vil ha ein annan veg må endre noko stakken spør om før det valet blir teke. ForceBindIP dekkjer den første halvdelen: det startar eit program med socketane alt bundne til ei lokal adresse du oppgir. Det åleine endrar ikkje kva grensesnitt pakken forlèt via, fordi destinasjonen framleis vel ruta. Bind ei kjelde på ein berbar PC der standardruta peikar inn i tunnelen, og pakken går likevel inn i tunnelen.

Symptomet har ei lesbar form når du først kjenner det. Det gjeld for ei LAN-adresse som det valde grensesnittet når direkte, og feilar for alt på internett der ruta peikar mot tunnelen. Det ser òg ut til å verke heilt til programmet gir arbeid til ein hjelpar, fordi ein hjelpar som opnar sin eigen socket aldri fekk vite om bindinga.

Flytt avgjerda når éin prosess er feil eining

Viss det eigentlege kravet er eining og ikkje program, set henne på sitt eige SSID eller VLAN og lat rutaren avgjere: den kjelda tek den normale vegen medan andre kjelder brukar tunnelen. Ein dedikert gateway-maskin er det andre ærlege designet: han held VPN-en og tek berre imot destinasjonane rutaren sender til han. På eit VLAN dekkjer policyen kvar straum eininga opnar, inkludert hjelpeprosessane som knuste Windows-tilnærminga. Bytet er omfang: to program på den eininga kan ikkje lenger handsamast ulikt.

Begge er kjelde- eller destinasjonspolicyar med eit omfang du kan seie i éin setning. Ingen av dei er per applikasjon, og eit design som sel seg som per applikasjon, feilar første gong programmet delegerer arbeidet sitt til ein andre prosess.

Relaterte artiklar