Gre promet res skozi VPN? Kako to preveriti

Dve napaki sta s sličice v sistemski pladnji videti enaki: promet, ki vstopi v tunel, in promet, ki se mu tiho izogne. Odjemalec v obeh primerih prikaže Connected, ker Connected pomeni le, da vmesnik tunela obstaja in da je odjemalec namestil poti, ki jih je želel. Ali je en paket ene aplikacije uporabil te poti, je ločeno vprašanje, na katero se odgovarja na drugem mestu v skladu. Štiri meritve rešijo večino — iskanje poti, prvi skok, zajem na fizičnem vmesniku in opazovanje od zunaj — pogled seje na strežniku pa pokrije ostalo.

Začnite s potjo, po kateri bo šel paket

Usmerjevalna tabela je odločitev, zato jo vprašajte o enem cilju, namesto da bi jo prebrali v celoti in ugibali. V Linuxu ip route get poimenuje vmesnik in izvorni naslov, ki ju je izbralo jedro:

ip route get 203.0.113.10
ip route get 10.20.5.7

V Windowsu je Find-NetRoute -RemoteIPAddress 203.0.113.10 uporabnejši od route print -4 iz istega razloga: poroča o poti, ki je zmagala, ne o vseh obstoječih poteh. Vseeno preberite tabelo enkrat zaradi njene vrstice 0.0.0.0. Par /1 tam pomeni, da je odjemalec polnega tunela prepisal privzeto pot: možnost redirect-gateway def1 OpenVPN namesti 0.0.0.0/1 in 128.0.0.0/1 skozi tunel, kar premaga obstoječo 0.0.0.0/0 pri najdaljšem ujemanju predpone, ne da bi izbrisalo fizično privzeto pot. Zato lahko dve privzeti poti obstajata hkrati, medtem ko gre vse še vedno v tunel.

Dve podrobnosti naredita tabelo lažnivo. Prvič, glejte predpono, ki se je ujemala, ne števila privzetih poti, ker zmagovalca določi metrika vmesnika ali par /1. Drugič, obstoječa povezava obdrži pot, s katero je bila vzpostavljena; po dvigu tunela lahko odprta seja še naprej uporablja staro pot, dokler ni ponastavljena, in zato se zdi, da ponovna povezava odpravi težavo z usmerjanjem. Delujoč odjemalec — ps ax | grep openvpn — dokazuje le, da se je proces začel.

Sledite enemu notranjemu in enemu javnemu imenu

Iskanje poti pokaže namero; pot pokaže dostavo. Med povezavo sledite imenu, ki mora biti notranje, in imenu, ki ne sme biti, ter primerjajte prvi skok:

traceroute intranet.corp.example
traceroute 1.1.1.1

Enak prvi skok za oba pomeni, da notranje ime nikoli ni vstopilo v tunel in je napaka nad njim, običajno ime, ki se razreši v javni naslov, ali pot, ki ni bila nikoli nameščena. Če notranji promet izhaja skozi 10.8.0.1, javni pa skozi 192.168.1.1, razdeljeni tunel počne točno to, za kar je bil nastavljen. Sled, ki doseže prehod VPN in nato vrne samo časovne omejitve, je običajno težava povratne poti ali požarnega zidu strežnika, ne manjkajoča pot posredovanja.

Filtriran ICMP naredi to preverjanje lažnivo: zvezdice na obeh sledeh so videti kot mrtev tunel in so običajno požarni zid. Preizkusite vrata TCP, kjer lahko — traceroute -T -p 443 v Linuxu — in zapomnite si, da sled ne pove, kateri razreševalnik je odgovoril: ime se lahko razreši lokalno in je še vedno dosegljivo skozi tunel.

Zajemajte na fizičnem vmesniku, ne na tunelu

Fizična povezava je edino mesto, ki pokaže, kaj omrežje v resnici vidi. Ob dvignjenem tunelu bi morala seja v pisarno izgledati kot šifrirana obremenitev, naslovljena na strežnik VPN, ne kot povezava na 10.20.5.7:

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

Prvi filter ujame razreševanje imen, ki izhaja lokalno, in to je najpogostejše in najtišje uhajanje — stran se vseeno naloži, razreševalnik je le videl poizvedbo. Drugi ujame običajen promet na notranji naslov, ki bi moral obstajati samo znotraj tunela. V Windowsu pktmon opravi isto delo brez gonilnika: pktmon filter add -p 53, nato pktmon start --capture --pkt-size 128, nato pktmon stop in pktmon format pktmon.etl -o capture.txt. Te zastavice se med različicami Windowsa nekoliko razlikujejo, zato preverite pktmon filter add /?, preden zaupate skladnji.

