Kvar du ser trafikken til ein OpenVPN-klient på gatewayen

Du vil vite kva destinasjonar ein tilkopla klient når, så du opnar eit skal på VPN-tenaren og skriv ss. Ingenting nyttig dukkar opp, og konklusjonen om at tunnelen er øydelagd kjem litt for lett. Ein rutande OpenVPN-gateway videresender pakkane til klienten; han avsluttar ikkje TCP-sambanda deira og eig ikkje sockets for dei. Beviset bur ein annan stad, og kvar avheng av korleis trafikken vert handtert når han forlèt tunnelen.

Avgjer kva oppsett du ser på

To vanlege former gjev heilt ulike bevis. Ein rutande gateway avkapslar, videresender og gjer moglegvis kjelde-NAT, slik at sambandet til klienten held fram med å eksistere ende til ende utan ein lokal socket.

Ein proxy avsluttar trafikk: han godtek sambandet og opnar deretter sitt eige oppstraumsamband. I det oppsettet finst det to samband for éi førespurnad, og samanhengen mellom dei finst berre i proxyen sine eigne registreringar. Å vite kven av desse du har rulla ut avgjer om du bør lese flyttilstanden i kjernen eller applikasjonsloggar.

Det meste av forvirringa kjem frå gissing. Stadfest forma før du vel verktøy. Les først tenarkonfigurasjonen for eit proxydirektiv, fordi tilstadeværet endrar kvart seinare steg. Utan eitt er pakkevegen ruting, og flyttilstanden i kjernen er beviset ditt.

Knyt adressa til ein sesjon først

Start med sesjonstilstanden til tenaren og identifiser den noverande indre adressa til klienten. Pooladresser vert gjenbrukte, så ei adresse åleine er ein leasing, ikkje ein person.

Noter tid og autentisert identitet saman, og legg merke til om eit heilt LAN skjuler seg bak den klienten. Viss den fjerne enden rutar eit subnett, kan dei indre adressene du ser vere opphavlege vertar eller omsette.

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

Det paret svarar på to spørsmål samstundes: kva prefiks tunnelegrensesnittet tener, og kva sesjon som var aktiv i intervallet du bryr deg om. Gjer dette før du tolkar noka flytoppføring, fordi ein overtydande tuppel knytt til feil sesjon er verre enn ingen bevis i det heile.

Les flyttabellen på ein rutande gateway

Når adressa og intervallet er fastsette, viser ei skriveverna liste over spora samband kva gatewayen videresender for henne. Filtrer på den opphavlege kjelda så du ikkje les heile tabellen.

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

Kvar oppføring held to tuplar, original og svar, som er dei to retningane av éin flyt og ikkje to applikasjonar. På ein kjelde-NAT-veg held den opphavlege tuppelen tunneladressa, medan svarssida viser den omsette gatewayadressa, og det er nettopp dette som får utdataa til å sjå feil ut ved første augekast.

Handter lista som levande tilstand og ikkje som historikk. Korte flytar kan alt vere utløpte, uspora trafikk viser seg aldri, og eit anna nettverksnamnerom viser ein annan tabell. conntrack-referansen dokumenterer filtera og det tovegs utdataet.

Eitt avgrensa opptak for å stadfeste lesinga

Viss tunnelegrensesnittet er synleg der du ser, avgjer eitt avgrensa opptak om pakkane du identifiserte er dei som er på leidninga. Hald filteret smalt og pakkegrensa lita.

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

Samanlikn tidsstempel, protokoll og portar med flytoppføringa og med førespurnaden du laga som test. Eit opptak teke etter NAT viser berre den offentlege adressa til gatewayen, medan tunnelsida framleis kan vise klienten si, og den skilnaden er informasjon og ikkje ein inkonsistens.

Viss grensesnittet ikkje ser noko, kontroller datastien før du konkluderer med at klienten er inaktiv: trafikk mellom klientar og nokre offload-stiar passerer aldri punktet du overvakar.

Proxyloggar, og grensene for det du såg

Når ein proxy sit i vegen, er oppstraumssocketane hans synlege i socket-tabellen, men dei mappar ikkje ein-til-ein på VPN-klientar, særleg med pooling eller multipleksing. Bruk den konfigurerte transaksjonsloggen til proxyen for å korrelere klientidentitet, destinasjon, tidsstempel og kvar førespurnadsidentifikator han registrerer.

Kontroller loggingsoppsettet til den utrulla versjonen i staden for å anta at kvar førespurnad vert logga som standard.

Til slutt, ver presis om omfanget. Ei destinasjonsadresse og ein port er metadata, ikkje ein URL og ikkje sideinnhald, fordi den indre HTTPS-sesjonen held si eiga vern uavhengig av tunnelen. Rapporter kva du observerte, frå kva observasjonspunkt og til kva tid.