Ar srautas tikrai eina per VPN? Kaip tai patikrinti

Dvi gedimų rūšys atrodo vienodai iš dėklo piktogramos: srautas, kuris patenka į tunelį, ir srautas, kuris tyliai jį apeina. Klientas abiem atvejais rodo Connected, nes Connected reiškia tik tai, kad tunelio sąsaja egzistuoja ir klientas įdiegė norimus maršrutus. Ar vienas vienos programos paketas naudojo tuos maršrutus, yra atskiras klausimas, į kurį atsakoma kitoje krūvos vietoje. Keturi matavimai išsprendžia didžiąją dalį — maršruto paieška, pirmasis šuolis, įrašymas fiziniame adapteryje ir stebėjimas iš išorės — o serverio sesijos vaizdas padengia likusią dalį.

Pradėkite nuo maršruto, kuriuo eis paketas

Maršrutizavimo lentelė yra sprendimas, todėl klauskite jos apie vieną paskirties tašką, o ne skaitykite visą ir spėliokite. Linux sistemoje ip route get nurodo sąsają ir šaltinio adresą, kuriuos pasirinko branduolys:

ip route get 203.0.113.10
ip route get 10.20.5.7

Windows sistemoje Find-NetRoute -RemoteIPAddress 203.0.113.10 naudingesnis už route print -4 dėl tos pačios priežasties: jis praneša apie laimėjusį maršrutą, o ne apie visus egzistuojančius. Vis dėlto perskaitykite lentelę kartą dėl jos 0.0.0.0 eilutės. Pora /1 ten reiškia, kad viso tunelio klientas perrašė numatytąjį maršrutą: OpenVPN parinktis redirect-gateway def1 įdiegia 0.0.0.0/1 ir 128.0.0.0/1 per tunelį, ir tai ilgiausio priešdėlio atitikimu nugali esamą 0.0.0.0/0, neištrindama fizinio numatytojo maršruto. Todėl du numatytieji maršrutai gali egzistuoti kartu, o viskas vis tiek patenka į tunelį.

Dvi detalės daro lentelę melagingą. Pirma, žiūrėkite į atitikusį priešdėlį, o ne į numatytųjų maršrutų skaičių, nes nugalėtoją lemia sąsajos metrika arba pora /1. Antra, jau egzistuojantis ryšys išlaiko kelią, kuriuo buvo užmegztas; pakėlus tunelį atvira sesija gali toliau naudoti seną maršrutą, kol ji bus atstatyta, ir todėl atrodo, kad prisijungimas iš naujo ištaiso maršrutizavimo problemą. Veikiantis klientas — ps ax | grep openvpn — įrodo tik tai, kad procesas prasidėjo.

Sekite vieną vidinį ir vieną viešą vardą

Maršruto paieška rodo ketinimą; kelias rodo pristatymą. Būdami prisijungę sekite vardą, kuris turi būti vidinis, ir vardą, kuris neturi būti, ir palyginkite pirmąjį šuolį:

traceroute intranet.corp.example
traceroute 1.1.1.1

Tas pats pirmasis šuolis abiem reiškia, kad vidinis vardas niekada nepateko į tunelį, o gedimas yra aukščiau, dažniausiai vardas, kuris sprendžiamas į viešą adresą, arba maršrutas, kuris niekada nebuvo įdiegtas. Jei vidinis srautas išeina per 10.8.0.1, o viešas - per 192.168.1.1, tai padalintas tunelis daro būtent tai, kam buvo sukonfigūruotas. Trasė, kuri pasiekia VPN šliuzą ir tada grąžina tik laiko limitus, dažniausiai yra grįžimo kelio arba serverio ugniasienės problema, o ne trūkstamas perdavimo maršrutas.

Filtruotas ICMP daro šį patikrinimą melagingą: žvaigždutės abiejose trasose atrodo kaip miręs tunelis ir dažniausiai tai ugniasienė. Išbandykite TCP prievadą ten, kur galite — traceroute -T -p 443 Linux sistemoje — ir atminkite, kad trasė nieko nesako apie tai, kuris resolveris atsakė: vardas gali būti išspręstas vietoje ir vis tiek pasiekiamas per tunelį.

Įrašykite fiziniame adapteryje, o ne tunelyje

Fizinė jungtis yra vienintelė vieta, kuri parodo, ką tinklas iš tikrųjų mato. Pakėlus tunelį, sesija į biurą turėtų atrodyti kaip užšifruota naudinga apkrova, adresuota VPN serveriui, o ne kaip ryšys su 10.20.5.7:

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

Pirmasis filtras pagauna vardų sprendimą, kuris išeina vietoje, ir tai yra dažniausia bei tyliausia nutekėjimas — puslapis vis tiek įkeliamas, resolveris tik pamatė užklausą. Antrasis pagauna paprastą srautą į vidinį adresą, kuris turėtų egzistuoti tik tunelio viduje. Windows sistemoje pktmon atlieka tą patį darbą be tvarkyklės: pktmon filter add -p 53, tada pktmon start --capture --pkt-size 128, tada pktmon stop ir pktmon format pktmon.etl -o capture.txt. Šios vėliavėlės šiek tiek skiriasi tarp Windows versijų, todėl patikrinkite pktmon filter add /? prieš pasitikėdami sintakse.