Zajemite fizični vmesnik, da najdete uhajanja; zajem na tunelu vsebuje pakete, za katere že verjamete, da so tam, na strežniku pa vsebuje neberljive zunanje pakete, katerih vir je prehod. Števci bajtov na katerem koli vmesniku opisujejo pakete, ne programov; za pripis prometa procesu je potreben monitor, ki preslika vtičnice v procese.

Vprašajte zunanjo storitev in nato vprašajte znova za vsako aplikacijo

Edino preverjanje, ki dokaže izhod, je odgovor od zunaj: storitev, ki vrne videni izvorni naslov. Zaženite jo iz lupine, kjer lahko izberete vmesnik, in zaženite dvakrat:

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

Različni odgovori vam dajo dokaz obeh poti in način za preizkus določene aplikacije: privežite jo ali jo zaženite v imenskem prostoru omrežja z eno potjo in poglejte, kateri naslov zabeleži oddaljeni konec. Enaki odgovori so zanimiva napaka: bodisi privez ni učinkoval bodisi nekaj med gostiteljem in oddaljenim koncem prepiše izvorni naslov, preden prispe. V Windowsu curl --interface zahteva naslov vmesnika, ne njegovega imena.

Brskalnik, ki poroča naslov VPN, dokazuje brskalnik. Poštni odjemalec, upravitelj paketov, agent za varnostne kopije ali drug profil brskalnika lahko vsak ubere drugo pot, še posebej kadar nastavitev proxyja ali pot razdeljenega tunela pokriva enega od njih. Sprememba naslova sama po sebi ni dokaz uhajanja: razporejevalnik obremenitve lahko odgovori drugače glede na videni izhod, zato primerjajte zabeleženi izvorni naslov, ne strani.

Uporabite pogled strežnika, da potrdite partnerja

Strežnik odgovarja na drugo vprašanje: ali je partner povezan, koliko je prenesel in ali se je seja znova zagnala. Partner, ki je na strežniku aktiven, medtem ko se števci odjemalca komaj premikajo, pomeni, da promet aplikacije ne vstopa v tunel, kar koli je rekla tabela odjemalca. Partner, ki premika veliko podatkov za uporabnika, ki poroča, da nič ne deluje, je druga preiskava.

Tu se skrivata dve pasti. Maskiran tunel naredi, da vsak tok izgleda, kot da prihaja s prehoda, zato se dnevniki in obračunavanje po odjemalcih zlijejo na en naslov. In odjemalec se obravnava kot lokalni gostitelj, zato vprašanje, ali kdo kopira datoteke skozi VPN, odgovorita promet skupne rabe datotek na strežniku ali revizija gostitelja na strežniku — opazovanje tunela da končne točke in obseg, ne imen datotek.

Ločite oblikovno odločitev od uhajanja

Ni vse zunaj tunela uhajanje. Promet na povezanem segmentu in razpošiljanje ostajata po zasnovi lokalna, tiskalnik, najden prek multicast, se še naprej oglašuje v LAN, DHCP pa mora izstopiti lokalno. Aplikacija, privezana na določen vmesnik, namenoma obide usmerjevalno tabelo, in to spremeni le pravilo požarnega zidu, imenski prostor ali politična pot.

IPv6 si na kontrolnem seznamu zasluži svojo vrstico. Tunel, ki nosi samo IPv4, gostitelju z dvojno kopico pusti drugo uporabno pot, cilj z dvojno kopico pa jo bo imel raje — tudi DNS, če je razreševalnik dosegljiv prek IPv6. Onemogočite IPv6 na vmesniku ali potrdite, da ga tunel nosi, preden rezultat IPv4 štejete za popoln.

Ko se preverjanja ne ujemajo, neskladje običajno poimenuje napako:

Delujoč vrstni red: shranite usmerjevalno tabelo pred povezavo in po njej, sledite enemu notranjemu in enemu javnemu imenu, zajemite DNS na fizičnem vmesniku, vrnite izhodni naslov iz lupine za določeno aplikacijo in nato preberite strežnik glede obsega. Če se prvi štirje ujemajo, tunel nosi to, kar mislite, in preostala težava je nad njim. Če se dva ne ujemata, je neujemajoči par napaka, ne ikona.