Waar je het verkeer van een OpenVPN-client op de gateway volgt

Je wilt weten welke bestemmingen een verbonden client bereikt, dus je opent een shell op de VPN-server en typt ss. Er verschijnt niets bruikbaars, en de conclusie dat de tunnel stuk is volgt iets te gemakkelijk. Een gerouteerde OpenVPN-gateway stuurt de pakketten van de client door; hij beëindigt hun TCP-verbindingen niet en bezit er geen sockets voor. Het bewijs woont ergens anders, en waar hangt af van hoe het verkeer wordt behandeld nadat het de tunnel verlaat.

Bepaal naar welke opstelling je kijkt

Twee gangbare vormen leveren volledig verschillend bewijs. Een routerende gateway decapsuleert, stuurt door en doet mogelijk source-NAT, zodat de verbinding van de client end-to-end blijft bestaan zonder lokale socket.

Een proxy beëindigt verkeer: hij accepteert de verbinding en opent dan zijn eigen upstreamverbinding. In die opstelling zijn er twee verbindingen voor één verzoek, en het verband ertussen bestaat alleen in de eigen administratie van de proxy. Weten welke van deze twee je hebt uitgerold bepaalt of je de flowstatus van de kernel of applicatielogs moet lezen.

De meeste verwarring komt van gissen. Bevestig de vorm voordat je het gereedschap kiest. Lees eerst de serverconfiguratie op een proxydirective, want de aanwezigheid ervan verandert elke volgende stap. Zonder die is het pakketpad routing en is de flowstatus van de kernel je bewijs.

Koppel eerst het adres aan een sessie

Begin bij de sessiestatus van de server en bepaal het huidige interne adres van de client. Pooladressen worden hergebruikt, dus een adres op zichzelf is een lease, geen persoon.

Noteer de tijd en de geauthenticeerde identiteit samen, en let op of er een heel LAN achter die client schuilt. Als het verre uiteinde een subnet routeert, kunnen de interne adressen die je ziet originele hosts of vertaalde zijn.

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

Dat paar beantwoordt twee vragen tegelijk: welk prefix de tunnelinterface bedient, en welke sessie actief was in het interval dat je aangaat. Doe dit voordat je welke flowregel dan ook interpreteert, want een overtuigende tuple die aan de verkeerde sessie hangt is erger dan helemaal geen bewijs.

Lees de flowtabel op een routerende gateway

Zodra adres en interval vaststaan, toont een alleen-lezen lijst van gevolgde verbindingen wat de gateway daarvoor doorstuurt. Filter op de oorspronkelijke bron zodat je niet de hele tabel leest.

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

Elke regel bevat twee tuples, origineel en antwoord, die de twee richtingen van één flow zijn en niet twee applicaties. Op een source-NAT-pad houdt de originele tuple het tunneladres, terwijl de antwoordzijde het vertaalde gatewayadres toont, en dat is precies wat de uitvoer op het eerste gezicht verkeerd laat lijken.

Behandel de lijst als levende toestand en niet als historie. Korte flows zijn misschien al verlopen, niet-gevolgd verkeer verschijnt nooit, en een andere netwerknamespace toont een andere tabel. De conntrack-referentie documenteert de filters en de tweerichtingsuitvoer.

Eén begrensde opname om de lezing te bevestigen

Als de tunnelinterface zichtbaar is waar je kijkt, beslist één begrensde opname of de pakketten die je hebt geïdentificeerd degenen op de draad zijn. Houd het filter smal en de pakketlimiet klein.

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

Vergelijk tijdstempels, protocol en poorten met de flowregel en met het verzoek dat je als test deed. Een opname na NAT toont alleen het publieke adres van de gateway, terwijl de tunnelzijde nog dat van de client kan tonen, en dat verschil is informatie en geen inconsistentie.

Ziet de interface niets, controleer dan het datapad voordat je concludeert dat de client inactief is: verkeer tussen clients en sommige offloadpaden passeren nooit het punt dat je bekijkt.

Proxylogs, en de grenzen van wat je zag

Staat er een proxy in het pad, dan zijn zijn upstreamsockets zichtbaar in de sockettabel, maar ze komen niet één-op-één overeen met VPN-clients, vooral niet bij pooling of multiplexing. Gebruik het geconfigureerde transactielog van de proxy om clientidentiteit, bestemming, tijdstempel en elke vastgelegde verzoekidentificatie te correleren.

Controleer de loggingconfiguratie van de uitgerolde versie in plaats van aan te nemen dat elk verzoek standaard wordt gelogd.

Wees ten slotte precies over de reikwijdte. Een bestemmingsadres en een poort zijn metadata, geen URL en geen pagina-inhoud, omdat de interne HTTPS-sessie zijn eigen bescherming houdt ongeacht de tunnel. Rapporteer wat je hebt waargenomen, vanaf welk observatiepunt en op welk tijdstip.