Giet it ferkear echt troch de VPN? Hoe't jo dat kontrolearje

Twa flaters sjogge der itselde út fan it ikoan yn 'e systeemlade: ferkear dat de tunnel yngiet en ferkear dat der stil omhinne giet. De klant toant Connected yn beide gefallen, want Connected betsjut allinnich dat de tunnelinterface bestiet en dat de klant de rûtes ynstallearre hat dy't er woe. Oft ien pakket fan ien applikaasje dy rûtes brûkt hat, is in aparte fraach, dy't op in oar plak yn 'e stapel beäntwurde wurdt. Fjouwer mjittingen lossen it measte op — it rûtesykjen, de earste hop, in opname op 'e fysike adapter en in waarnimming fan bûten — en de sesje-oersjoch op de tsjinner dekt de rest.

Begjin mei de rûte dy't it pakket nimme sil

De rûtingtabel is de beslissing, freegje him dus oer ien bestimming ynstee fan 'e hiele tabel te lêzen en te rieden. Op Linux neamt ip route get de interface en it boarneadres dat de kearn keas:

ip route get 203.0.113.10
ip route get 10.20.5.7

Op Windows is Find-NetRoute -RemoteIPAddress 203.0.113.10 handiger as route print -4 om deselde reden: it meldt de rûte dy't wûn, net alle rûtes dy't besteane. Lês de tabel dochs ien kear foar syn 0.0.0.0-ry. In /1-pear dêr betsjut dat in foltunnelklant de standertrûte wer oanskreau: de opsje redirect-gateway def1 fan OpenVPN ynstallearret 0.0.0.0/1 en 128.0.0.0/1 troch de tunnel, wat de besteande 0.0.0.0/0 ferslacht by de langste-prefiks-oerienkomst sûnder de fysike standertrûte te wiskjen. Dêrom kinne twa standertrûtes njonkeninoar bestean wylst alles dochs de tunnel yngiet.

Twa details meitsje de tabel leugenich. Earst, sjoch nei it prefiks dat oerienkaam en net nei it oantal standertrûtes, want in interfacemetryk of in /1-pear beslist de winner. Twadde, in ferbining dy't al bestiet hâldt it paad wêrmei't er oprjochte is; nei't de tunnel omheech giet, kin in iepen sesje de âlde rûte bliuwe brûken oant er weromset wurde, en dêrom liket opnij ferbinen in rûteprobleem op te lossen. In draaiende klant — ps ax | grep openvpn — bewiist allinnich dat it proses begûn is.

Folgje ien ynterne en ien iepenbiere namme

Rûtesykjen toant bedoeling; it paad toant levering. Folgje in namme dy't yntern wêze moat en in namme dy't dat net wêze moat, wylst jo ferbûn binne, en fergelykje de earste hop:

traceroute intranet.corp.example
traceroute 1.1.1.1

Deselde earste hop foar beide betsjut dat de ynterne namme nea de tunnel yngien is en de fout derboppe leit, meastentiids in namme dy't nei in iepenbier adres oplost of in rûte dy't nea ynstallearre waard. As yntern ferkear troch 10.8.0.1 nei bûten giet wylst iepenbier ferkear troch 192.168.1.1 giet, docht splitstunnel krekt wat it konfigurearre is om te dwaan. In traject dat by de VPN-poarte komt en dan allinnich tiidferstriken werom jout, is meastentiids in werompaad- of tsjinnerfirewallprobleem, net in ûntbrekkende trochstjoerrûte.

Filtere ICMP makket dizze kontrôle leugenich: stjerren op beide trajecten lykje op in deade tunnel en binne meastentiids in firewall. Test in TCP-poarte wêr't jo kinne — traceroute -T -p 443 op Linux — en betink dat it traject neat seit oer hokker resolver antwurde: in namme kin lokaal oplosse en dochs troch de tunnel berikber wêze.

Meitsje in opname op 'e fysike adapter, net op 'e tunnel

De fysike skeakel is it iennichste plak dat sjen lit wat it netwurk wier sjocht. Mei de tunnel omheech moat in sesje nei kantoar ferskine as fersifere lading rjochte op 'e VPN-tsjinner, net as in ferbining nei 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

It earste filter fangt namme-oplossing dy't lokaal nei bûten giet, wat de meast foarkommende en stilste lekkage is — de side laden dochs, de resolver hat allinnich de fraach sjoen. It twadde fangt gewoan ferkear nei in yntern adres dat allinnich yn 'e tunnel bestean moat. Op Windows docht pktmon itselde wurk sûnder stjoerder: pktmon filter add -p 53, dan pktmon start --capture --pkt-size 128, dan pktmon stop en pktmon format pktmon.etl -o capture.txt. Dy flaggen ferskille in bytsje tusken Windows-buorden, dus kontrolearje pktmon filter add /? foardat jo de syntaks fertrouwe.

