Kde na bráne sledovať prevádzku klienta OpenVPN

Chcete vedieť, na ktoré ciele sa pripojený klient dostáva, takže otvoríte shell na serveri VPN a napíšete ss. Neobjaví sa nič užitočné a záver, že tunel je pokazený, príde trochu príliš ľahko. Smerovaná brána OpenVPN preposiela pakety klienta; neukončuje ich TCP spojenia a nevlastní pre ne sockety. Dôkaz žije inde a to inde závisí od toho, ako sa s prevádzkou zaobchádza po opustení tunela.

Určte, na ktoré usporiadanie sa pozeráte

Dva bežné tvary dávajú úplne odlišné dôkazy. Smerujúca brána dekapsuluje, preposiela a prípadne robí preklad zdrojovej adresy, takže spojenie klienta naďalej existuje od konca do konca bez miestneho socketu.

Proxy prevádzku ukončuje: prijme spojenie a potom otvorí svoje vlastné spojenie smerom nahor. V takom usporiadaní existujú pre jednu požiadavku dve spojenia a súvislosť medzi nimi existuje len vo vlastných záznamoch proxy. Poznanie toho, ktoré z nich ste nasadili, rozhoduje o tom, či máte čítať stav tokov v jadre alebo aplikačné záznamy.

Väčšina zmätku pochádza z hádania. Pred výberom nástroja tvar potvrďte. Najprv si v konfigurácii servera prečítajte, či obsahuje direktívu proxy, pretože jej prítomnosť mení každý ďalší krok. Bez nej je cesta paketov smerovanie a stav tokov v jadre je váš dôkaz.

Najprv priraďte adresu k relácii

Začnite stavom relácií na serveri a určte aktuálnu vnútornú adresu klienta. Adresy z fondu sa recyklujú, takže adresa sama o sebe je prenájom, nie osoba.

Zaznamenajte čas a overenú identitu spoločne a všimnite si, či sa za týmto klientom neskrýva celá lokálna sieť. Ak vzdialený koniec smeruje podsieť, vnútorné adresy, ktoré vidíte, môžu byť pôvodné hostiteľské alebo preložené.

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

Táto dvojica odpovedá na dve otázky naraz: ktorému prefixu slúži rozhranie tunela a ktorá relácia bola aktívna v intervale, ktorý vás zaujíma. Urobte to skôr, než začnete interpretovať akýkoľvek záznam toku, pretože presvedčivá štvorica pripojená k nesprávnej relácii je horšia ako žiadny dôkaz.

Čítajte tabuľku tokov na smerujúcej bráne

Keď sú adresa a interval stanovené, výpis sledovaných spojení iba na čítanie ukáže, čo za ňu brána preposiela. Filtrujte podľa pôvodného zdroja, aby ste nečítali celú tabuľku.

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

Každý záznam drží dve štvorice, pôvodnú a odpoveďovú, ktoré sú dva smery jedného toku, nie dve aplikácie. Na ceste s prekladom zdrojovej adresy si pôvodná štvorica zachováva adresu tunela, zatiaľ čo strana odpovede ukazuje preloženú adresu brány, a práve preto výstup na prvý pohľad vyzerá nesprávne.

Berte výpis ako živý stav, nie ako históriu. Krátke toky už mohli vypršať, nesledovaná prevádzka sa nikdy neobjaví a iný sieťový menný priestor ukazuje inú tabuľku. Referenčná príručka ku conntrack dokumentuje filtre a obojsmerný výstup.

Jedno obmedzené zachytenie na potvrdenie čítania

Ak je rozhranie tunela viditeľné tam, kam sa pozeráte, jediné obmedzené zachytenie rozhodne, či pakety, ktoré ste určili, sú tie na drôte. Držte filter úzky a limit paketov malý.

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

Porovnajte časové značky, protokol a porty so záznamom toku a s požiadavkou, ktorú ste poslali ako test. Zachytenie urobené po preklade adries ukazuje len verejnú adresu brány, zatiaľ čo strana tunela môže stále ukazovať adresu klienta, a ten rozdiel je informácia, nie nezrovnalosť.

Ak rozhranie nič nevidí, skontrolujte dátovú cestu, kým usúdite, že klient je nečinný: prevádzka klient-klient a niektoré cesty odľahčenia nikdy neprechádzajú bodom, ktorý sledujete.

Záznamy proxy a hranice toho, čo ste videli

Keď je v ceste proxy, jeho sockety nahor sú viditeľné v tabuľke socketov, ale nemapujú sa jedna k jednej na klientov VPN, najmä pri združovaní alebo multiplexovaní. Použite nakonfigurovaný transakčný záznam proxy na koreláciu identity klienta, cieľa, časovej značky a akéhokoľvek identifikátora požiadavky, ktorý zaznamenáva.

Skontrolujte konfiguráciu protokolovania nasadenej verzie, namiesto toho, aby ste predpokladali, že každá požiadavka sa protokoluje predvolene.

Nakoniec buďte presní v rozsahu. Cieľová adresa a port sú metadáta, nie URL a nie obsah stránky, pretože vnútorná relácia HTTPS si zachováva vlastnú ochranu bez ohľadu na tunel. V hlásení uveďte, čo ste pozorovali, z ktorého pozorovacieho bodu a v akom čase.