Prochází provoz skutečně přes VPN? Jak to ověřit

Dvě poruchy vypadají z ikony v oznamovací oblasti stejně: provoz, který vstupuje do tunelu, a provoz, který se mu tiše vyhýbá. Klient v obou případech hlásí Connected, protože Connected znamená jen to, že rozhraní tunelu existuje a že klient nainstaloval trasy, které chtěl. Zda jeden paket jedné aplikace tyto trasy použil, je samostatná otázka, na kterou se odpovídá na jiném místě zásobníku. Čtyři měření vyřeší většinu — vyhledání trasy, první skok, zachycení na fyzickém adaptéru a pozorování zvenčí — a pohled na relaci na serveru pokryje zbytek.

Začněte trasou, kterou paket půjde

Směrovací tabulka je rozhodnutí, proto se jí zeptejte na jeden cíl, místo abyste ji celou četli a hádali. V Linuxu ip route get pojmenuje rozhraní a zdrojovou adresu, které jádro vybralo:

ip route get 203.0.113.10
ip route get 10.20.5.7

Ve Windows je Find-NetRoute -RemoteIPAddress 203.0.113.10 užitečnější než route print -4 ze stejného důvodu: hlásí trasu, která vyhrála, ne všechny existující trasy. Přesto si tabulku jednou přečtěte kvůli jejímu řádku 0.0.0.0. Dvojice /1 tam znamená, že klient plného tunelu přepsal výchozí trasu: volba redirect-gateway def1 v OpenVPN instaluje 0.0.0.0/1 a 128.0.0.0/1 přes tunel, což při nejdelší shodě prefixu poráží existující 0.0.0.0/0, aniž by smazala fyzickou výchozí trasu. Proto mohou dvě výchozí trasy koexistovat, i když všechno stále jde do tunelu.

Dva detaily dělají tabulku lživou. Za prvé, dívejte se na prefix, který odpovídal, ne na počet výchozích tras, protože vítěze určuje metrika rozhraní nebo dvojice /1. Za druhé, spojení, které už existuje, si drží cestu, se kterou bylo navázáno; po zvednutí tunelu může otevřená relace používat starou trasu, dokud se nerestartuje, a proto se zdá, že opětovné připojení opravuje problém se směrováním. Běžící klient — ps ax | grep openvpn — dokazuje jen to, že proces začal.

Vystopujte jeden interní a jeden veřejný název

Vyhledání trasy ukazuje záměr; cesta ukazuje doručení. Vystopujte název, který musí být interní, a název, který být nesmí, zatímco jste připojeni, a porovnejte první skok:

traceroute intranet.corp.example
traceroute 1.1.1.1

Stejný první skok u obou znamená, že interní název nikdy nevstoupil do tunelu a porucha je nad ním, obvykle název, který se překládá na veřejnou adresu, nebo trasa, která nebyla nikdy nainstalována. Interní provoz vycházející přes 10.8.0.1, zatímco veřejný vychází přes 192.168.1.1, znamená, že rozdělený tunel dělá přesně to, k čemu byl nastaven. Trasa sledování, která dorazí k bráně VPN a pak vrací jen časové limity, je obvykle problém zpětné cesty nebo serverového firewallu, ne chybějící cesta přesměrování.

Filtrované ICMP dělá tuto kontrolu lživou: hvězdičky na obou trasách vypadají jako mrtvý tunel a obvykle to je firewall. Otestujte TCP port, kde můžete — traceroute -T -p 443 v Linuxu — a pamatujte, že sledování neříká, který překladač odpověděl: název se může přeložit lokálně a přesto být dostupný přes tunel.

Zachycujte na fyzickém adaptéru, ne na tunelu

Fyzické spojení je jediné místo, které ukazuje, co síť skutečně vidí. Se zvednutým tunelem by se relace do kanceláře měla objevit jako šifrovaný náklad adresovaný serveru VPN, ne jako spojení na 10.20.5.7:

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

První filtr chytá překlad názvů, který vychází lokálně, což je nejčastější a nejtišší únik — stránka se přesto načte, jen překladač viděl dotaz. Druhý chytá běžný provoz na interní adresu, která by měla existovat jen uvnitř tunelu. Ve Windows dělá pktmon stejnou práci bez ovladače: pktmon filter add -p 53, potom pktmon start --capture --pkt-size 128, potom pktmon stop a pktmon format pktmon.etl -o capture.txt. Tyto přepínače se mezi verzemi Windows trochu liší, proto si před důvěrou v syntaxi zkontrolujte pktmon filter add /?.

