VPN bezeroa konektatzen da, nabigatzaileak funtzionatzen du, eta benetan axola zaizun komando bakarrak zure etxeko konexiotik ateratzen jarraitzen du. Edo alderantziz gertatzen da: tunelak bide lehenetsia hartzen du eta tokiko fitxategi zerbitzaria mahaigainetik desagertzen da. Hori eraikuntza agente batekin bizi izan nuen, artefaktuen barne ispilu batera iritsi behar zuena, gainerako ostalaria bulegoko LANean zegoen bitartean, eta bezeroak zehazki bi aukera eskaintzen zituen: trafiko guztia edo ezer ez. Eskaera bi norantzatan bera da, programa hau eta ez makina osoa, eta bezero gehienek ez dute horretarako kontrol-laukirik, bide-taulagailuak inoiz ez duelako jakin zer den programa bat.

Zergatik ezin duen bide-taulagailuak zure programa ikusi

Prozesu batek pakete bat bidaltzen duenean, pilak helmugako helbidea bilatzen du bide-taulagailuan. Exekutagarriaren izenak ez eta atakak ez dute bilaketa horretan sartzen. Domeinu-izenek huts egiten dute arrazoi beragatik: tunelak trafikoa helbide batera eramaten du, eta izen bat helbide bihurtu denerako, bideratzea da nukleoak oraindik duen palanka bakarra. Horregatik «VPN soilik gune honetarako» proxy bat esan nahi du azkenean, eta «VPN soilik programa honetarako» mekanismo multzo txiki bateko bat.

MechanismWhat selectsCoversOn tunnel drop
Socket bindsource addressa client you controlconnections fail
UID rule (Linux)owning userevery process of one accountconnections fail
Firewall profile (Windows)adapter profileone programfails closed
Network namespacenamespace membershipeverything started insideconnections fail
SOCKS hopapp proxy settingone app or one browser profileconnections fail

Hauetako bat ere ez da prozesuko bidea. Bakoitzak erabakia programa, erabiltzailea edo aplikazioaren beraren konfigurazioa ikus dezakeen geruza batera eramaten du.

Helmuga bakar bat bidea da oraindik, ez programaren araua. macOSen ohiko errezeta «Bidali trafiko guztia VPN bidez» desmarkatzea eta ostalari-bide bat gehitzea da: sudo route add -host internal-tuner.example -interface ppp0, berriro kentzen dena sudo route delete -host internal-tuner.example -interface ppp0 erabiliz. Irakurri lehenengo interfazearen izena ifconfig irteeran, ppp0 adibide bat besterik ez delako. Komodinek ez dute funtzionatzen ostalari-bide batean, beraz hainbat izenekin hitz egiten duen zerbitzu batek izen bakoitzeko sarrera bat behar du, eta arauak makinako prozesu guztiak hartzen ditu, zure buruan zenuena ez ezik.

Lotu socketa tunelaren helbidera

Bezeroa kontrolatzen duzunean, lotura da hautatzailerik merkeena. Tunelaren tokiko helbidera lotutako socket batek interfaze horretatik irteten du, betiere helmugarako bidea han badago, eta makinako gainerako guztiak bere bide arrunta mantentzen du. Xehetasuna da loturak iturburu-helbidea aukeratzen duela, bide-taulagailuak irteera aukeratzen jarraitzen duen bitartean. Loturak bakarrik ez du tunelera biderik ez duen trafikoa mugitzen, eta hori da «lotu nuen eta oraindik alde okerretik ateratzen da» salaketen atzean dagoen akatsa.

import socket
s = socket.socket()
s.bind(("10.8.0.2", 0))
s.connect(("build.internal.example", 443))

Maila altuagoko tresnek ideia bera erakusten dute: curl --interface 10.8.0.2, PHPko CURLOPT_INTERFACE eta Pythonen HTTP bezeroetan source_address argumentua. Helbideak tunelari pertenezu behar dio, eta hemen akats tipografiko bat ohiko konexio-errore gisa huts egiten du, ez bideratze-kexa gisa. Helbidearen ordez gailu-izen batera lotzea Linuxen pribilegioa da eta ez da Windows edo macOSra pasatzen, horregatik script eramangarriek helbidea pasatzen dute.

Linux: egin bat jabearekin, ez programaren izenarekin

Nukleoak socket baten jabea den erabiltzailea bat ditzake, beraz kontu dedikatu bat hautatzaile bihurtzen da. Jarri tunela bere bide-taulagailuan eta bidali bertara kontu horren trafikoa soilik:

ip rule add uidrange 1001-1001 lookup 100
ip route add default dev tun0 table 100

Honek soilik funtzionatzen du tunela jada bide lehenetsia ez bada. Hasi bezeroa --route-nopull aukerarekin, edo iragazi bultzatutako birbideratzea --pull-filter ignore "redirect-gateway" erabiliz OpenVPN 2.4 eta berriagoetan, eta gero gehitu taulako sarrera zeuk. Bestela bi lehenetsiak existitzen dira eta lehentasun txikiagokoak irabazten du. Horren bertsio nahita egina bide lehenetsia tunelaren atebidera zuzentzea da, edo deskonexio-script batetik egitea: trafikoa internetetik kanpo mantentzen du tunela erortzen denean, baina hori etengailu bat da, ez hautatzaile bat, eta norbaitek kendu arte geratzen da.

