Varför tcpdump bara visar IPsec-klartext i en riktning

Du kör tcpdump på den yttre gränssnittet på en Linux IPsec-gateway och ser två saker samtidigt: inkommande ESP-ramar och, direkt efter dem, de dekrypterade inre paketen. Utgående visas bara ESP. Den naturliga slutsatsen är att svar inte skickas, eller att IPsec krypterar den ena riktningen och glömmer den andra. Ingen av dem är sann.

Det du tittar på är en fångstpunkt. Kärnan omvandlar utgående paket innan enhetens sändningsväg lämnar dem till paketsocketen, så socketen ser aldrig den inre formen på väg ut. Inkommande fångas paketet först som ESP, och den dekapsulerade kopian blir synlig när den kommer in i stacken igen. Samma trafik, två olika observationsfönster.

Fångstpunkten avgör vad du ser

På ett vanligt gränssnitt sitter en AF_PACKET-socket nära enhetslagret. Paket som lämnar värden går först genom IPsec-utgångsbearbetningen, som gör ett inre TCP-segment till ett ESP- eller UDP-4500-datagram, och når först därefter det lagret. Ankommande paket kopieras till socketen när de kommer in från kabeln, fortfarande krypterade, och det dekrypterade resultatet blir synligt senare när stacken levererar det lokalt eller vidarebefordrar det.

Den ordningen förklarar asymmetrin fullständigt. Det är inte bevis om riktning, policy eller applikationsbeteende, och att behandla det som det får folk att jaga ett svar som hela tiden skickades korrekt. Det är en av få nätverksgåtor där instrumentet, inte nätverket, skapar anomalin.

Anpassa filtret till lagret du menar

Ett uttryck som tcp port 443 väljer en inre TCP-anslutning. Utgående har den anslutningen redan blivit ESP när socketen tillfrågas, så filtret matchar ingenting. Om du vill räkna skyddad trafik, filtrera på den yttre formen i stället: protokoll 50 för rå ESP, eller UDP-port 4500 när NAT-traversering används. Båda filtren ger ett paketantal som kan jämföras mellan de två parterna, vilket oftast är anledningen till att räkna. Ingen av dem säger om den inre begäran besvarades.

Behandla inte ett UDP 4500-antal som ett ESP-paketantal. IKE använder också den porten för NAT-T keepalives och för det inkapslade utbytet, så antalet omfattar trafik som inte är de data du ville mäta. Det inledande IKE-utbytet på UDP 500 behöver ett eget filter om det är frågan. Ett antal som blandar kontrolltrafik med data gör också varje bandbreddsuppskattning fel med en okänd marginal. Separata räkningar svarar på separata frågor.

Skriv ner filtret bredvid frågan det besvarar. ”Hur mycket ESP lämnade lådan” och ”lämnade webbegäran lådan” är olika mätningar med olika filter, och en enda fångst kan inte avgöra båda. Utan den anteckningen kommer två personer att jämföra tal som aldrig räknade samma sak.

Observera före omvandlingen, inte efter

Om du behöver se utgående klartext, flytta observationspunkten tidigare, före IPsec-utgångsbearbetningen. NFLOG ger dig en Netfilter-krok där en regel kan kopiera valda paket till en socket i användarutrymmet, som tcpdump kan läsa. strongSwans guide för trafikdump dokumenterar just detta tillvägagångssätt av just denna anledning.

Policyträffen begränsar regeln till trafik som är på väg in i en tunnel. -m policy --pol ipsec --dir out är det som gör regeln specifik i stället för att logga varje paket lådan skickar. Läs sedan logggruppen med en begränsad fångst: ett litet antal ögonblicksbilder och en storleksgräns hindrar diagnostiken från att bli ett trafikarkiv. En begränsad fångst är också lättare att lämna till en granskare utan att släpa med irrelevant last. Bestäm antalet innan du börjar, inte efter att du sett hur mycket som kom.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

Välj kroken som passar flödet. OUTPUT täcker trafik som gatewayen själv genererar; transit från en LAN-klient går i stället genom FORWARD-kedjan, och en regel på OUTPUT kommer aldrig att se den. Adressen och porten ovan är platshållare för ett godkänt testmål.

Vad observationen bevisar

NFLOG är ett loggmål, inte ett acceptbeslut. Ett paket som dyker upp där visar att det nådde kroken och matchade regeln. Det visar inte att ett senare filter släppte igenom det, att enheten sände det, eller att motparten tog emot något.

En tom logg är lika tvetydig. Kontrollera regelns paketräknare, bekräfta riktningen, bekräfta att flödet verkligen matchade en IPsec-policy och bekräfta målet. Bara en överensstämmande räknare på båda parter gör en observation till en slutsats. Jämför sedan säkerhetsassociationens räknare på båda parter för samma kontrollerade försök, eftersom SA-räknarna är den auktoritativa registreringen av vad som skyddades och skickades.

Ännu en fälla: ”klartext” betyder här utanför IPsec-krypteringslagret. En inre HTTPS-session har fortfarande sin egen TLS. Att fånga det dekapsulerade paketet dekrypterar inte applikationens TLS, och att se läsbar HTTP där betyder att applikationen aldrig använde HTTPS.

Städa och jämför båda ändarna

Ta bort exakt den regel du infogade, efter dess ägare, så snart observationen är klar. Att lämna en loggningsregel på plats kostar CPU på varje matchande paket och skapar tyst ett datalagringsproblem. Radera genom att upprepa regeln med -D i stället för att spola en kedja du inte äger.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

Om driftsättningen använder IPsec i användarutrymmet, ett XFRM-gränssnitt eller hårdvaruavlastning flyttar observationspunkterna, och det här receptet kanske inte gäller alls. Med libipsec är den dokumenterade platsen för att observera inre trafik TUN-enheten. Identifiera vägen först, välj sedan punkten som besvarar frågan, och förvänta dig att de två riktningarna bara ser olika ut när du tittar på fel sida av omvandlingen.