Įrašykite fizinę sąsają, kad rastumėte nutekėjimus; įrašas tunelyje turi paketus, kurie, jūsų manymu, jau yra ten, o serveryje jis turi neperskaitomus išorinius paketus, kurių šaltinis yra šliuzas. Baitų skaitikliai bet kurioje sąsajoje apibūdina paketus, o ne programas; norint priskirti srautą procesui reikia monitoriaus, kuris susieja lizdus su procesais.

Paklauskite išorinės paslaugos, tada paklauskite dar kartą kiekvienai programai

Vienintelis patikrinimas, kuris įrodo išėjimą, yra atsakymas iš išorės: paslauga, kuri grąžina matytą šaltinio adresą. Paleiskite ją iš apvalkalo, kur galite pasirinkti sąsają, ir paleiskite du kartus:

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

Skirtingi atsakymai duoda abiejų kelių įrodymą ir būdą išbandyti konkrečią programą: prisiriškite ją arba paleiskite tinklo vardų erdvėje su vienu maršrutu ir pažiūrėkite, kokį adresą užregistruoja tolimas galas. Identiški atsakymai yra įdomus gedimas: arba prisirišimas neveikė, arba kažkas tarp mazgo ir tolimo galo perrašo šaltinio adresą prieš jam atvykstant. Windows sistemoje curl --interface nori adapterio adreso, o ne jo vardo.

Naršyklė, kuri praneša VPN adresą, įrodo naršyklę. Pašto klientas, paketų tvarkyklė, atsarginių kopijų agentas arba antra naršyklės paskyra gali kiekvienas eiti skirtingu keliu, ypač kai tarpinio serverio nustatymas arba padalinto tunelio maršrutas uždengia vieną iš jų. Adreso pasikeitimas pats savaime nėra nutekėjimo įrodymas: apkrovos balansuotojas gali atsakyti kitaip, priklausomai nuo matyto išėjimo, todėl lyginkite užregistruotą šaltinio adresą, o ne puslapį.

Naudokite serverio vaizdą partneriui patvirtinti

Serveris atsako į kitą klausimą: ar partneris prisijungęs, kiek jis perdavė ir ar sesija buvo paleista iš naujo. Partneris, kuris serveryje aktyvus, o kliento skaitikliai beveik nejuda, reiškia, kad programos srautas nepatenka į tunelį, kad ir ką sakė kliento lentelė. O partneris, kuris perduoda daug duomenų naudotojui, teigiančiam, kad niekas neveikia, yra kitas tyrimas.

Čia slypi du spąstai. Maskuotas tunelis leidžia kiekvienam srautui atrodyti taip, lyg jis ateitų iš šliuzo, todėl žurnalai ir apskaita pagal klientą sueina į vieną adresą. O klientas traktuojamas kaip vietinis mazgas, todėl klausimą, ar kas nors kopijuoja failus per VPN, atsako failų bendrinimo srautas serveryje arba mazgo auditas serveryje — tunelio stebėjimas duoda galinius taškus ir apimtį, o ne failų pavadinimus.

Atskirkite dizaino sprendimą nuo nutekėjimo

Ne viskas, kas yra už tunelio ribų, yra nutekėjimas. Vietinės jungties ir transliacijos srautas dizaino sprendimu lieka vietinis, per multicast rastas spausdintuvas toliau skelbiasi LAN tinkle, o DHCP privalo išeiti vietoje. Programą, prisirišusią prie konkrečios sąsajos, sąmoningai apeina maršrutizavimo lentelę, ir tai keičia tik ugniasienės taisyklė, vardų erdvė arba politikos maršrutas.

IPv6 nusipelno atskiros eilutės kontroliniame sąraše. Tunelis, kuris neša tik IPv4, palieka dvigubo steko mazgui antrą tinkamą kelią, ir dvigubo steko paskirties taškas jį rinksis — įskaitant DNS, jei resolveris pasiekiamas per IPv6. Išjunkite IPv6 adapteryje arba patvirtinkite, kad tunelis jį neša, prieš laikydami IPv4 rezultatą išsamiu.

Kai patikrinimai nesutampa, nesutapimas paprastai įvardija gedimą:

Veikianti tvarka: išsaugokite maršrutizavimo lentelę prieš prisijungimą ir po jo, sekite vieną vidinį ir vieną viešą vardą, įrašykite DNS fiziniame adapteryje, grąžinkite išėjimo adresą iš apvalkalo konkrečiai programai, tada skaitykite serverį dėl apimties. Jei pirmi keturi sutampa, tunelis neša tai, ką manote, o likusi problema yra aukščiau. Jei du iš jų nesutampa, nesutampanti pora yra gedimas, o ne piktograma.