Hvor du ser trafikken til en OpenVPN-klient på gatewayen

Du vil vite hvilke destinasjoner en tilkoblet klient når, så du åpner et skall på VPN-serveren og skriver ss. Ingenting nyttig dukker opp, og konklusjonen om at tunnelen er ødelagt kommer litt for lett. En rutende OpenVPN-gateway videresender klientens pakker; den avslutter ikke TCP-forbindelsene deres og eier ikke sockets for dem. Beviset bor et annet sted, og hvor avhenger av hvordan trafikken håndteres når den forlater tunnelen.

Avgjør hvilket oppsett du ser på

To vanlige former gir helt forskjellige bevis. En rutende gateway avkapsler, videresender og gjør muligens kilde-NAT, slik at klientens forbindelse fortsetter å eksistere ende til ende uten en lokal socket.

En proxy avslutter trafikk: den godtar forbindelsen og åpner deretter sin egen oppstrømsforbindelse. I det oppsettet finnes det to forbindelser for én forespørsel, og sammenhengen mellom dem finnes bare i proxyens egne registreringer. Å vite hvilken av disse du har rullet ut avgjør om du bør lese kjernens flyttilstand eller applikasjonslogger.

Det meste av forvirringen kommer fra gjetting. Bekreft formen før du velger verktøyet. Les først serverkonfigurasjonen for et proxydirektiv, fordi tilstedeværelsen endrer hvert senere steg. Uten ett er pakkeveien ruting, og kjernens flyttilstand er beviset ditt.

Knytt adressen til en sesjon først

Start med serverens sesjonstilstand og identifiser klientens nåværende indre adresse. Pooladresser gjenbrukes, så en adresse alene er en leasing, ikke en person.

Noter tid og autentisert identitet sammen, og legg merke til om et helt LAN skjuler seg bak den klienten. Hvis den fjerne enden ruter et subnett, kan de indre adressene du ser være opprinnelige verter eller oversatte.

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

Det paret svarer på to spørsmål samtidig: hvilket prefiks tunnelegrensesnittet betjener, og hvilken sesjon som var aktiv i intervallet du bryr deg om. Gjør dette før du tolker noen flytoppføring, fordi en overbevisende tuppel knyttet til feil sesjon er verre enn ingen bevis i det hele tatt.

Les flyttabellen på en rutende gateway

Når adressen og intervallet er fastslått, viser en skrivebeskyttet liste over sporede forbindelser hva gatewayen videresender for den. Filtrer på den opprinnelige kilden så du ikke leser hele tabellen.

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

Hver oppføring holder to tupler, original og svar, som er de to retningene av én flyt og ikke to applikasjoner. På en kilde-NAT-vei beholder den opprinnelige tuppelen tunneladressen, mens svarssiden viser gatewayens oversatte adresse, og det er nettopp dette som får utdataene til å se feil ut ved første øyekast.

Behandle listen som levende tilstand og ikke som historikk. Korte flyter kan allerede være utløpt, usporet trafikk vises aldri, og et annet nettverksnavnerom viser en annen tabell. conntrack-referansen dokumenterer filtrene og det toveis utdataene.

Ett avgrenset opptak for å bekrefte lesningen

Hvis tunnelegrensesnittet er synlig der du ser, avgjør ett avgrenset opptak om pakkene du identifiserte er de som er på ledningen. Hold filteret smalt og pakkegrensen liten.

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

Sammenlign tidsstempler, protokoll og porter med flytoppføringen og med forespørselen du laget som test. Et opptak tatt etter NAT viser bare gatewayens offentlige adresse, mens tunnelsiden fortsatt kan vise klientens, og den forskjellen er informasjon og ikke en inkonsistens.

Hvis grensesnittet ikke ser noe, kontroller datastien før du konkluderer med at klienten er inaktiv: trafikk mellom klienter og noen offload-stier passerer aldri punktet du overvåker.

Proxylogger, og grensene for det du så

Når en proxy sitter i veien, er oppstrømssocketene dens synlige i socket-tabellen, men de mapper ikke en-til-en på VPN-klienter, særlig med pooling eller multipleksing. Bruk proxyens konfigurerte transaksjonslogg til å korrelere klientidentitet, destinasjon, tidsstempel og enhver forespørselsidentifikator den registrerer.

Kontroller loggingsoppsettet til den utrullede versjonen i stedet for å anta at hver forespørsel logges som standard.

Til slutt, vær presis om omfanget. En destinasjonsadresse og en port er metadata, ikke en URL og ikke sideinnhold, fordi den indre HTTPS-sesjonen beholder sin egen beskyttelse uavhengig av tunnelen. Rapporter hva du observerte, fra hvilket observasjonspunkt og til hvilken tid.