Hvor du ser en OpenVPN-klients trafik på gatewayen

Du vil vide, hvilke destinationer en tilsluttet klient når, så du åbner en shell på VPN-serveren og skriver ss. Der vises ikke noget brugbart, og konklusionen om, at tunnelen er brudt, følger lidt for let. En ruterende OpenVPN-gateway videresender klientens pakker; den afslutter ikke deres TCP-forbindelser og ejer ikke sockets for dem. Beviset bor et andet sted, og hvor afhænger af, hvordan trafikken håndteres, når den forlader tunnelen.

Afgør, hvilket arrangement du kigger på

To almindelige former giver helt forskellige beviser. En ruterende gateway afkapsler, videresender og laver muligvis kilde-NAT, så klientens forbindelse fortsætter med at eksistere ende til ende uden en lokal socket.

En proxy afslutter trafik: den accepterer forbindelsen og åbner derefter sin egen opstrømsforbindelse. I det arrangement er der to forbindelser til én anmodning, og sammenhængen mellem dem findes kun i proxys egne registreringer. At vide, hvilken af dem du har udrullet, afgør, om du skal læse kernens flowtilstand eller applikationslogs.

Det meste forvirring kommer fra gætværk. Bekræft formen, før du vælger værktøjet. Læs først serverkonfigurationen for et proxydirektiv, fordi dets tilstedeværelse ændrer hvert senere skridt. Uden et er pakkestien ruting, og kernens flowtilstand er dit bevis.

Bind først adressen til en session

Start med serverens sessionstilstand og identificér klientens aktuelle indre adresse. Puljeadresser genbruges, så en adresse alene er en leasing, ikke en person.

Notér tid og den autentificerede identitet sammen, og bemærk, om et helt LAN skjuler sig bag den klient. Hvis den fjerne ende ruter et undernet, kan de indre adresser, du ser, være oprindelige værter eller oversatte.

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

Det par besvarer to spørgsmål på én gang: hvilket præfiks tunnelegrænsefladen betjener, og hvilken session der var aktiv i det interval, du interesserer dig for. Gør det, før du fortolker nogen flowpost, fordi en overbevisende tuple knyttet til den forkerte session er værre end slet intet bevis.

Læs flowtabellen på en ruterende gateway

Når adressen og intervallet er fastlagt, viser en skrivebeskyttet liste over sporede forbindelser, hvad gatewayen videresender for den. Filtrér på den oprindelige kilde, så du ikke læser hele tabellen.

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

Hver post indeholder to tuples, original og svar, som er de to retninger af ét flow og ikke to applikationer. På en kilde-NAT-sti beholder den oprindelige tuple tuneladressen, mens svarsiden viser gatewayens oversatte adresse, og det er præcis det, der får output til at se forkert ud ved første øjekast.

Behandl listen som levende tilstand og ikke som historik. Korte flows kan allerede være udløbet, usporet trafik vises aldrig, og et andet netværksnavnerum viser en anden tabel. conntrack-referencen dokumenterer filtrene og det tovejs output.

Én afgrænset optagelse til at bekræfte læsningen

Hvis tunnelegrænsefladen er synlig der, hvor du kigger, afgør én afgrænset optagelse, om de pakker, du identificerede, er dem på ledningen. Hold filteret smalt og pakkegrænsen lille.

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

Sammenlign tidsstempler, protokol og porte med flowposten og med den anmodning, du lavede som test. En optagelse taget efter NAT viser kun gatewayens offentlige adresse, mens tunnelsiden stadig kan vise klientens, og den forskel er information og ikke en uoverensstemmelse.

Hvis grænsefladen intet ser, skal du kontrollere datastien, før du konkluderer, at klienten er inaktiv: trafik mellem klienter og nogle offload-stier passerer aldrig det punkt, du overvåger.

Proxylogs og grænserne for, hvad du så

Når en proxy sidder i stien, er dens opstrømssockets synlige i sockettabellen, men de afbildes ikke en-til-en på VPN-klienter, især med pooling eller multipleksing. Brug proxys konfigurerede transaktionslog til at korrelere klientidentitet, destination, tidsstempel og enhver anmodningsidentifikator, den registrerer.

Kontrollér den udrullede versions logningskonfiguration i stedet for at antage, at hver anmodning logges som standard.

Vær endelig præcis om omfanget. En destinationsadresse og -port er metadata, ikke en URL og ikke sideindhold, fordi den indre HTTPS-session beholder sin egen beskyttelse uanset tunnelen. Rapportér, hvad du observerede, fra hvilket observationspunkt og på hvilket tidspunkt.