Tunay bang dumadaan ang trapiko sa VPN? Paano ito i-verify
Ang paghahanap ng ruta, unang hop, isang capture sa pisikal na adapter at isang pagsusuri ng address mula sa labas ay sumasagot sa magkakaibang bahagi ng tanong.
Dalawang failure ang magkamukha mula sa icon sa system tray: trapikong pumapasok sa tunnel at trapikong tahimik na lumilihis dito. Ipinapakita ng client ang Connected sa dalawang kaso, dahil ang Connected ay nangangahulugan lamang na umiiral ang tunnel interface at nailagay ng client ang mga rutang gusto nito. Kung ginamit ng isang packet ng isang application ang mga rutang iyon ay hiwalay na tanong, na sinasagot sa ibang bahagi ng stack. Apat na sukatan ang nagtatakda ng halos lahat — ang paghahanap ng ruta, ang unang hop, isang capture sa pisikal na adapter at isang obserbasyon mula sa labas — at ang view ng session sa server ay sumasaklaw sa natitira.
Magsimula sa rutang tatahakin ng packet
Ang routing table ang desisyon, kaya tanungin ito tungkol sa isang destinasyon sa halip na basahin lahat at manghula. Sa Linux, binabanggit ng ip route get ang interface at source address na pinili ng kernel:
ip route get 203.0.113.10
ip route get 10.20.5.7Sa Windows, mas kapaki-pakinabang ang Find-NetRoute -RemoteIPAddress 203.0.113.10 kaysa route print -4 sa parehong dahilan: iniuulat nito ang rutang nanalo, hindi lahat ng rutang umiiral. Basahin pa rin ang table minsan para sa row na 0.0.0.0. Ang pares na /1 doon ay nangangahulugang isinulat muli ng full-tunnel client ang default na ruta: ini-install ng opsyong redirect-gateway def1 ng OpenVPN ang 0.0.0.0/1 at 128.0.0.0/1 sa pamamagitan ng tunnel, na tumatalo sa umiiral na 0.0.0.0/0 sa pinakamahabang prefix match nang hindi binubura ang pisikal na default na ruta. Kaya't dalawang default na ruta ang maaaring magkasabay habang ang lahat ay pumapasok pa rin sa tunnel.
Dalawang detalye ang nagpapasinungaling sa table. Una, tingnan ang prefix na tumugma at hindi ang bilang ng default na ruta, dahil ang interface metric o isang pares na /1 ang nagtatakda ng panalo. Pangalawa, ang koneksyong umiiral na ay nagpapanatili ng landas kung paano ito naitatag; pagkatapos umangat ang tunnel, ang bukas na session ay maaaring magpatuloy sa paggamit ng lumang ruta hanggang ma-reset ito, at iyon ang dahilan kung bakit mukhang inaayos ng muling pagkonekta ang problema sa routing. Ang tumatakbong client — ps ax | grep openvpn — ay nagpapatunay lamang na nagsimula ang proseso.
Subaybayan ang isang panloob at isang pampublikong pangalan
Ipinapakita ng paghahanap ng ruta ang intensyon; ipinapakita ng landas ang paghahatid. Habang konektado, subaybayan ang pangalang dapat panloob at pangalang hindi dapat, at ihambing ang unang hop:
traceroute intranet.corp.example
traceroute 1.1.1.1Ang parehong unang hop para sa dalawa ay nangangahulugang hindi kailanman pumasok sa tunnel ang panloob na pangalan at ang sira ay nasa itaas nito, karaniwang pangalang nire-resolve sa pampublikong address o rutang hindi kailanman na-install. Kung ang panloob na trapiko ay lumalabas sa 10.8.0.1 habang ang pampubliko ay lumalabas sa 192.168.1.1, ginagawa ng split tunneling ang eksaktong itinakda para dito. Ang trace na umaabot sa VPN gateway at pagkatapos ay nagbabalik lamang ng mga timeout ay karaniwang problema sa return path o firewall ng server, hindi nawawalang forward route.
Ang na-filter na ICMP ay nagpapasinungaling sa pagsusuring ito: ang mga bituin sa dalawang trace ay mukhang patay na tunnel at karaniwang firewall iyon. Subukan ang TCP port kung saan kaya — traceroute -T -p 443 sa Linux — at tandaan na hindi sinasabi ng trace kung aling resolver ang sumagot: ang isang pangalan ay maaaring mag-resolve nang lokal at maabot pa rin sa pamamagitan ng tunnel.
Kunin ang capture sa pisikal na adapter, hindi sa tunnel
Ang pisikal na link ang tanging lugar na nagpapakita kung ano ang talagang nakikita ng network. Kapag nakataas ang tunnel, ang session papunta sa opisina ay dapat lumitaw bilang naka-encrypt na payload na naka-address sa VPN server, hindi bilang koneksyon sa 10.20.5.7:
sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5Ang unang filter ay humuhuli sa name resolution na lumalabas nang lokal, na siyang pinakakaraniwan at pinakatahimik na leak — naglo-load pa rin ang pahina, nakita lamang ng resolver ang query. Ang pangalawa ay humuhuli sa ordinaryong trapiko patungo sa panloob na address na dapat umiiral lamang sa loob ng tunnel. Sa Windows, ginagawa ng pktmon ang parehong trabaho nang walang driver: pktmon filter add -p 53, pagkatapos pktmon start --capture --pkt-size 128, pagkatapos pktmon stop at pktmon format pktmon.etl -o capture.txt. Ang mga flag na ito ay bahagyang nagkakaiba sa pagitan ng mga build ng Windows, kaya tingnan ang pktmon filter add /? bago magtiwala sa syntax.
Kunin ang capture sa pisikal na interface upang makahanap ng mga leak; ang capture sa tunnel ay naglalaman ng mga packet na inaakala mo nang naroon, at sa server naglalaman ito ng mga hindi mababasang panlabas na packet na ang pinagmulan ay ang gateway. Ang mga byte counter sa anumang interface ay naglalarawan ng mga packet, hindi ng mga program; upang maiugnay ang trapiko sa isang proseso kailangan ng monitor na nagmamapa ng mga socket sa mga proseso.
Tanungin ang panlabas na serbisyo, pagkatapos tanungin muli bawat application
Ang tanging pagsusuring nagpapatunay ng labasan ay isang sagot mula sa labas: serbisyong ibinabalik ang source address na nakita nito. Patakbuhin ito mula sa shell, kung saan mapipili mo ang interface, at patakbuhin nang dalawang beses:
sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ipAng magkaibang sagot ay nagbibigay sa iyo ng patunay ng dalawang landas at paraan upang subukan ang isang partikular na application: i-bind ito, o patakbuhin sa network namespace na may isang ruta, at tingnan kung aling address ang itinatala ng malayong dulo. Ang magkaparehong sagot ang kawili-wiling sira: alinman ay walang epekto ang bind, o may bagay sa pagitan ng host at malayong dulo na nagsusulat muli ng source address bago ito dumating. Sa Windows, hinihingi ng curl --interface ang address ng adapter at hindi ang pangalan nito.
Ang browser na nag-uulat ng address ng VPN ay nagpapatunay sa browser. Ang mail client, package manager, backup agent o ikalawang profile ng browser ay maaaring magkakaibang landas ang bawat isa, lalo na kapag may proxy setting o ruta ng split tunnel na sumasaklaw sa isa sa kanila. Ang pagbabago ng address ay hindi patunay ng leak sa sarili nito: ang load balancer ay maaaring tumugon nang iba ayon sa labasan na nakita nito, kaya ihambing ang naitalang source address, hindi ang pahina.
Gamitin ang view ng server upang kumpirmahin ang peer
Ang server ay sumasagot sa ibang tanong: kung konektado ang peer, gaano karami ang nadala at kung nag-restart ang session. Ang peer na aktibo sa server samantalang halos hindi gumagalaw ang counter ng client ay nangangahulugang hindi pumapasok sa tunnel ang trapiko ng application, anuman ang sabi ng table ng client. Ang peer na naglilipat ng maraming data para sa user na nag-uulat na walang gumagana ay ibang imbestigasyon.
May dalawang bitag dito. Ang masked tunnel ay nagpapakita sa bawat flow na parang galing sa gateway, kaya ang mga log at accounting bawat client ay bumabagsak sa isang address. At ang client ay itinuturing na lokal na host, kaya ang tanong kung may kumokopya ng file sa pamamagitan ng VPN ay sinasagot ng file-sharing traffic sa server o ng host audit sa server — ang pagmamasid sa tunnel ay nagbibigay ng mga endpoint at dami, hindi ng mga pangalan ng file.
Ibahin ang desisyon sa disenyo sa isang leak
Hindi lahat ng nasa labas ng tunnel ay leak. Ang link-local at broadcast na trapiko ay nananatiling lokal ayon sa disenyo, ang printer na natagpuan sa multicast ay patuloy na nag-aanunsyo sa LAN, at ang DHCP ay dapat lumabas nang lokal. Ang application na nakatali sa partikular na interface ay sadyang lumalampas sa routing table, at tanging firewall rule, namespace o policy route ang nagbabago nito.
Ang IPv6 ay may karapatan sa sariling linya sa checklist. Ang tunnel na nagdadala lamang ng IPv4 ay nag-iiwan sa dual-stack host ng ikalawang magagamit na landas, at pipiliin ito ng dual-stack na destinasyon — kabilang ang DNS, kung maaabot ang resolver sa pamamagitan ng IPv6. I-disable ang IPv6 sa adapter o kumpirmahin na dinadala ito ng tunnel bago ituring na kumpleto ang resulta ng IPv4.
Kapag hindi nagtutugma ang mga pagsusuri, ang hindi pagtutugma ang karaniwang nagbabanggit ng sira:
| 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 |
Isang pagkakasunod-sunod na gumagana: i-save ang routing table bago at pagkatapos kumonekta, subaybayan ang isang panloob at isang pampublikong pangalan, kunin ang capture ng DNS sa pisikal na adapter, ibalik ang address ng labasan mula sa shell para sa partikular na application, pagkatapos basahin ang server para sa dami. Kung magkatugma ang unang apat, dinadala ng tunnel ang iniisip mo at ang natitirang problema ay nasa itaas nito. Kung dalawa sa kanila ay hindi magkatugma, ang pares na hindi nagtutugma ang sira, hindi ang icon.