Vai trafiks tiešām iet caur VPN? Kā to pārbaudīt

Divas kļūmes no sistēmas teknes ikonas izskatās vienādi: trafiks, kas nonāk tunelī, un trafiks, kas to klusi apiet. Klientā abos gadījumos redzams Connected, jo Connected nozīmē tikai to, ka tuneļa saskarne pastāv un klients ir instalējis vēlamos maršrutus. Vai viens vienas programmas pakete izmantoja šos maršrutus, ir atsevišķs jautājums, uz kuru atbild citā steka vietā. Četri mērījumi atrisina lielāko daļu — maršruta meklēšana, pirmais lēciens, ieraksts fiziskajā adapterī un novērojums no ārpuses — un servera sesijas skats nosedz pārējo.

Sāciet ar maršrutu, pa kuru ies pakete

Maršrutēšanas tabula ir lēmums, tāpēc jautājiet tai par vienu galamērķi, nevis lasiet visu un miniet. Linux sistēmā ip route get nosauc saskarni un avota adresi, ko izvēlējās kodols:

ip route get 203.0.113.10
ip route get 10.20.5.7

Windows sistēmā Find-NetRoute -RemoteIPAddress 203.0.113.10 ir noderīgāks par route print -4 tā paša iemesla dēļ: tas ziņo par uzvarējušo maršrutu, nevis par visiem esošajiem. Tomēr izlasiet tabulu vienreiz tās 0.0.0.0 rindas dēļ. Pāris /1 tur nozīmē, ka pilna tuneļa klients ir pārrakstījis noklusējuma maršrutu: OpenVPN opcija redirect-gateway def1 instalē 0.0.0.0/1 un 128.0.0.0/1 caur tuneli, un tas garākās prefiksa atbilstības dēļ pārspēj esošo 0.0.0.0/0, neizdzēšot fizisko noklusējuma maršrutu. Tāpēc divi noklusējuma maršruti var pastāvēt līdzās, kamēr viss joprojām nonāk tunelī.

Divi sīkumi padara tabulu melīgu. Pirmkārt, skatieties uz atbilstošo prefiksu, nevis uz noklusējuma maršrutu skaitu, jo uzvarētāju nosaka saskarnes metrika vai pāris /1. Otrkārt, jau esošs savienojums saglabā ceļu, ar kuru tas tika izveidots; pēc tuneļa pacelšanas atvērta sesija var turpināt izmantot veco maršrutu, līdz tā tiek atiestatīta, un tāpēc izskatās, ka atkārtota pievienošanās salabo maršrutēšanas problēmu. Strādājošs klients — ps ax | grep openvpn — pierāda tikai to, ka process ir sācies.

Izsekojiet vienu iekšēju un vienu publisku nosaukumu

Maršruta meklēšana parāda nodomu; ceļš parāda piegādi. Savienotā stāvoklī izsekojiet nosaukumu, kam jābūt iekšējam, un nosaukumu, kam nevajadzētu būt, un salīdziniet pirmo lēcienu:

traceroute intranet.corp.example
traceroute 1.1.1.1

Viens un tas pats pirmais lēciens abiem nozīmē, ka iekšējais nosaukums nekad nav nonācis tunelī un kļūme ir virs tā, parasti nosaukums, kas atrisinās uz publisku adresi, vai maršruts, kas nekad netika instalēts. Ja iekšējais trafiks iziet caur 10.8.0.1, bet publiskais caur 192.168.1.1, sadalītais tunelis dara tieši to, kam tas tika konfigurēts. Pēda, kas sasniedz VPN vārteju un pēc tam atgriež tikai taimautus, parasti ir atgriešanās ceļa vai servera ugunsmūra problēma, nevis trūkstošs pāradresācijas maršruts.

Filtrēts ICMP padara šo pārbaudi melīgu: zvaigznītes abās pēdās izskatās kā miris tunelis, un parasti tas ir ugunsmūris. Pārbaudiet TCP portu, kur varat — traceroute -T -p 443 Linux sistēmā — un atcerieties, ka pēda nepasaka, kurš atrisinātājs atbildēja: nosaukums var atrisināties lokāli un tomēr būt sasniedzams caur tuneli.

Ierakstiet fiziskajā adapterī, nevis tunelī

Fiziskā saite ir vienīgā vieta, kas parāda, ko tīkls patiešām redz. Ar paceltu tuneli sesijai uz biroju vajadzētu izskatīties kā šifrētai kravai, kas adresēta VPN serverim, nevis kā savienojumam ar 10.20.5.7:

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

Pirmais filtrs noķer nosaukumu atrisināšanu, kas iziet lokāli, un tas ir visbiežākā un klusākā noplūde — lapa joprojām ielādējas, atrisinātājs tikai redzēja vaicājumu. Otrais noķer parastu trafiku uz iekšēju adresi, kam vajadzētu pastāvēt tikai tuneļa iekšienē. Windows sistēmā pktmon dara to pašu bez draivera: pktmon filter add -p 53, tad pktmon start --capture --pkt-size 128, tad pktmon stop un pktmon format pktmon.etl -o capture.txt. Šie karodziņi nedaudz atšķiras starp Windows versijām, tāpēc pārbaudiet pktmon filter add /? pirms uzticēties sintaksei.

