Neniu ŝaltilo por ekskludi ĉi tiun aplikaĵon: donu al la procezo sian propran fonton

Unu programo uzu la ordinaran konekton dum ĉio alia restas en la tunelo, kaj la kliento ne havas ŝaltilon por tio. Nek ekzistas kaŝita menuo por trovi. Vojo elektiĝas el kampoj ene de la pakaĵo, kaj la pakaĵo portas adresojn kaj pordojn, ne la identecon de la procezo, kiu ĝin kreis, do ekskludo devas esti esprimita en unu el tiuj kampoj. Sekvu pakaĵon unufoje kaj la disponeblaj ebloj ĉesas esti misteraj.

Kial la kliento ne povas proponi ĝin

Cela enkursigado komparas la celan adreson kun prefiksoj kaj konservas la plej longan kongruon. En tiu momento ĉiu pakaĵo aspektas sama, kion ajn produktis ĝin. Fonta politika enkursigado larĝigas la komparon al la fonta adreso, kaj tio estas la hoko, kiun uzas ĉiu praktika solvo: ŝanĝu la fonton, kaj alia tabelo fariĝas elektebla.

Pordoj ne helpas. Ekskludo laŭ pordo devus esti taksita antaŭ la celloko, kaj la pordo ludas neniun rolon en tiu decido. Ĉio reklamata kiel pordbaza ekskludo fakte ekskludas laŭ iu alia kampo kaj priskribas tion malprecize.

Vera enkursigado laŭ aplikaĵo ekzistas tie, kie la platformo aldonis maŝinaron por ĝi, ekzemple filtrilvokojn en Windows aŭ la bindadon de la VPN-servo en Android. Labortabla OpenVPN-instalaĵo portas nenion el tio, kaj neniu agorda flago elpensas ĝin.

Linux: marku la procezon, poste enkursigu la markon

La plej pura aliro ligas la decidon al la procezo, kiu posedas la soketon. La kongruo owner funkcias por loke generita trafiko en la ĉeno OUTPUT, do marko aplikita tie povas elekti apartan tabelon:

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

Pakaĵoj de uzanto 1001 tiam konsultas tabelon 200 kaj eliras tra la ordinara enirejo, dum la ĉefa tabelo ankoraŭ sendas ĉion alian en la tunelon. La kongruo owner validas nur por loke generitaj pakaĵoj, kio estas ĝuste la trafiko, kiu gravas ĉi tie, kaj ĝi ne povas klasifiki pakaĵojn plusenditajn por alia gastiganto. Kontrolu per la iloj, ne per la intenco: ss -tnp montras la lokan adreson kaj la posedantan procezon de establitaj konektoj, kaj ip route get 1.1.1.1 mark 0x1 montras, kiun tabelon la marko elektas.

La pli solida respondo por memstara programo estas reta nomspaco, ĉar ĉiu soketo kreita ene de ĝi estas ligita al ĝi per konstruo, do helpaj procezoj kaj filaj konektoj heredas la konduton tute sen klasifiko. La kosto estas plumbado: veth-paro, adreso ĉe ĉiu fino, kaj defaŭlta vojo ene de la nomspaco, kiu montras reen al la gastiganto.

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: la celo ankoraŭ decidas

Windows elektas la eliran interfacon laŭ la celo, do programo, kiu volas alian vojon, devas ŝanĝi ion, kion la stako konsultas antaŭ tiu elekto. ForceBindIP kovras la unuan duonon: ĝi lanĉas programon kun siaj soketoj jam ligitaj al loka adreso, kiun vi nomas. Tio sola ne ŝanĝas, per kiu interfaco la pakaĵo eliras, ĉar la celo ankoraŭ elektas la vojon. Ligu fonton sur tekkomputilo, kies defaŭlta vojo montras en la tunelon, kaj la pakaĵo tamen eniras la tunelon.

La simptomo havas legeblan formon, post kiam vi konas ĝin. Ĝi validas por LAN-adreso, kiun la elektita interfaco atingas rekte, kaj malsukcesas por ĉio en la interreto, kies vojo montras al la tunelo. Ĝi ankaŭ ŝajnas funkcii ĝis la programo transdonas laboron al helpanto, ĉar helpanto, kiu malfermas sian propran soketon, neniam estis informita pri la ligo.

Movu la decidon, kiam unu procezo estas la malĝusta unuo

Se la reala postulo estas aparato, ne programo, metu ĝin sur sian propran SSID aŭ VLAN kaj lasu la enkursigilon decidi: tiu fonto prenas la normalan vojon, dum aliaj fontoj uzas la tunelon. Dediĉita enireja maŝino estas la alia honesta dezajno: ĝi tenas la VPN kaj ricevas nur la celojn, kiujn la enkursigilo sendas al ĝi. En VLAN la politiko kovras ĉiun fluon, kiun la aparato malfermas, inkluzive la helpajn procezojn, kiuj rompis la Windows-aliron. La interŝanĝo estas la amplekso: du programoj sur tiu aparato jam ne povas esti traktataj malsame.

Ambaŭ estas politikoj pri fonto aŭ celo kun amplekso, kiun vi povas esprimi en unu frazo. Neniu estas laŭ aplikaĵo, kaj dezajno, kiu sin prezentas kiel laŭ aplikaĵo, malsukcesas la unuan fojon, kiam la programo delegas sian laboron al dua procezo.