Meitsje in opname fan 'e fysike interface om lekkages te finen; in opname op 'e tunnel befettet de pakketten dêr't jo al fan tinke dat se der binne, en op in tsjinner befettet er ûnlêsbere bûtenste pakketten wêrfan't de boarne de poarte is. Bytestellers op hokker interface dan ek beskriuwe pakketten, net programma's; om ferkear oan in proses ta te skriuwen is in monitor nedich dy't sockets oan prosessen keppelt.

Freegje in eksterne tsjinst, en freegje it dan nochris per applikaasje

De iennichste kontrôle dy't de útgong bewiist is in antwurd fan bûten: in tsjinst dy't it boarneadres weromstjoert dat er seach. Rin it út in shell, wêr't jo de interface kieze kinne, en rin it twa kear:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Ferskillende antwurden jouwe jo bewiis fan beide paden en in manier om in spesifike applikaasje te testen: byn it, of rin it yn in netwurknammeromte mei ien rûte, en sjoch hokker adres de fiere kant fêstleit. Identike antwurden binne de nijsgjirrige flater: of de binding hie gjin effekt, of eat tusken de host en de fiere kant skriuwt it boarneadres oer foardat it oankomt. Op Windows wol curl --interface it adres fan 'e adapter ynstee fan syn namme.

In browser dy't it VPN-adres rapportearret bewiist de browser. In e-postklant, in pakketbehearder, in reservekopy-agint of in twadde browserprofyl kinne elk in oar paad nimme, benammen as in proxy-ynstelling of in splitstunnelrûte ien fan harren dekt. In adresferoaring is op himsels gjin bewiis fan in lekkage: in loadbalancer kin oars antwurdzje ôfhinklik fan 'e útgong dy't er seach, fergelykje dus it fêstleine boarneadres, net de side.

Brûk it tsjinner-oersjoch om de peer te befêstigjen

De tsjinner beäntwurdet in oare fraach: oft in peer ferbûn is, hoefolle er droegen hat en oft de sesje opnij begûn is. In peer dy't op 'e tsjinner aktyf is wylst de tellers fan 'e klant amper bewege, betsjut dat it applikaasjeferkear de tunnel net yngiet, wat de klanttabel ek sei. In peer dy't in soad gegevens ferpleatst foar in brûker dy't rapportearret dat neat wurket, is in oar ûndersyk.

Hjir lizze twa fallen. In maskere tunnel lit elke stream lykje as kaam er fan 'e poarte, sadat logs en ôfrekkenjen per klant op ien adres gearfalle. En in klant wurdt behannele as in lokale host, dus de fraach oft immen bestannen troch de VPN kopiearret wurdt beäntwurde troch bestandielferkear op 'e tsjinner of troch hostaudit op 'e tsjinner — it besjen fan 'e tunnel jout einpunten en folume, net bestandsnammen.

Underskied in ûntwerpbeslissing fan in lekkage

Net alles bûten de tunnel is in lekkage. Link-local- en broadcast-ferkear bliuwt fan ûntwerp lokaal, in printer dy't fia multicast fûn wurdt bliuwt him oankundigjen op 'e LAN, en DHCP moat lokaal nei bûten. In applikaasje bûn oan in spesifike interface giet mei opsetsin om 'e rûtingtabel hinne, en allinnich in firewallregel, in nammeromte of in beliedsrûte feroaret dat.

IPv6 fertsjinnet syn eigen rigel op 'e kontrolelist. In tunnel dy't allinnich IPv4 draacht lit in dual-stack-host mei in twadde brûkber paad, en in dual-stack-bestimming sil dat foarkar jaan — ek DNS, as de resolver fia IPv6 berikber is. Sette IPv6 út op 'e adapter of befêstigje dat de tunnel it draacht foardat jo in IPv4-resultaat as folslein beskôgje.

As de kontrôles net oerienkomme, neamt it ferskil meastentiids de flater:

In oarder dy't wurket: bewarje de rûtingtabel foar en nei it ferbinen, folgje ien ynterne en ien iepenbiere namme, meitsje in DNS-opname op 'e fysike adapter, stjoer it útgongsadres fan 'e shell werom foar de spesifike applikaasje, lês dan de tsjinner foar folume. As de earste fjouwer oerienkomme, draacht de tunnel wat jo tinke en sit it oerbleaune probleem derboppe. As twa fan har ferskille, is it pear dat ferskilt de flater, net it ikoan.