Gaan verkeer regtig deur die VPN? Hoe om dit te verifieer

Twee mislukkings lyk dieselfde vanaf die ikoon in die systeemkassie: verkeer wat in die tonnel ingaan en verkeer wat stilweg daaromheen gaan. Die kliënt meld Connected in albei gevalle, want Connected beteken net dat die tonnelkoppelvlak bestaan en dat die kliënt die roetes geïnstalleer het wat hy wou. Of een pakkie van een toepassing daardie roetes gebruik het, is 'n aparte vraag wat op 'n ander plek in die stapel beantwoord word. Vier metings beslis die meeste daarvan — die roete-opsoek, die eerste hop, 'n opname op die fisiese adapter en 'n waarneming van buite — en die bediener se eie sessie-aansig dek die res.

Begin met die roete wat die pakkie sal neem

Die roetertabel is die besluit, vra dit dus oor een bestemming in plaas daarvan om die hele ding te lees en te raai. Op Linux noem ip route get die koppelvlak en bronadres wat die kern gekies het:

ip route get 203.0.113.10
ip route get 10.20.5.7

Op Windows is Find-NetRoute -RemoteIPAddress 203.0.113.10 nuttiger as route print -4 om dieselfde rede: dit rapporteer die roete wat gewen het, nie elke roete wat bestaan nie. Lees die tabel tog een keer vir sy 0.0.0.0-ry. 'n /1-paar daar beteken 'n voltonnel-kliënt het die verstek herskryf: OpenVPN se redirect-gateway def1 installeer 0.0.0.0/1 en 128.0.0.0/1 deur die tonnel, wat die bestaande 0.0.0.0/0 op langste-voorvoegsel-passing klop sonder om die fisiese verstek te verwyder. Dit is waarom twee verstekke kan saambestaan terwyl alles steeds in die tonnel ingaan.

Twee besonderhede laat die tabel lieg. Eerstens, kyk na die voorvoegsel wat gepas het eerder as die aantal verstekroetes, want 'n koppelvlak-maatstaf of 'n /1-paar besluit die wenner. Tweedens, 'n verbinding wat reeds bestaan behou die pad waarmee dit gevestig is; nadat die tonnel opkom, kan 'n oop sessie die ou roete bly gebruik totdat dit herstel word, en daarom lyk dit of herverbinding 'n roeteprobleem oplos. 'n Lopende kliënt — ps ax | grep openvpn — bewys net dat die proses begin het.

Volg een interne naam en een openbare naam

Roete-opsoek wys bedoeling; die pad wys aflewering. Volg 'n naam wat intern moet wees en 'n naam wat dit nie moet wees nie, terwyl jy gekonnekteer is, en vergelyk die eerste hop:

traceroute intranet.corp.example
traceroute 1.1.1.1

Dieselfde eerste hop vir albei beteken die interne naam het nooit die tonnel binnegegaan nie en die fout lê bo dit, gewoonlik 'n naam wat na 'n openbare adres oplos of 'n roete wat nooit geïnstalleer is nie. Interne verkeer wat deur 10.8.0.1 uitgaan terwyl openbare verkeer deur 192.168.1.1 uitgaan, beteken splitsingstonneling doen presies wat dit gekonfigureer is om te doen. 'n Spoor wat die VPN-gateway bereik en dan net tydsverloop teruggee, is gewoonlik 'n terugpad- of bediener-vuurmuurprobleem, nie 'n ontbrekende aanstuurroete nie.

Gefiltreerde ICMP laat hierdie kontrole lieg: sterretjies op albei spore lyk soos 'n dooie tonnel en is gewoonlik 'n vuurmuur. Probeer 'n TCP-poort waar jy kan — traceroute -T -p 443 op Linux — en onthou die spoor sê niks oor watter resolver geantwoord het nie: 'n naam kan plaaslik oplos en steeds deur die tonnel bereik word.

Maak 'n opname op die fisiese adapter, nie die tonnel nie

Die fisiese skakel is die enigste plek wat wys wat die netwerk werklik kan sien. Met die tonnel op, behoort 'n sessie na die kantoor te verskyn as geënkripteerde vrag wat aan die VPN-bediener geadresseer is, nie as 'n verbinding na 10.20.5.7 nie:

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

Die eerste filter vang naamoplossing wat plaaslik uitgaan, wat die algemeenste lek is en die stilste — die bladsy laai steeds, die resolver het net die navraag gesien. Die tweede vang gewone verkeer na 'n interne adres wat net binne die tonnel behoort te bestaan. Op Windows doen pktmon dieselfde werk sonder 'n drywer: pktmon filter add -p 53, dan pktmon start --capture --pkt-size 128, dan pktmon stop en pktmon format pktmon.etl -o capture.txt. Daardie vlae verskil effens tussen Windows-boude, so kyk pktmon filter add /? voordat jy die sintaks vertrou.

