Ingen bryter for å utelate denne appen: gi prosessen sin egen kilde

Ett program skal bruke den vanlige forbindelsen mens alt annet blir værende i tunnelen, og klienten har ingen bryter for det. Det finnes heller ingen skjult meny å finne. En rute velges fra felt inne i pakken, og pakken bærer adresser og porter i stedet for identiteten til prosessen som lagde den, så en utelatelse må uttrykkes i ett av disse feltene. Følg en pakke én gang, og de tilgjengelige valgene slutter å være mystiske.

Hvorfor klienten ikke kan tilby det

Destinasjonsruting sammenligner destinasjonsadressen med prefikser og beholder det lengste treffet. I det øyeblikket ser hver pakke lik ut, uansett hva som lagde den. Kildepolicy-ruting utvider sammenligningen til kildeadressen, og det er kroken enhver praktisk løsning bruker: endre kilden, og en annen tabell blir aktuell.

Porter hjelper ikke. En utelatelse etter port måtte vurderes før destinasjonsoppslaget, og porten spiller ingen rolle i den beslutningen. Alt som annonseres som portbasert utelatelse, utelater egentlig etter et annet felt og beskriver det løst.

Ekte ruting per applikasjon finnes der plattformen har lagt til maskineri for det, som filterkall på Windows eller VPN-tjenestebindingen på Android. En skrivebordsinstans av OpenVPN leverer ingenting av det, og ingen konfigurasjonsflagg finner det opp.

Linux: merk prosessen, rut deretter merket

Den reneste tilnærmingen knytter beslutningen til prosessen som eier socketen. owner-treffet virker for lokalt generert trafikk i OUTPUT-kjeden, så et merke som settes der kan velge en egen 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

Pakker fra bruker 1001 konsulterer da tabell 200 og forlater via den vanlige gatewayen, mens hovedtabellen fortsatt sender alt annet inn i tunnelen. owner-treffet gjelder bare for lokalt genererte pakker, som er nøyaktig den trafikken som betyr noe her, og det kan ikke klassifisere pakker som videresendes for en annen vert. Verifiser med verktøyene og ikke med intensjonen: ss -tnp viser den lokale adressen og den eierende prosessen for etablerte forbindelser, og ip route get 1.1.1.1 mark 0x1 viser hvilken tabell merket velger.

Et nettverksnavnerom er det mer robuste svaret for et selvstendig program, fordi hver socket som opprettes der inne er bundet til det av konstruksjon, så hjelpeprosesser og underordnede forbindelser arver oppførselen uten å bli klassifisert i det hele tatt. Prisen er rørleggerarbeid: et veth-par, en adresse i hver ende og en standardrute inne i navnerommet som peker 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 bestemmer fortsatt

Windows velger det utgående grensesnittet ut fra destinasjonen, så et program som vil ha en annen vei må endre noe stakken spør om før det valget tas. ForceBindIP dekker den første halvdelen: det starter et program med socketene allerede bundet til en lokal adresse du oppgir. Det alene endrer ikke hvilket grensesnitt pakken forlater via, fordi destinasjonen fortsatt velger ruten. Bind en kilde på en bærbar PC der standardruten peker inn i tunnelen, og pakken går likevel inn i tunnelen.

Symptomet har en lesbar form når du først kjenner det. Det gjelder for en LAN-adresse som det valgte grensesnittet når direkte, og feiler for alt på internett der ruten peker mot tunnelen. Det ser også ut til å virke helt til programmet gir arbeid til en hjelper, fordi en hjelper som åpner sin egen socket aldri ble fortalt om bindingen.

Flytt beslutningen når én prosess er feil enhet

Hvis det egentlige kravet er en enhet og ikke et program, sett den på sitt eget SSID eller VLAN og la ruteren bestemme: den kilden tar den normale veien mens andre kilder bruker tunnelen. En dedikert gateway-maskin er det andre ærlige designet: den holder VPN-en og mottar bare destinasjonene ruteren sender til den. På et VLAN dekker policyen hver strøm enheten åpner, inkludert hjelpeprosessene som knuste Windows-tilnærmingen. Byttet er omfang: to programmer på den enheten kan ikke lenger behandles ulikt.

Begge er kilde- eller destinasjonspolicyer med et omfang du kan si i én setning. Ingen av dem er per applikasjon, og et design som selger seg som per applikasjon, feiler første gang programmet delegerer arbeidet sitt til en andre prosess.