Geen skakelaar om hierdie app uit te sluit nie: gee die proses sy eie bron

Een program moet die gewone verbinding gebruik terwyl alles anders op die tonnel bly, en die kliënt het geen skakelaar daarvoor nie. Daar is ook geen versteekte kieslys om te vind nie. ’n Roete word gekies uit velde binne die pakket, en die pakket dra adresse en poorte eerder as die identiteit van die proses wat dit geskep het, dus moet ’n uitsluiting in een van daardie velde uitgedruk word. Volg ’n pakket een keer en die beskikbare opsies hou op om raaiselagtig te wees.

Waarom die kliënt dit nie kan bied nie

Bestemmingsroetering vergelyk die bestemmingsadres met voorvoegsels en hou die langste passing. Elke pakket lyk op daardie oomblik dieselfde, wat dit ook al geproduseer het. Bronbeleidroetering verbreed die vergelyking na die bronadres, en dit is die haak wat elke praktiese oplossing gebruik: verander die bron, en ’n ander tabel word beskikbaar.

Poorte help nie. ’n Uitsluiting op poort sou voor die bestemmingsopsoek geëvalueer moes word, en die poort speel geen rol in daardie besluit nie. Enigiets wat as poortgebaseerde uitsluiting geadverteer word, sluit eintlik op een of ander ander veld uit en beskryf dit vaag.

Egte roetering per toepassing bestaan waar die platform daarvoor masjinerie bygevoeg het, soos filteroproepinge op Windows of die VPN-diensbinding op Android. ’n Lessenaar-OpenVPN-instansie lewer niks daarvan nie, en geen konfigurasievlag vind dit uit nie.

Linux: merk die proses, roet dan die merk

Die skoonste benadering koppel die besluit aan die proses wat die socket besit. Die owner-passing werk vir plaaslik gegenereerde verkeer in die OUTPUT-ketting, so ’n merk wat daar toegepas word, kan ’n aparte tabel kies:

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

Pakkette van gebruiker 1001 raadpleeg dan tabel 200 en verlaat die netwerk via die gewone poort, terwyl die hoof-tabel steeds alles anders in die tonnel stuur. Die owner-passing geld slegs vir plaaslik gegenereerde pakkette, wat presies die verkeer is waaroor jy hier bekommerd is, en dit kan nie pakkette klassifiseer wat vir ’n ander gasheer gestuur word nie. Verifieer met die gereedskap eerder as met die bedoeling: ss -tnp wys die plaaslike adres en die besitproses van bestaande verbindings, en ip route get 1.1.1.1 mark 0x1 wys watter tabel die merk kies.

’n netwerk-naamruimte is die stewiger antwoord vir ’n selfstandige program, want elke socket wat daarin geskep word, is per konstruksie daaraan gebind, so hulpprosesse en kindverbindings erf die gedrag sonder om hoegenaamd geklassifiseer te word. Die koste is loodgieterswerk: ’n veth-paar, ’n adres aan elke kant, en ’n verstekroete binne die naamruimte wat terug na die gasheer wys.

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: die bestemming besluit steeds

Windows kies die uitgaande koppelvlak op grond van die bestemming, so ’n program wat ’n ander pad wil hê, moet iets verander wat die stapel raadpleeg voordat daardie keuse gemaak word. ForceBindIP dek die eerste helfte: dit begin ’n program met sy sockets reeds gebind aan ’n plaaslike adres wat jy noem. Dit alleen verander nie watter koppelvlak die pakket verlaat nie, want die bestemming kies steeds die roete. Bind ’n bron op ’n skootrekenaar wie se verstekroete in die tonnel in wys, en die pakket gaan steeds in die tonnel in.

Die simptoom het ’n leesbare vorm sodra jy dit ken. Dit geld vir ’n LAN-adres wat die gekose koppelvlak direk bereik, en misluk vir enigiets op die internet wie se roete na die tonnel wys. Dit lyk ook of dit werk totdat die program werk aan ’n helper oorhandig, want ’n helper wat sy eie socket oopmaak, is nooit van die binding vertel nie.

Skuif die besluit wanneer een proses die verkeerde eenheid is

As die werklike vereiste ’n toestel eerder as ’n program is, plaas dit op sy eie SSID of VLAN en laat die roeter besluit: daardie bron neem die normale pad terwyl ander bronne die tonnel gebruik. ’n Toegewyde poortrekenaar is die ander eerlike ontwerp; dit hou die VPN en ontvang net die bestemmings wat die roeter aan hom stuur. Op ’n VLAN dek die beleid elke vloei wat die toestel oopmaak, insluitend die hulpprosesse wat die Windows-benadering gebreek het. Die ruil is omvang: twee programme op daardie toestel kan nie meer anders behandel word nie.

Albei is bron- of bestemmingsbeleide met ’n omvang wat jy in een sin kan stel. Nie een is per toepassing nie, en ’n ontwerp wat homself as per toepassing adverteer, misluk die eerste keer wanneer die program sy werk aan ’n tweede proses delegeer.