Prechádza prevádzka naozaj cez VPN? Ako to overiť

Dve poruchy vyzerajú z ikony v systémovej lište rovnako: prevádzka, ktorá vstupuje do tunela, a prevádzka, ktorá ho potichu obchádza. Klient v oboch prípadoch hlási Connected, pretože Connected znamená len to, že rozhranie tunela existuje a že klient nainštaloval trasy, ktoré chcel. Či jeden paket jednej aplikácie použil tie trasy, je samostatná otázka, na ktorú sa odpovedá na inom mieste zásobníka. Štyri merania vyriešia väčšinu — vyhľadanie trasy, prvý skok, zachytenie na fyzickom adaptéri a pozorovanie zvonku — a zobrazenie relácie na serveri pokryje zvyšok.

Začnite trasou, ktorou paket pôjde

Smerovacia tabuľka je rozhodnutie, preto sa jej opýtajte na jeden cieľ namiesto čítania celej a hádania. V Linuxe ip route get pomenuje rozhranie a zdrojovú adresu, ktoré vybralo jadro:

ip route get 203.0.113.10
ip route get 10.20.5.7

Vo Windowse je Find-NetRoute -RemoteIPAddress 203.0.113.10 užitočnejší ako route print -4 z rovnakého dôvodu: hlási trasu, ktorá vyhrala, nie všetky existujúce trasy. Napriek tomu si tabuľku raz prečítajte kvôli jej riadku 0.0.0.0. Dvojica /1 tam znamená, že klient plného tunela prepísal predvolenú trasu: voľba redirect-gateway def1 v OpenVPN inštaluje 0.0.0.0/1 a 128.0.0.0/1 cez tunel, čo pri najdlhšej zhode prefixu poráža existujúcu 0.0.0.0/0 bez toho, aby zmazala fyzickú predvolenú trasu. Preto môžu dve predvolené trasy existovať súčasne, kým všetko stále ide do tunela.

Dva detaily robia tabuľku luhárskou. Po prvé, pozerajte na prefix, ktorý sa zhodoval, nie na počet predvolených trás, pretože metrika rozhrania alebo dvojica /1 rozhodujú o víťazovi. Po druhé, už existujúce spojenie si zachováva cestu, s ktorou bolo vytvorené; po zdvihnutí tunela môže otvorená relácia používať starú trasu, kým sa neobnoví, a preto sa zdá, že opätovné pripojenie opravuje problém so smerovaním. Bežiaci klient — ps ax | grep openvpn — dokazuje len to, že proces sa spustil.

Sledujte jeden interný a jeden verejný názov

Vyhľadanie trasy ukazuje zámer; cesta ukazuje doručenie. Sledujte názov, ktorý musí byť interný, a názov, ktorý nesmie byť, kým ste pripojení, a porovnajte prvý skok:

traceroute intranet.corp.example
traceroute 1.1.1.1

Rovnaký prvý skok pre obidva znamená, že interný názov nikdy nevstúpil do tunela a porucha je nad ním, zvyčajne názov, ktorý sa prekladá na verejnú adresu, alebo trasa, ktorá nikdy nebola nainštalovaná. Ak interná prevádzka vychádza cez 10.8.0.1, kým verejná vychádza cez 192.168.1.1, rozdelený tunel robí presne to, na čo bol nastavený. Stopa, ktorá dosiahne bránu VPN a potom vracia len časové limity, je zvyčajne problém spiatočnej cesty alebo serverového firewallu, nie chýbajúca trasa preposielania.

Filtrovaný ICMP robí túto kontrolu luhárskou: hviezdičky na oboch stopách vyzerajú ako mŕtvy tunel a zvyčajne je to firewall. Otestujte TCP port, kde môžete — traceroute -T -p 443 v Linuxe — a pamätajte, že stopa nehovorí, ktorý prekladač odpovedal: názov sa môže preložiť lokálne a napriek tomu byť dostupný cez tunel.

Zachytávajte na fyzickom adaptéri, nie na tuneli

Fyzické spojenie je jediné miesto, ktoré ukazuje, čo sieť skutočne vidí. So zdvihnutým tunelom by sa relácia do kancelárie mala zjaviť ako šifrovaná záťaž adresovaná serveru VPN, nie ako spojenie na 10.20.5.7:

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

Prvý filter zachytí preklad názvov, ktorý vychádza lokálne, čo je najčastejší a najtichší únik — stránka sa aj tak načíta, prekladač len videl požiadavku. Druhý zachytí obyčajnú prevádzku na internú adresu, ktorá by mala existovať len vnútri tunela. Vo Windowse robí pktmon tú istú prácu bez ovládača: pktmon filter add -p 53, potom pktmon start --capture --pkt-size 128, potom pktmon stop a pktmon format pktmon.etl -o capture.txt. Tieto prepínače sa medzi verziami Windows mierne líšia, preto pred dôverou v syntax skontrolujte pktmon filter add /?.