Ierakstiet fizisko saskarni, lai atrastu noplūdes; ieraksts tunelī satur paketes, par kurām jūs jau ticat, ka tās tur ir, bet serverī tas satur nelasāmas ārējās paketes, kuru avots ir vārteja. Baitu skaitītāji jebkurā saskarnē apraksta paketes, nevis programmas; lai attiecinātu trafiku uz procesu, vajadzīgs monitors, kas kartē ligzdas uz procesiem.

Pajautājiet ārējam servisam, pēc tam pajautājiet vēlreiz katrai programmai

Vienīgā pārbaude, kas pierāda izeju, ir atbilde no ārpuses: serviss, kas atgriež redzēto avota adresi. Palaidiet to no čaulas, kur varat izvēlēties saskarni, un palaidiet divreiz:

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

Dažādas atbildes dod abu ceļu pierādījumu un veidu, kā pārbaudīt konkrētu programmu: piesaistiet to vai palaidiet to tīkla nosaukumtelpā ar vienu maršrutu un paskatieties, kādu adresi reģistrē tālais gals. Identiskas atbildes ir interesantā kļūme: vai nu piesaiste neiedarbojās, vai kaut kas starp resursdatoru un tālo galu pārraksta avota adresi, pirms tā nonāk. Windows sistēmā curl --interface grib adaptera adresi, nevis tā nosaukumu.

Pārlūks, kas ziņo VPN adresi, pierāda pārlūku. Pasta klients, pakotņu pārvaldnieks, dublēšanas aģents vai otrs pārlūka profils katrs var iet citu ceļu, jo īpaši tad, kad starpniekservera iestatījums vai sadalītā tuneļa maršruts nosedz kādu no tiem. Adreses maiņa pati par sevi nav noplūdes pierādījums: slodzes balansētājs var atbildēt citādi atkarībā no redzētās izejas, tāpēc salīdziniet reģistrēto avota adresi, nevis lapu.

Izmantojiet servera skatu, lai apstiprinātu partneri

Serveris atbild uz citu jautājumu: vai partneris ir savienots, cik daudz tas ir pārraidījis un vai sesija tika restartēta. Partneris, kas serverī ir aktīvs, kamēr klienta skaitītāji gandrīz nekustas, nozīmē, ka programmas trafiks neietilpst tunelī, lai ko teiktu klienta tabula. Savukārt partneris, kas pārvieto daudz datu lietotājam, kurš ziņo, ka nekas nestrādā, ir cita izmeklēšana.

Šeit slēpjas divas lamatas. Maskēts tunelis liek katram plūsmam izskatīties tā, it kā tas nāktu no vārtejas, tāpēc žurnāli un uzskaite pa klientiem saplūst vienā adresē. Un klients tiek uzskatīts par vietēju resursdatoru, tāpēc uz jautājumu, vai kāds kopē failus pa VPN, atbild failu koplietošanas trafiks serverī vai resursdatora audits serverī — tuneļa novērošana dod galapunktus un apjomu, nevis failu nosaukumus.

Atšķiriet dizaina lēmumu no noplūdes

Ne viss ārpus tuneļa ir noplūde. Saistes lokālais un apraides trafiks dizaina dēļ paliek lokāls, caur multicast atrastais printeris turpina pieteikties LAN tīklā, un DHCP ir jāiziet lokāli. Programma, kas piesaistīta konkrētai saskarnei, apzināti apiet maršrutēšanas tabulu, un to maina tikai ugunsmūra noteikums, nosaukumtelpa vai politikas maršruts.

IPv6 ir pelnījis savu rindu kontrolsarakstā. Tunelis, kas pārvadā tikai IPv4, atstāj divkāršā steka resursdatoram otru izmantojamu ceļu, un divkāršā steka galamērķis to dos priekšroku — arī DNS, ja atrisinātājs ir sasniedzams pa IPv6. Atspējojiet IPv6 adapterī vai apstipriniet, ka tunelis to pārvadā, pirms uzskatāt IPv4 rezultātu par pilnīgu.

Kad pārbaudes nesakrīt, nesakritība parasti nosauc kļūmi:

Strādājoša secība: saglabājiet maršrutēšanas tabulu pirms pievienošanās un pēc tam, izsekojiet vienu iekšēju un vienu publisku nosaukumu, ierakstiet DNS fiziskajā adapterī, atgrieziet izejas adresi no čaulas konkrētajai programmai, pēc tam lasiet serveri apjoma dēļ. Ja pirmie četri sakrīt, tunelis pārvadā to, ko jūs domājat, un atlikušā problēma ir virs tā. Ja divi no tiem nesakrīt, nesakrītošais pāris ir kļūme, nevis ikona.