Kde na bráně sledovat provoz klienta OpenVPN

Chcete vědět, na které cíle se připojený klient dostává, takže otevřete shell na serveru VPN a napíšete ss. Neobjeví se nic užitečného a závěr, že je tunel rozbitý, přijde trochu příliš snadno. Směrovaná brána OpenVPN přeposílá pakety klienta; neukončuje jejich TCP spojení a nevlastní pro ně sockety. Důkaz žije jinde a to jinde závisí na tom, jak se s provozem nakládá poté, co opustí tunel.

Určete, na kterou konfiguraci se díváte

Dva běžné tvary dávají zcela odlišné důkazy. Směrující brána dekapsuluje, přeposílá a případně provádí překlad zdrojové adresy, takže spojení klienta dál existuje od konce ke konci bez místního socketu.

Proxy provoz ukončuje: přijme spojení a potom otevře své vlastní spojení směrem nahoru. V takovém uspořádání existují pro jeden požadavek dvě spojení a souvislost mezi nimi existuje jen ve vlastních záznamech proxy. Znalost toho, které z nich jste nasadili, rozhoduje o tom, zda máte číst stav toků v jádře, nebo aplikační záznamy.

Většina zmatení pochází z hádání. Před výběrem nástroje tvar potvrďte. Nejprve si v konfiguraci serveru přečtěte, zda obsahuje direktivu proxy, protože její přítomnost mění každý další krok. Bez ní je cesta paketů směrování a stav toků v jádře je váš důkaz.

Nejprve přivažte adresu k relaci

Začněte stavem relací na serveru a určete aktuální vnitřní adresu klienta. Adresy z fondu se recyklují, takže adresa sama o sobě je pronájem, ne osoba.

Zaznamenejte čas a ověřenou identitu společně a poznamenejte si, zda se za tímto klientem skrývá celá lokální síť. Pokud vzdálený konec směruje podsíť, vnitřní adresy, které vidíte, mohou být původní hostitelé nebo přeložené.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Tato dvojice odpovídá na dvě otázky najednou: kterému prefixu slouží rozhraní tunelu a která relace byla aktivní v intervalu, který vás zajímá. Udělejte to dřív, než začnete vykládat jakýkoli záznam toku, protože přesvědčivá čtveřice připojená ke špatné relaci je horší než žádný důkaz.

Čtěte tabulku toků na směrující bráně

Když jsou adresa a interval stanoveny, výpis sledovaných spojení pouze pro čtení ukáže, co za něj brána přeposílá. Filtrujte podle původního zdroje, abyste nečetli celou tabulku.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Každý záznam drží dvě čtveřice, původní a odpovědní, což jsou dva směry jednoho toku, nikoli dvě aplikace. Na cestě s překladem zdrojové adresy si původní čtveřice zachovává adresu tunelu, zatímco strana odpovědi ukazuje přeloženou adresu brány, a právě proto výstup na první pohled vypadá špatně.

Berte výpis jako živý stav, ne jako historii. Krátké toky už mohly vypršet, nesledovaný provoz se nikdy neobjeví a jiný síťový jmenný prostor ukazuje jinou tabulku. Referenční příručka ke conntrack dokumentuje filtry a obousměrný výstup.

Jedno omezené zachycení k potvrzení čtení

Pokud je rozhraní tunelu vidět tam, kam se díváte, jediné omezené zachycení rozhodne, zda pakety, které jste určili, jsou ty na drátě. Držte filtr úzký a limit paketů malý.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

Porovnejte časová razítka, protokol a porty se záznamem toku a s požadavkem, který jste poslali jako test. Zachycení pořízené po překladu adres ukazuje jen veřejnou adresu brány, zatímco strana tunelu může stále ukazovat adresu klienta, a ten rozdíl je informace, nikoli nesrovnalost.

Pokud rozhraní nic nevidí, zkontrolujte datovou cestu, než usoudíte, že klient je nečinný: provoz klient-klient a některé cesty odlehčení nikdy neprocházejí bodem, který sledujete.

Záznamy proxy a hranice toho, co jste viděli

Když je v cestě proxy, jeho sockety nahoru jsou vidět v tabulce socketů, ale nemapují se jedna ku jedné na klienty VPN, zvláště při sdružování nebo multiplexování. Použijte nakonfigurovaný transakční záznam proxy ke korelaci identity klienta, cíle, časového razítka a jakéhokoli identifikátoru požadavku, který zaznamenává.

Zkontrolujte konfiguraci protokolování nasazené verze, místo abyste předpokládali, že každý požadavek se protokoluje ve výchozím nastavení.

Nakonec buďte přesní v rozsahu. Cílová adresa a port jsou metadata, ne URL a ne obsah stránky, protože vnitřní relace HTTPS si uchovává vlastní ochranu bez ohledu na tunel. Hlaste, co jste pozorovali, ze kterého pozorovacího bodu a v jakém čase.