VPN bidez doa benetan trafikoa? Nola egiaztatu
Ibilbidearen bilaketa, lehen jauzia, adaptagailu fisikoan egindako harrapaketa eta kanpoko helbide-egiaztapenak galderaren zati desberdinei erantzuten diete.
Hutsegite bik berdinak dirudite erretiluaren ikonoan: tunelera sartzen den trafikoak eta isil-isilik haren inguruan doan trafikoak. Bezeroak Connected erakusten du bi kasuetan, Connected-ek tunelaren interfazea badagoela eta bezeroak nahi zituen ibilbideak instalatu dituela baino ez baitu esan nahi. Aplikazio bateko pakete batek ibilbide horiek erabili zituen ala ez galdera bereizia da, eta pilaren beste puntu batean erantzuten da. Lau neurketak gauzaren zatirik handiena konpontzen dute — ibilbidearen bilaketa, lehen jauzia, adaptagailu fisikoan egindako harrapaketa eta kanpoko behaketa — eta zerbitzariaren saio-ikuspegiak gainerakoa estaltzen du.
Hasi paketeak hartuko duen ibilbidearekin
Bideratze-taula da erabakia, beraz galdetu helburu bati buruz, taula osoa irakurri eta asmatu beharrean. Linuxen, ip route get nukleoak aukeratutako interfazea eta iturburu-helbidea adierazten ditu:
ip route get 203.0.113.10
ip route get 10.20.5.7Windowsen, Find-NetRoute -RemoteIPAddress 203.0.113.10 erabilgarriagoa da route print -4 baino arrazoi beragatik: irabazi zuen ibilbidea jakinarazten du, existitzen diren ibilbide guztiak ez. Irakurri taula behin 0.0.0.0 errenkadaren bila. Han /1 bikote bat egoteak esan nahi du tunel osoaren bezero batek lehenetsitako ibilbidea berridatzi zuela: OpenVPNren redirect-gateway def1 aukerak 0.0.0.0/1 eta 128.0.0.0/1 instalatzen ditu tuneletik, eta horrek lehendik dagoen 0.0.0.0/0 gainditzen du aurrizkirik luzeenaren bat-etortzean, lehenetsitako ibilbide fisikoa ezabatuta gabe. Horregatik bi ibilbide lehenetsik batera egon daitezke, dena tunelean sartzen jarraitzen duen bitartean.
Bi xehetasunek taula gezurtatzen dute. Lehenik, begiratu bat etorri zen aurrizkia, ez ibilbide lehenetsien kopurua, interfazearen metrikak edo /1 bikoteak erabakitzen baitu irabazlea. Bigarrenik, jada badagoen konexioak ezarri zen bidea gordetzen du; tunela altxatu ondoren, irekitako saioak ibilbide zaharra erabiltzen jarrai dezake berrezarri arte, eta horregatik berriz konektatzeak bideratze-arazo bat konpontzen duela ematen du. Lanean dabilen bezeroak — ps ax | grep openvpn — prozesua hasi zela besterik ez du frogatzen.
Jarrai ezazu barneko izen bat eta kanpoko izen bat
Ibilbidearen bilaketak asmoa erakusten du; bideak entregatzea. Jarrai ezazu barnekoa izan behar duen izen bat eta izan behar ez duen beste bat, konektatuta zauden bitartean, eta alderatu lehen jauzia:
traceroute intranet.corp.example
traceroute 1.1.1.1Bientzat lehen jauzi bera izateak esan nahi du barneko izena ez zela inoiz tunelera sartu eta hutsegitea horren gainetik dagoela, normalean helbide publikora ebazten den izen bat edo inoiz instalatu ez zen ibilbide bat. Barneko trafikoa 10.8.0.1 bidez irteten eta publikoa 192.168.1.1 bidez irteten bada, tunel zatituak konfiguratu zen zehazki egiten ari da. VPN atebidera iritsi eta gero denbora-mugak besterik itzultzen ez dituen arrasto bat itzultze-bidearen edo zerbitzariaren suebakiaren arazoa izan ohi da, ez falta den aurrera-bideratze ibilbide bat.
ICMP iragaziak egiaztapen hau gezurtatzen du: bi arrastoetan izarrek tunel hila dirudite eta normalean suebaki bat da. Probatu TCP ataka bat non ahal duzun — traceroute -T -p 443 Linuxen — eta gogoratu arrastoak ez duela esaten zein ebazlekilek erantzun zuen: izen bat lokalean ebatzi eta tuneletik irisgarri izan daiteke oraindik.
Harrapatu adaptagailu fisikoan, ez tunelean
Esteka fisikoa da sareak benetan zer ikusten duen erakusten duen leku bakarra. Tunela altxatuta, bulegorako saio bat VPN zerbitzariari zuzendutako karga zifratu gisa agertu beharko litzateke, ez 10.20.5.7 helbiderako konexio gisa:
sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5Lehen iragazkiak lokalean irteten den izen-ebazpena harrapatzen du, eta hori da ohikoena eta isileneko isuria — orria oraindik kargatzen da, ebazlekileak kontsulta besterik ez zuen ikusi. Bigarrenak tunelean bakarrik egon beharko lukeen barne-helbide baterako trafiko arrunta harrapatzen du. Windowsen, pktmon-k lan bera egiten du kontrolatzailerik gabe: pktmon filter add -p 53, gero pktmon start --capture --pkt-size 128, gero pktmon stop eta pktmon format pktmon.etl -o capture.txt. Bandera horiek pixka bat aldatzen dira Windows bertsioen artean, beraz egiaztatu pktmon filter add /? sintaxiaz fidatu aurretik.
Harrapatu interfaze fisikoa isuriak aurkitzeko; tunelean egindako harrapaketak han daudela uste duzun paketeak baino ez ditu, eta zerbitzari batean kanpoko pakete irakurtezinak ditu, iturria atebidea dutela. Edozein interfazetako byte-kontagailuek paketeak deskribatzen dituzte, ez programak; trafikoa prozesu bati egotzi behar zaionean, socketak prozesuekin lotzen dituen monitore bat behar da.
Galdetu kanpoko zerbitzu bati, eta gero galdetu berriro aplikazio bakoitzeko
Irteera frogatzen duen egiaztapen bakarra kanpotik datorren erantzuna da: ikusi zuen iturburu-helbidea islatzen duen zerbitzua. Exekutatu shell batetik, han aukeratu baitaiteke interfazea, eta exekutatu birritan:
sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ipErantzun desberdinek bi bideen froga ematen dizute eta aplikazio jakin bat probatzeko modua: lotu ezazu, edo exekutatu bide bakarreko sare-izen-espazio batean, eta ikusi zein helbide erregistratzen duen urruneko muturrak. Erantzun berdinak dira hutsegite interesgarria: edo loturak ez zuen eraginik izan, edo zerbait host eta urruneko muturraren artean iturburu-helbidea iritsi aurretik berridazten du. Windowsen, curl --interface-k adaptagailuaren helbidea nahi du, ez haren izena.
VPN helbidea jakinarazten duen nabigatzaileak nabigatzailea frogatzen du. Posta-bezero, pakete-kudeatzaile, babeskopia-eragile edo bigarren nabigatzaile-profil bakoitzak bide desberdina har dezake, batez ere proxy-ezarpen edo tunel zatituaren ibilbide batek horietako bat estaltzen duenean. Helbide-aldaketa ez da isuri baten froga berez: karga-orekatzaileak beste erantzun bat eman dezake ikusi zuen irteeraren arabera, beraz alderatu erregistratutako iturburu-helbidea, ez orria.
Erabili zerbitzariaren ikuspegia parekidea baieztatzeko
Zerbitzariak beste galdera bati erantzuten dio: parekidea konektatuta dagoen, zenbat eraman duen eta saioa berrabiarazi den. Zerbitzarian parekidea aktibo dagoen bitartean bezeroaren kontagailuek ia mugitzen ez badira, aplikazioaren trafikoa ez da tunelera sartzen ari, bezeroaren taulak zer esan zuen ere. Erabiltzaile bati ezer ere ez zaiola funtzionatzen dioenean haren parekideak datu asko mugitzen baditu, beste ikerketa bat da.
Bi tranpa daude hemen. Tunel maskaratuak fluxu bakoitza atebidetik datorrela ematen du, eta, beraz, erregistroak eta bezero bakoitzeko kontabilitatea helbide bakarrera erortzen dira. Eta bezeroa host lokal gisa tratatzen da, beraz, norbaitek VPN bidez fitxategiak kopiatzen ari den ala ez galdetzeari zerbitzariko fitxategi-partekatze trafikoak edo zerbitzariko host-ikuskaritzak erantzuten dio — tunelari so egiteak muturrak eta bolumena ematen ditu, ez fitxategi-izenak.
Bereizi diseinu-erabakia isuritik
Tuneletik kanpo dagoen guztia ez da isuri bat. Esteka lokaleko eta difusiozko trafikoak lokal geratzen da diseinuz, multicast bidez aurkitutako inprimagailuak LANean iragartzen jarraitzen du, eta DHCP-k lokalean irten behar du. Interfaze jakin batera lotutako aplikazio batek bideratze-taula nahita saihesten du, eta suebaki-arau batek, izen-espazio batek edo politika-ibilbide batek soilik aldatzen du hori.
IPv6-k bere lerroa merezi du zerrendan. IPv4 soilik daraman tunel batek pila bikoitzeko host bat bigarren bide erabilgarri batekin uzten du, eta pila bikoitzeko helmuga batek hura lehenetsiko du — DNS barne, ebazlekilea IPv6 bidez irisgarria bada. Desgaitu IPv6 adaptagailuan edo egiaztatu tunelak daramala IPv4 emaitza osoa dela ezarri aurretik.
Egiaztapenak bat ez datozenean, desadostasunak hutsa izendatzen du normalean:
| What you see | What it means | Next step |
|---|---|---|
| The route picks tun0 but the capture shows cleartext to 10.20.5.7 | Something bypassed the table: a bound app, a policy route or a session older than the tunnel | Reset the flow, check the app bind, check the ip rule list |
| The route picks eth0 for an internal name | The name resolves to a public address, or the route was never installed | Compare the resolved address with the routes the server pushes |
| The capture shows DNS to the LAN resolver | Resolver leak: data is tunneled, lookups are not | Point the resolver inside, or push it from the server |
| All four checks agree and one app still fails | Path selection is fine; suspect MTU, a per-app proxy or the far end | Test the same destination from a known-good client |
Funtzionatzen duen ordena: gorde bideratze-taula konektatu aurretik eta ondoren, jarrai ezazu barneko izen bat eta kanpoko bat, harrapatu DNSa adaptagailu fisikoan, islatu irteerako helbidea shell-etik aplikazio zehatzarentzat, eta gero irakurri zerbitzaria bolumenaren bila. Lehen laurak bat etortzen badira, tunelak zu uste duzuna darama eta gainerako arazoa haren gainetik dago. Horietako bik bat ez badute egiten, desadostasun duen bikotea da hutsa, ez ikonoa.