Zachytávajte fyzické rozhranie, aby ste našli úniky; zachytenie na tuneli obsahuje pakety, o ktorých už veríte, že tam sú, a na serveri obsahuje nečitateľné vonkajšie pakety, ktorých zdrojom je brána. Bytové počítadlá na ktoromkoľvek rozhraní opisujú pakety, nie programy; priradiť prevádzku procesu vyžaduje monitor, ktorý mapuje sokety na procesy.

Opýtajte sa externej služby a potom sa opýtajte znova pre každú aplikáciu

Jediná kontrola, ktorá dokazuje výstup, je odpoveď zvonku: služba, ktorá vráti videnú zdrojovú adresu. Spustite ju z shellu, kde môžete vybrať rozhranie, a spustite ju dvakrát:

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

Rôzne odpovede vám dajú dôkaz oboch ciest a spôsob, ako otestovať konkrétnu aplikáciu: pripútajte ju alebo ju spustite v sieťovom mennom priestore s jednou trasou a pozrite, ktorú adresu vzdialený koniec zaznamená. Zhodné odpovede sú tá zaujímavá porucha: buď pripútanie nepôsobilo, alebo niečo medzi hostiteľom a vzdialeným koncom prepisuje zdrojovú adresu pred príchodom. Vo Windowse curl --interface chce adresu adaptéra, nie jeho názov.

Prehliadač, ktorý hlási adresu VPN, dokazuje prehliadač. Poštový klient, správca balíkov, zálohovací agent alebo druhý profil prehliadača môžu každý ísť inou cestou, najmä keď nastavenie proxy alebo trasa rozdeleného tunela pokrýva jeden z nich. Zmena adresy sama o sebe nie je dôkazom úniku: vyrovnávač záťaže môže odpovedať inak podľa videného výstupu, preto porovnávajte zaznamenanú zdrojovú adresu, nie stránku.

Potvrďte partnera pohľadom na server

Server odpovedá na inú otázku: či je partner pripojený, koľko preniesol a či sa relácia reštartovala. Partner, ktorý je na serveri aktívny, kým počítadlá klienta sa takmer nehýbu, znamená, že prevádzka aplikácie nevstupuje do tunela, čo by hovorila tabuľka klienta. Partner, ktorý prenáša veľa dát pre používateľa, ktorý hlási, že nič nefunguje, je iné vyšetrovanie.

Sú tu dve pasce. Maskovaný tunel robí, že každý tok vyzerá, akoby prichádzal z brány, takže protokoly a účtovanie po klientoch sa zlejú do jednej adresy. A klient sa považuje za miestneho hostiteľa, takže otázku, či niekto kopíruje súbory cez VPN, zodpovie prevádzka zdieľania súborov na serveri alebo audit hostiteľa na serveri — sledovanie tunela dá koncové body a objem, nie mená súborov.

Rozlíšte návrhové rozhodnutie od úniku

Nie všetko mimo tunela je únik. Prevádzka na prepojenom segmente a všesmerová zostáva z princípu lokálna, tlačiareň nájdená cez multicast sa ďalej hlási v LAN a DHCP musí odísť lokálne. Aplikácia pripútaná ku konkrétnemu rozhraniu zámerne obchádza smerovaciu tabuľku a mení to len pravidlo firewallu, menný priestor alebo politická trasa.

IPv6 si v kontrolnom zozname zaslúži vlastný riadok. Tunel, ktorý nesie len IPv4, necháva dvojzásobníkovému hostiteľovi druhú použiteľnú cestu a dvojzásobníkový cieľ ju uprednostní — vrátane DNS, ak je prekladač dostupný cez IPv6. Vypnite IPv6 na adaptéri alebo potvrďte, že ho tunel nesie, skôr než budete výsledok IPv4 považovať za úplný.

Keď sa kontroly nezhodujú, rozpor zvyčajne pomenuje poruchu:

Fungujúce poradie: uložte smerovaciu tabuľku pred pripojením a po ňom, sledujte jeden interný a jeden verejný názov, zachyťte DNS na fyzickom adaptéri, vráťte adresu výstupu zo shellu pre konkrétnu aplikáciu a potom prečítajte server kvôli objemu. Ak sa prvé štyri zhodujú, tunel nesie to, čo si myslíte, a zvyšný problém je nad ním. Ak sa dve z nich nezhodujú, nezhodná dvojica je porucha, nie ikona.