Waar om die verkeer van 'n OpenVPN-kliënt op die poort te volg

Jy wil weet watter bestemmings 'n gekoppelde kliënt bereik, so jy maak 'n dop op die VPN-bediener oop en tik ss. Niks nuttigs verskyn nie, en die gevolgtrekking dat die tonnel stukkend is, volg 'n bietjie te maklik. 'n Gerouteerde OpenVPN-poort stuur die kliënt se pakkette aan; dit beëindig nie hulle TCP-verbindings nie en besit ook nie sokke daarvoor nie. Die bewyse woon elders, en watter elders hang daarvan af hoe die verkeer hanteer word nadat dit die tonnel verlaat.

Bepaal watter rangskikking jy voor het

Twee algemene vorms lewer heeltemal verskillende bewyse. 'n Routerende poort dekapsuleer, stuur aan en doen moontlik bron-NAT, so die kliënt se verbinding bly van punt tot punt bestaan sonder 'n plaaslike sok.

'n Proxy beëindig verkeer: dit aanvaar die verbinding en maak dan sy eie opstroomverbinding oop. In daardie rangskikking is daar twee verbindings vir een versoek, en die verband tussen hulle bestaan net in die proxy se eie rekords. Om te weet watter een jy ontplooi het, bepaal of jy na die kernel se vloeitoestand of na toepassingslogboeke moet kyk.

Die meeste verwarring kom uit raai. Bevestig die vorm voordat jy die gereedskap kies. Lees eers die bedienerkonfigurasie vir 'n proxy-opdrag, want die teenwoordigheid daarvan verander elke latere stap. Sonder een is die pakketpad routering en is die kernel se vloeitoestand jou bewyse.

Koppel eers die adres aan 'n sessie

Begin by die bediener se sessietoestand en identifiseer die kliënt se huidige binneste adres. Poeladresse word hergebruik, so 'n adres op sy eie is 'n huur, nie 'n persoon nie.

Teken die tyd en die geauthentikeerde identiteit saam aan, en let op of 'n hele LAN agter daardie kliënt skuil. As die verre kant 'n subnet routeer, kan die binneste adresse wat jy sien oorspronklike hosts of vertaalde wees.

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

Daardie paar beantwoord twee vrae tegelyk: watter voorvoegsel die tonnelkoppelvlak dien, en watter sessie aktief was gedurende die interval wat jou aangaan. Doen dit voordat jy enige vloei-inskrywing interpreteer, want 'n oortuigende tuple wat aan die verkeerde sessie gekoppel is, is erger as geen bewyse hoegenaamd nie.

Lees die vloeitabel op 'n routerende poort

Met die adres en interval vasgestel, wys 'n lees-alleen lys van dopgehoude verbindings wat die poort daarvoor aanstuur. Filtreer op die oorspronklike bron sodat jy nie die hele tabel lees nie.

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

Elke inskrywing hou twee tuples, oorspronklik en antwoord, wat die twee rigtings van een vloei is eerder as twee toepassings. Op 'n bron-NAT-pad hou die oorspronklike tuple die tonneladres terwyl die antwoordkant die vertaalde poortadres wys, en dit is juis wat die uitvoer met die eerste oogopslag verkeerd laat lyk.

Hanteer die lys as lewende toestand en nie as 'n geskiedenis nie. Kort vloei kan al verval het, ongedopte verkeer verskyn nooit, en 'n ander netwerknaamruimte wys 'n ander tabel. Die conntrack-verwysing dokumenteer die filters en die tweerigting-uitvoer.

Een begrensde opname om die lesing te bevestig

As die tonnelkoppelvlak sigbaar is waar jy kyk, beslis 'n enkele begrensde opname of die pakkette wat jy geïdentifiseer het diegene op die draad is. Hou die filter smal en die pakketlimiet klein.

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

Vergelyk tydstempels, protokol en poorte met die vloei-inskrywing en met die versoek wat jy as toets gemaak het. 'n Opname wat ná NAT geneem is, wys net die poort se publieke adres, terwyl die tonnelkant steeds die kliënt se adres kan wys, en daardie verskil is inligting eerder as 'n teenstrydigheid.

As die koppelvlak niks sien nie, kontroleer die datapad voordat jy aflei dat die kliënt ledig is: kliënt-tot-kliënt-verkeer en sommige aflaairoetes beweeg nooit deur die punt wat jy dophou nie.

Proxy-logboeke, en die grense van wat jy gesien het

Wanneer 'n proxy in die pad sit, is sy opstroomsokke in die soktabel sigbaar, maar hulle karteer nie een-tot-een op VPN-kliënte nie, veral met poeling of multiplksing. Gebruik die proxy se gekonfigureerde transaksielog om kliëntidentiteit, bestemming, tydstempel en enige versoekidentifiseerder wat dit aanteken, met mekaar te korreleer.

Kontroleer die ontplooide weergawe se logkonfigurasie eerder as om te aanvaar dat elke versoek by verstek aangeteken word.

Laastens, wees presies oor die omvang. 'n Bestemmingsadres en -poort is metadata, nie 'n URL en nie bladsyinhoud nie, want die binneste HTTPS-sessie hou sy eie beskerming ongeag die tonnel. Rapporteer wat jy waargeneem het, vanaf watter waarnemingspunt, en op watter tyd.