Zachycujte fyzické rozhraní, abyste našli úniky; zachycení na tunelu obsahuje pakety, o kterých už věříte, že tam jsou, a na serveru obsahuje nečitelné vnější pakety, jejichž zdrojem je brána. Bajtové čítače na kterémkoli rozhraní popisují pakety, ne programy; přiřadit provoz procesu vyžaduje monitor, který mapuje sockety na procesy.

Zeptejte se externí služby a pak se ptejte znovu pro každou aplikaci

Jediná kontrola, která dokazuje výstup, je odpověď zvenčí: služba, která vrátí zdrojovou adresu, kterou viděla. Spusťte ji z shellu, kde můžete vybrat rozhraní, a spusťte ji dvakrát:

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

Různé odpovědi vám dají důkaz obou cest a způsob, jak otestovat konkrétní aplikaci: přivažte ji nebo ji spusťte v síťovém jmenném prostoru s jedinou trasou a podívejte se, kterou adresu vzdálená strana zaznamená. Shodné odpovědi jsou ta zajímavá porucha: buď přivázání nefungovalo, nebo něco mezi hostitelem a vzdálenou stranou přepisuje zdrojovou adresu, než dorazí. Ve Windows curl --interface chce adresu adaptéru, ne jeho název.

Prohlížeč hlásící adresu VPN dokazuje prohlížeč. Poštovní klient, správce balíčků, zálohovací agent nebo druhý profil prohlížeče mohou každý jít jinou cestou, zvláště když nastavení proxy nebo trasa rozděleného tunelu pokrývá jeden z nich. Změna adresy sama o sobě není důkaz úniku: vyvažovač zatížení může odpovědět jinak podle výstupu, který viděl, proto porovnávejte zaznamenanou zdrojovou adresu, ne stránku.

Potvrďte protějšek pohledem na server

Server odpovídá na jinou otázku: zda je protějšek připojen, kolik přenesl a zda se relace restartovala. Protějšek, který je na serveru aktivní, zatímco čítače klienta se sotva hýbou, znamená, že provoz aplikace do tunelu nevstupuje, ať klientova tabulka říká cokoli. Protějšek, který přenáší hodně dat pro uživatele, jenž hlásí, že nic nefunguje, je jiné vyšetřování.

Jsou tu dvě pasti. Maskovaný tunel dělá, že každý tok vypadá, jako by přicházel z brány, takže protokoly a účtování po klientech se slijí do jedné adresy. A klient se považuje za místního hostitele, takže otázku, zda někdo kopíruje soubory přes VPN, zodpoví provoz sdílení souborů na serveru nebo audit hostitele na serveru — sledování tunelu dává koncové body a objem, ne jména souborů.

Rozlište designové rozhodnutí od úniku

Ne všechno mimo tunel je únik. Provoz na propojený segment a všesměrový provoz zůstává z principu lokální, tiskárna nalezená přes multicast se dál hlásí v LAN a DHCP musí odejít lokálně. Aplikace přivázaná ke konkrétnímu rozhraní záměrně obchází směrovací tabulku a to mění jen pravidlo firewallu, jmenný prostor nebo politická trasa.

IPv6 si v kontrolním seznamu zaslouží vlastní řádek. Tunel, který nese jen IPv4, nechává dvouzásuvkovému hostiteli druhou použitelnou cestu a dvouzásuvkový cíl ji upřednostní — včetně DNS, je-li překladač dosažitelný přes IPv6. Vypněte IPv6 na adaptéru nebo potvrďte, že ho tunel nese, než výsledek IPv4 budete považovat za úplný.

Když se kontroly rozcházejí, rozpor obvykle pojmenuje poruchu:

Fungující pořadí: uložte směrovací tabulku před připojením a po něm, vystopujte jeden interní a jeden veřejný název, zachyťte DNS na fyzickém adaptéru, vraťte adresu výstupu ze shellu pro konkrétní aplikaci, potom si přečtěte server kvůli objemu. Pokud se první čtyři shodují, tunel nese to, co si myslíte, a zbývající problém je nad ním. Pokud se dvě z nich rozcházejí, dvojice, která se rozchází, je porucha, ne ikona.