Bertsio indartsuagoa sare-namespace bat da. Sortu ezazu, exekutatu bezeroa barruan eta hasi aplikazioa ip netns exec erabiliz. Namespace-tik kanpo ezerk ez du tunelaren interfazea ikusten, beraz aplikazioak ezin du ustekabean ostalariaren bidera itzuli. Kostua erreala da: namespaceak veth pare bat behar du sare fisikora iristeko eta bere resolver fitxategia, muntaketa-namespaceak ez baitu ostalariaren ebazpen-ezarpenak partekatzen.

Hutsegite modu bik azaltzen dituzte isurketen gehienak. Izenen ebazpena ostalariaren resolverrean gertatzen da oraindik, beraz kontsulta tunelatik kanpora ateratzen da TCP konexioa barrura doan arren. Eta IPv6k bere ip -6 rule behar du, v4 arau batek ez baitu estaltzen.

Windows eta macOS: mugatu suebakia edo utzi proxy bat

Windowsen ere ez dago aplikazioko bide-hautatzailerik, baina bere suebaki-arauak profil batera mugatu daitezke, eta VPN egokitzailea «publiko» gisa sailka daiteke etxeko LANak «pribatu» jarraitzen duen bitartean. Sortu irteerako blokeo-arauak programarako «pribatu» eta «domeinu» profiletan, utzi «publiko» irekita, eta aplikazioak tunelaren bidez soilik iritsiko da sarera. Ezarri lehenengo konexioaren sare-kategoria, eta gero egiaztatu arauak suebakiaren monitorizazio-panelean bat egin duela. Blokeoa da, ez bidea: itxita huts egiten du tunela erortzen denean, eta ezin du suebakia alde batera uzten duen aplikazio bat gelditu.

macOSek logika bera jarraitzen du beste tresna batzuekin. SSH bidez iristen den SOCKS entzulea da aukerarik inbaditzailerik txikiena, ssh -D 1080 user@host erabiliz tokiko ataka bat sortzen baita eta hura erabiltzeko konfiguratutako aplikazioek soilik hartzen dute bide hori. pf arau batek programa bat blokea dezake erabiltzaile edo taldearen arabera, baina oraindik ezin du tunela soilik programa horretarako aukeratu. Tunnelblickek ezin du domeinuaren arabera filtratu, bideek helbideekin lan egiten dutelako; OpenConnect erabiltzaileek vpn-slice tresnara jotzen dute zerbitzariak aurrizki-zerrenda zabalegia bultzatzen duenean.

Bi alternatibak plataformako tresnek uzten dutena estaltzen dute. Proxy-a domeinuaren arabera aldatzen duten nabigatzaile-luzapenak dira «gune hau soilik» erantzun praktikoa, izenak oraindik existitzen diren aplikazio-geruzan jarduten dutelako; nabigatzaile bat estaltzen dute eta beste ezer ez. Irtenbide zakarra saltzailearen bezeroa makina birtualean exekutatzea da, ostalariak bere bidea mantentzen duen bitartean gonbidatuak bide-aldaketaren jabe izan dadin, bi sare-pila mantentzearen kostuarekin.

SOCKS jauzi bat lotura-aukerarik ez duten tresnentzat

Aplikazio gehienak HTTP edo SOCKS proxira zuzendu daitezke interfazeen berri ezer ez dakiten arren. SSH bezero batek bat eskaintzen du zerbitzariaren aldean aldaketarik gabe:

ssh -N -D 127.0.0.1:9999 [email protected]

Ataka hori erabiltzeko konfiguratuta dagoen guztia bastioian irteten da, mahaigaineko gainerakoak bere konexio arrunta mantentzen duen bitartean. Tunelaren helbidera lotutako 3proxy instantzia lokal batek gauza bera egiten du ataka baterako SSH gabe, eta stunnel tresnak TLSz bildutako ataka bakarra estaltzen du. Mugak praktikoak dira: proxyak erabiltzen dakiten protokoloak soilik garraiatzen ditu, UDPk SOCKS5 UDP elkartzea behar du, bezero askoren «SOCKS5» ezarpenak aktibatzen ez duena, eta DNS proxyak ebatzi behar du (socks5h curlen), bestela izena tokiko resolverrera ihes egiten du.

Mantendu entzulea loopback-en, beste makina batek behar ez badu behintzat.

Egiaztatu bidea harrapaketa batekin, ez egoera-mezu batekin

Aplikazioaren egoera-leihoek ezarpena deskribatzen dute, ez paketea. Harrapatu bi interfazetan eta alderatu:

tcpdump -i any -n port 443
ss -tnp | grep 443

Konexioa interfaze fisikoan agertzen bada tunelaren sarrera parekiderik gabe, hautatzailea ez dago indarrean, bezeroak esaten duena esanda ere. Egiaztatu IPv6 eta resolverra bereizita, eta egiaztatu bigarren bide bat dagoen, hala nola prozesu lagungarri bat edo oinordetzan jasotako sistema-proxy bat.

Orduan aukeratu eskakizunari dagokion muga: proxy bat nahikoa da gune batentzat, UID arau bat nahikoa da kontu batentzat, suebaki-profila nahikoa da konexioak itxita huts egin behar duenean, eta namespacea da tunela kanpoko guztietatik ezkutatzen duen aukera bakarra.

Erlazionatutako artikuluak