Kas liiklus läheb tõesti VPN-ist läbi? Kuidas seda kontrollida

Kaks riket näevad süsteemisalve ikoonilt ühesugused välja: liiklus, mis läheb tunnelisse, ja liiklus, mis läheb sellest vaikselt mööda. Klient näitab mõlemal juhul Connected, sest Connected tähendab ainult seda, et tunneli liides on olemas ja klient paigaldas marsruudid, mida tahtis. Kas ühe rakenduse üks pakett neid marsruute kasutas, on eraldi küsimus, millele vastatakse virnas mujal. Neli mõõtmist lahendavad suurema osa sellest — marsruudiotsing, esimene hüpe, püüdmine füüsilisel adapteril ja vaatlus väljastpoolt — ning serveri enda sessioonivaade katab ülejäänu.

Alustage marsruudist, mille pakett valib

Marsruutimistabel on otsus, seega küsige sellelt ühe sihtkoha kohta, mitte ärge lugege kogu tabelit ja oletage. Linuxis nimetab ip route get liidese ja lähteaadressi, mille tuum valis:

ip route get 203.0.113.10
ip route get 10.20.5.7

Windowsis on Find-NetRoute -RemoteIPAddress 203.0.113.10 samal põhjusel kasulikum kui route print -4: see teatab marsruudist, mis võitis, mitte kõigist olemasolevatest marsruutidest. Lugege tabelit siiski korra selle 0.0.0.0 rea pärast. Sealne /1 paar tähendab, et täistunneli klient kirjutas vaikemarsruudi ümber: OpenVPN-i valik redirect-gateway def1 paigaldab tunnelisse 0.0.0.0/1 ja 128.0.0.0/1, mis võidab olemasoleva 0.0.0.0/0 pikima prefiksi vaste järgi ilma füüsilist vaikemarsruuti kustutamata. Seetõttu saavad kaks vaikemarsruuti kõrvuti eksisteerida, samal ajal kui kõik läheb ikka tunnelisse.

Kaks detaili teevad tabeli valelikuks. Esiteks vaadake sobivat prefiksit, mitte vaikemarsruutide arvu, sest võitja otsustab liidese mõõdik või /1 paar. Teiseks jätab juba olemasolev ühendus endale tee, millega see loodi; pärast tunneli tõusmist võib avatud sessioon kasutada vana marsruuti seni, kuni see lähtestatakse, ja seetõttu näib uuesti ühendamine marsruutimisprobleemi parandavat. Töötav klient — ps ax | grep openvpn — tõestab ainult seda, et protsess käivitus.

Jälgige ühte sisemist ja ühte avalikku nime

Marsruudiotsing näitab kavatsust; tee näitab kohaletoimetamist. Jälgige ühendatud olekus nime, mis peab olema sisemine, ja nime, mis ei tohi olla, ning võrrelge esimest hüpet:

traceroute intranet.corp.example
traceroute 1.1.1.1

Sama esimene hüpe mõlema jaoks tähendab, et sisemine nimi ei sisenenud kunagi tunnelisse ja viga on sellest kõrgemal, tavaliselt nimi, mis laheneb avalikuks aadressiks, või marsruut, mida kunagi ei paigaldatud. Kui sisemine liiklus väljub 10.8.0.1 kaudu, samal ajal kui avalik väljub 192.168.1.1 kaudu, teeb jagatud tunnel täpselt seda, milleks see seadistati. Jälg, mis jõuab VPN-i lüüsini ja naaseb seejärel ainult ajalõppudega, on tavaliselt tagasitee või serveri tulemüüri probleem, mitte puuduv edastusmarsruut.

Filtreeritud ICMP teeb selle kontrolli valelikuks: tärnid mõlemal jäljel näevad välja nagu surnud tunnel ja tavaliselt on see tulemüür. Proovige TCP-porti, kus saate — traceroute -T -p 443 Linuxis — ja pidage meeles, et jälg ei ütle, milline resolver vastas: nimi võib lahenduda kohapeal ja olla siiski tunneli kaudu kättesaadav.

Püüdke füüsilisel adapteril, mitte tunnelis

Füüsiline lüli on ainus koht, mis näitab, mida võrk tegelikult näeb. Tunneli tõustes peaks kontorisse suunduv sessioon ilmuma krüptitud kandevõimena, mis on adresseeritud VPN-i serverile, mitte ühendusena 10.20.5.7-ga:

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