Maak 'n opname van die fisiese koppelvlak om lekke te vind; 'n opname op die tonnel bevat die pakkies wat jy reeds dink daar is, en op 'n bediener bevat dit onleesbare buitenste pakkies wie se bron die gateway is. Grewe-tellers op enige koppelvlak beskryf pakkies, nie programme nie; om verkeer aan 'n proses toe te skryf, het 'n monitor nodig wat sokke aan prosesse koppel.

Vra 'n buitediens, en vra dit dan weer per toepassing

Die enigste kontrole wat die uitgang bewys, is 'n antwoord van buite: 'n diens wat die bronadres terugstuur wat dit gesien het. Hardloop dit uit 'n dop, waar jy die koppelvlak kan kies, en hardloop dit twee keer:

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

Verskillende antwoorde gee jou bewys van albei paaie en 'n manier om 'n spesifieke toepassing te toets: bind dit, of hardloop dit in 'n netwerknaamruimte met een roete, en kyk watter adres die verre kant aanteken. Identiese antwoorde is die interessante mislukking: óf die binding het nie in werking getree nie, óf iets tussen die gasheer en die verre kant herskryf die bronadres voordat dit aankom. Op Windows wil curl --interface die adapteradres hê eerder as sy naam.

'n Blaaier wat die VPN-adres rapporteer, bewys die blaaier. 'n E-poskliënt, 'n pakketbestuurder, 'n rugsteunagent of 'n tweede blaaierprofiel kan elk 'n ander pad neem, veral wanneer 'n proxy-instelling of 'n splitsingstonnelroete een van hulle dek. 'n Adresverandering is nie op sigself bewys van 'n lek nie: 'n lasbalanseerder kan anders antwoord na gelang van die uitgang wat dit gesien het, so vergelyk die aangetekende bronadres, nie die bladsy nie.

Gebruik die bediener-aansig om die eweknie te bevestig

Die bediener beantwoord 'n ander vraag: of 'n eweknie gekonnekteer is, hoeveel dit gedra het en of die sessie herbegin het. 'n Eweknie wat op die bediener op is terwyl die kliënttellers skaars beweeg, beteken die toepassingsverkeer gaan nie in die tonnel in nie, wat die kliënttabel ook al gesê het. 'n Eweknie wat baie data beweeg vir 'n gebruiker wat rapporteer dat niks werk nie, is 'n ander ondersoek.

Twee strikke lê hier. 'n Gemasquerade tonnel laat elke vloei lyk of dit van die gateway kom, so logboeke en per-kliënt-rekenskap val op een adres saam. En 'n kliënt word as 'n plaaslike gasheer behandel, so 'n vraag oor iemand wat lêers deur die VPN kopieer, word beantwoord deur lêerdelingsverkeer by die bediener of deur gasheeroudit op die bediener — om die tonnel dop te hou gee eindpunte en volume, nie lêername nie.

Onderskei 'n ontwerpbesluit van 'n lek

Nie alles buite die tonnel is 'n lek nie. Skakel-plaaslike en uitsaaiverkeer bly ontwerpmatig plaaslik, 'n drukker wat oor multicast gevind word, bly op die LAN aankondig, en DHCP moet plaaslik uitgaan. 'n Toepassing wat aan 'n spesifieke koppelvlak gebind is, gaan doelbewus om die roetertabel heen, en net 'n vuurmuurreël, 'n naamruimte of 'n beleidsroete verander dit.

IPv6 verdien sy eie lyn in die kontrolelys. 'n Tonnel wat net IPv4 dra, laat 'n dubbelstapel-gasheer met 'n tweede bruikbare pad, en 'n dubbelstapel-bestemming sal dit verkies — insluitend DNS, as die resolver oor IPv6 bereikbaar is. Deaktiveer IPv6 op die adapter of bevestig dat die tonnel dit dra voordat jy 'n IPv4-resultaat as volledig beskou.

Wanneer die kontroles verskil, noem die verskil gewoonlik die fout:

'n Orde wat werk: stoor die roetertabel voor en na die koppeling, volg een interne en een openbare naam, maak 'n DNS-opname op die fisiese adapter, eggo die uitgangadres uit die dop vir die spesifieke toepassing, lees dan die bediener vir volume. As die eerste vier saamstem, dra die tonnel wat jy dink dit dra en sit die oorblywende probleem bo dit. As twee van hulle verskil, is die paar wat verskil die fout, nie die ikoon nie.