Var du ser en OpenVPN-klients trafik på gatewayen

Du vill veta vilka destinationer en ansluten klient når, så du öppnar ett skal på VPN-servern och skriver ss. Inget användbart dyker upp, och slutsatsen att tunneln är trasig kommer lite för lätt. En routande OpenVPN-gateway vidarebefordrar klientens paket; den avslutar inte deras TCP-anslutningar och äger inga sockets för dem. Beviset bor någon annanstans, och var beror på hur trafiken hanteras när den lämnar tunneln.

Avgör vilket upplägg du tittar på

Två vanliga former ger helt olika bevis. En routande gateway avkapslar, vidarebefordrar och gör möjligen käll-NAT, så klientens anslutning fortsätter att existera från ände till ände utan lokal socket.

En proxy avslutar trafik: den accepterar anslutningen och öppnar sedan sin egen uppströmsanslutning. I det upplägget finns två anslutningar för en begäran, och kopplingen mellan dem finns bara i proxyns egna poster. Att veta vilken av dessa du har driftsatt avgör om du bör läsa kärnans flödestillstånd eller applikationsloggar.

Det mesta av förvirringen kommer från gissningar. Bekräfta formen innan du väljer verktyg. Läs först serverkonfigurationen efter ett proxydirektiv, eftersom dess närvaro ändrar varje senare steg. Utan ett är paketvägen routing och kärnans flödestillstånd är ditt bevis.

Knyt adressen till en session först

Börja med serverns sessionstillstånd och identifiera klientens nuvarande inre adress. Pooladresser återanvänds, så en adress i sig är en leasing, inte en person.

Notera tid och autentiserad identitet tillsammans, och lägg märke till om ett helt LAN gömmer sig bakom den klienten. Om fjärränden routar ett subnät kan de inre adresserna du ser vara ursprungliga värdar eller översatta.

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

Det paret svarar på två frågor samtidigt: vilket prefix tunnelgränssnittet betjänar, och vilken session som var aktiv i intervallet du bryr dig om. Gör detta innan du tolkar någon flödespost, eftersom en övertygande tupel knuten till fel session är värre än inga bevis alls.

Läs flödestabellen på en routande gateway

När adressen och intervallet är fastställda visar en skrivskyddad lista över spårade anslutningar vad gatewayen vidarebefordrar för den. Filtrera på den ursprungliga källan så att du inte läser hela tabellen.

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

Varje post håller två tupler, original och svar, som är de två riktningarna av ett enda flöde och inte två applikationer. På en käll-NAT-väg behåller den ursprungliga tupeln tunneladressen, medan svarssidan visar gatewayens översatta adress, och det är just detta som får utdata att se fel ut vid första anblicken.

Behandla listan som levande tillstånd och inte som historik. Korta flöden kan redan ha gått ut, ospårad trafik visas aldrig, och ett annat nätverksnamnrymd visar en annan tabell. conntrack-referensen dokumenterar filtren och den tvåriktade utdatan.

En avgränsad inspelning för att bekräfta läsningen

Om tunnelgränssnittet syns där du tittar avgör en enda avgränsad inspelning om paketen du identifierade är de som finns på ledningen. Håll filtret smalt och paketgränsen liten.

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

Jämför tidsstämplar, protokoll och portar med flödesposten och med begäran du gjorde som test. En inspelning tagen efter NAT visar bara gatewayens publika adress, medan tunnelsidan fortfarande kan visa klientens, och den skillnaden är information och inte en inkonsekvens.

Om gränssnittet inte ser något, kontrollera datavägen innan du drar slutsatsen att klienten är overksam: trafik mellan klienter och vissa avlastningsvägar passerar aldrig punkten du bevakar.

Proxyloggar och gränserna för vad du såg

När en proxy sitter i vägen syns dess uppströmssockets i sockettabellen, men de mappar inte ett-till-ett mot VPN-klienter, särskilt inte med poolning eller multiplexning. Använd proxyns konfigurerade transaktionslogg för att korrelera klientidentitet, destination, tidsstämpel och varje begäransidentifierare som den registrerar.

Kontrollera loggningskonfigurationen för den driftsatta versionen i stället för att anta att varje begäran loggas som standard.

Slutligen, var exakt om omfattningen. En destinationsadress och en port är metadata, inte en URL och inte sidinnehåll, eftersom den inre HTTPS-sessionen behåller sitt eget skydd oavsett tunneln. Rapportera vad du observerade, från vilken observationspunkt och vid vilken tid.