Esimene filter püüab kohapealt väljuva nimelahenduse, mis on kõige levinum ja vaikseim leke — leht laeb ikka, resolver nägi lihtsalt päringut. Teine püüab harilikku liiklust sisemise aadressi poole, mis peaks eksisteerima ainult tunneli sees. Windowsis teeb pktmon sama töö ilma draiverita: pktmon filter add -p 53, siis pktmon start --capture --pkt-size 128, siis pktmon stop ja pktmon format pktmon.etl -o capture.txt. Need lipud erinevad Windowsi versioonide vahel veidi, seega kontrollige pktmon filter add /? enne, kui süntaksit usaldate.

Püüdke füüsilist liidest, et leida lekkeid; tunnelis tehtud püüdmine sisaldab pakette, mille olemasolus te juba usute, ja serveris sisaldab see loetamatuid väliseid pakette, mille allikas on lüüs. Baidilugejad mis tahes liidesel kirjeldavad pakette, mitte programme; liikluse protsessile omistamiseks on vaja monitori, mis seob soklid protsessidega.

Küsige väliselt teenuselt ja seejärel küsige uuesti iga rakenduse kohta

Ainus kontroll, mis tõestab väljumist, on vastus väljastpoolt: teenus, mis kordab nähtud lähteaadressi. Käivitage see kestast, kus saate liidese valida, ja käivitage kaks korda:

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

Erinevad vastused annavad tõestuse mõlema tee kohta ja viisi konkreetse rakenduse testimiseks: siduge see või käivitage see võrgu nimeruumis ühe marsruudiga ja vaadake, millise aadressi kaugem ots salvestab. Identsed vastused on huvitav rike: kas sidumine ei mõjunud, või kirjutab miski hosti ja kaugema otsa vahel lähteaadressi enne kohalejõudmist ümber. Windowsis tahab curl --interface adapteri aadressi, mitte selle nime.

VPN-i aadressi teatav brauser tõestab brauseri. Meilikklient, paketihaldur, varundusagent või teine brauseriprofiil võivad igaüks minna erinevat teed, eriti kui puhverserveri seade või jagatud tunneli marsruut katab ühe neist. Aadressi muutumine ei ole iseenesest lekke tõestus: koormusjaotur võib vastata erinevalt sõltuvalt väljundist, mida ta nägi, seega võrrelge salvestatud lähteaadressi, mitte lehte.

Kasutage serveri vaadet, et peer kinnitada

Server vastab teisele küsimusele: kas peer on ühendatud, kui palju see on edastanud ja kas sessioon taaskäivitus. Peer, mis on serveris aktiivne, samal ajal kui kliendi lugejad vaevalt liiguvad, tähendab, et rakenduse liiklus ei sisene tunnelisse, ükskõik mida kliendi tabel ütles. Peer, mis liigutab palju andmeid kasutaja jaoks, kes teatab, et miski ei tööta, on teine uurimine.

Siin varitseb kaks lõksu. Maskeeritud tunnel paneb iga voolu näima lüüsist tulevat, mistõttu logid ja kliendipõhine arvestus koonduvad ühele aadressile. Ja klienti koheldakse kohaliku hostina, seega küsimusele, kas keegi kopeerib faile VPN-i kaudu, vastatakse serveris failijagamise liiklusega või serveris hosti auditeerimisega — tunneli jälgimine annab lõpp-punktid ja mahu, mitte failinimesid.

Eristage disainiotsust lekest

Kõik väljaspool tunnelit ei ole leke. Lingikohalik ja ringhäälingu liiklus jääb disaini järgi kohalikuks, multicastiga leitud printer jätkab LAN-is teavitamist ja DHCP peab väljuma kohapeal. Konkreetse liidesega seotud rakendus möödub marsruutimistabelist meelega ja seda muudab ainult tulemüürireegel, nimeruum või poliitikamarsruut.

IPv6 väärib kontrollnimekirjas omaette rida. Tunnel, mis kannab ainult IPv4, jätab kahe virna hostile teise kasutatava tee ja kahe virna sihtkoht eelistab seda — sealhulgas DNS-i, kui resolver on IPv6 kaudu kättesaadav. Keelake adapteril IPv6 või kinnitage, et tunnel seda kannab, enne kui loete IPv4 tulemuse täielikuks.

Kui kontrollid on vastuolus, nimetab vastuolu tavaliselt vea:

Toimiv järjekord: salvestage marsruutimistabel enne ja pärast ühendamist, jälgige ühte sisemist ja ühte avalikku nime, püüdke DNS füüsilisel adapteril, kordake väljumisaadress kestast konkreetse rakenduse jaoks ja lugege seejärel serverit mahu osas. Kui esimesed neli nõustuvad, kannab tunnel seda, mida te arvate, ja ülejäänud probleem on sellest kõrgemal. Kui kaks neist on vastuolus, on vastuoluline paar viga, mitte ikoon.