Fără comutator „exclude această aplicație”: dați procesului propria sursă

Un program ar trebui să folosească conexiunea obișnuită în timp ce tot restul rămâne în tunel, iar clientul nu are niciun comutator pentru asta. Nu există nici un meniu ascuns de găsit. O rută se alege din câmpuri din interiorul pachetului, iar pachetul transportă adrese și porturi, nu identitatea procesului care l-a creat, așa că o excludere trebuie exprimată într-unul dintre acele câmpuri. Urmați un pachet o dată și opțiunile disponibile încetează să mai fie misterioase.

De ce clientul nu o poate oferi

Rutarea pe destinație compară adresa de destinație cu prefixe și păstrează cea mai lungă potrivire. În acel moment fiecare pachet arată la fel, orice l-ar fi produs. Rutarea pe politică de sursă lărgește comparația la adresa sursă, și acesta este cârligul pe care îl folosește orice soluție practică: schimbați sursa și un alt tabel devine eligibil.

Porturile nu ajută. O excludere după port ar trebui evaluată înainte de căutarea destinației, iar portul nu joacă niciun rol în acea decizie. Tot ce este promovat ca excludere bazată pe port exclude de fapt după un alt câmp și descrie asta în mod lax.

Rutarea reală pe aplicație există acolo unde platforma a adăugat mecanismul pentru ea, cum ar fi apelurile de filtru în Windows sau legarea serviciului VPN în Android. O instanță desktop de OpenVPN nu aduce nimic din asta, iar niciun indicator de configurare nu o inventează.

Linux: marcați procesul, apoi rutați marcajul

Cea mai curată abordare leagă decizia de procesul care deține socketul. Potrivirea owner funcționează pentru traficul generat local în lanțul OUTPUT, așa că un marcaj aplicat acolo poate selecta un tabel separat:

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

Pachetele de la utilizatorul 1001 consultă apoi tabelul 200 și pleacă prin gateway-ul obișnuit, în timp ce tabelul principal trimite în continuare tot restul în tunel. Potrivirea owner se aplică doar pachetelor generate local, adică exact traficul care contează aici, și nu poate clasifica pachetele redirecționate pentru alt host. Verificați cu instrumentele, nu cu intenția: ss -tnp arată adresa locală și procesul proprietar al conexiunilor stabilite, iar ip route get 1.1.1.1 mark 0x1 arată ce tabel selectează marcajul.

Un spațiu de nume de rețea este răspunsul mai solid pentru un program autonom, pentru că fiecare socket creat în el este legat de el prin construcție, așa că procesele auxiliare și conexiunile copil moștenesc comportamentul fără a fi clasificate deloc. Costul este instalații: o pereche veth, o adresă la fiecare capăt și o rută implicită în interiorul spațiului de nume care indică înapoi spre host.

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: destinația încă decide

Windows alege interfața de ieșire după destinație, așa că un program care vrea altă cale trebuie să schimbe ceva ce stiva consultă înainte de acea alegere. ForceBindIP acoperă prima jumătate: pornește un program cu socketurile deja legate de o adresă locală pe care o numiți. Doar asta nu schimbă interfața prin care iese pachetul, pentru că destinația selectează în continuare ruta. Legați o sursă pe un laptop a cărui rută implicită indică spre tunel și pachetul intră totuși în tunel.

Simptomul are o formă lizibilă odată ce îl cunoașteți. Este valabil pentru o adresă LAN la care interfața aleasă ajunge direct și eșuează pentru orice din internet a cărui rută indică spre tunel. De asemenea, pare să funcționeze până când programul dă munca unui auxiliar, pentru că unui auxiliar care își deschide propriul socket nu i s-a spus niciodată despre legare.

Mutați decizia când un singur proces este unitatea greșită

Dacă cerința reală este un dispozitiv și nu un program, puneți-l pe propriul SSID sau VLAN și lăsați routerul să decidă: acea sursă ia calea normală în timp ce alte surse folosesc tunelul. O mașină gateway dedicată este celălalt design onest: ține VPN-ul și primește doar destinațiile pe care i le trimite routerul. Pe un VLAN politica acoperă fiecare flux pe care dispozitivul îl deschide, inclusiv procesele auxiliare care au spart abordarea Windows. Schimbul este sfera: două programe pe acel dispozitiv nu mai pot fi tratate diferit.

Ambele sunt politici de sursă sau de destinație cu o sferă care poate fi spusă într-o singură propoziție. Niciuna nu este pe aplicație, iar un design care se vinde ca fiind pe aplicație eșuează prima dată când programul își deleagă munca unui al doilea proces.