Ingen kontakt til at udelukke denne app: giv processen sin egen kilde

Et program bør bruge den almindelige forbindelse, mens alt andet bliver på tunnelen, og klienten har ingen kontakt til det. Der er heller ingen skjult menu at finde. En rute vælges ud fra felter inde i pakken, og pakken bærer adresser og porte snarere end identiteten af den proces, der skabte den, så en udelukkelse skal udtrykkes i et af disse felter. Gå en pakke igennem én gang, og de tilgængelige muligheder holder op med at være mystiske.

Hvorfor klienten ikke kan tilbyde det

Destinationsrouting sammenligner destinationsadressen med præfikser og beholder det længste match. I det øjeblik ser enhver pakke ens ud, uanset hvad der har skabt den. Kildepolitik-routing udvider sammenligningen til kildeaddressen, og det er den krog, enhver praktisk løsning bruger: ændr kilden, og en anden tabel bliver aktuel.

Porte hjælper ikke. En udelukkelse efter port skulle vurderes før destinationsopslaget, og porten spiller ingen rolle i den beslutning. Alt, der annonceres som portbaseret udelukkelse, udelukker i virkeligheden efter et andet felt og beskriver det løst.

Ægte routing pr. applikation findes, hvor platformen har tilføjet maskineri til det, som filterkald på Windows eller VPN-tjenestebindingen på Android. En desktop-instans af OpenVPN leverer intet af det, og ingen konfigurationsflag opfinder det.

Linux: markér processen, og rut så markeringen

Den reneste tilgang knytter beslutningen til den proces, der ejer socket'en. Match på owner virker for lokalt genereret trafik i OUTPUT-kæden, så en markering anvendt der kan vælge en separat tabel:

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 bruger 1001 konsulterer derefter tabel 200 og forlader netværket via den almindelige gateway, mens hovedtabellen stadig sender alt andet ind i tunnelen. Match på owner gælder kun for lokalt genererede pakker, hvilket er præcis den trafik, du har brug for her, og det kan ikke klassificere pakker, der videresendes for en anden vært. Kontrollér med værktøjerne frem for hensigten: ss -tnp viser den lokale adresse og den ejende proces for etablerede forbindelser, og ip route get 1.1.1.1 mark 0x1 viser, hvilken tabel markeringen vælger.

Et netværksnamespace er det mere robuste svar til et selvstændigt program, fordi enhver socket, der oprettes deri, er bundet til det per konstruktion, så hjælpeprocesser og underordnede forbindelser arver adfærden uden at blive klassificeret overhovedet. Prisen er VVS: et veth-par, en adresse i hver ende og en standardrute inde i namespacet, der peger tilbage på værten.

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: destinationen bestemmer stadig

Windows vælger den udgående grænseflade ud fra destinationen, så et program, der vil have en anden vej, må ændre noget, som stakken konsulterer, før det valg træffes. ForceBindIP dækker den første halvdel: det starter et program med sockets, der allerede er bundet til en lokal adresse, du angiver. Det alene ændrer ikke, hvilken grænseflade pakken forlader via, fordi destinationen stadig vælger ruten. Bind en kilde på en bærbar computer, hvis standardrute peger ind i tunnelen, og pakken går alligevel ind i tunnelen.

Symptomet har en læsbar form, når du først kender det. Det gælder for en LAN-adresse, som den valgte grænseflade når direkte, og fejler for alt på internettet, hvis rute peger på tunnelen. Det ser også ud til at virke, indtil programmet giver arbejde til en hjælper, fordi en hjælper, der åbner sin egen socket, aldrig blev fortalt om bindingen.

Flyt beslutningen, når én proces er den forkerte enhed

Hvis det egentlige krav er en enhed og ikke et program, så sæt den på sit eget SSID eller VLAN og lad routeren bestemme: den kilde tager den normale vej, mens andre kilder bruger tunnelen. En dedikeret gateway-maskine er det andet ærlige design: den holder VPN'en og modtager kun de destinationer, som routeren sender til den. På et VLAN dækker politikken hver strøm, enheden åbner, inklusive de hjælpeprocesser, der brød Windows-tilgangen. Handlen er omfang: to programmer på den enhed kan ikke længere behandles forskelligt.

Begge er kilde- eller destinationspolitikker med et omfang, du kan angive i én sætning. Ingen af dem er pr. applikation, og et design, der sælger sig som pr. applikation, fejler første gang, programmet overlader sit arbejde til en anden proces.