Promiskuöst läge på en VPN-adapter dödar anslutningen
En inspelning på en tunneladapter kan stoppa dess vidarebefordran. Stäng av promiskuöst läge, välj det lager som svarar på frågan och behandla filen som en hemlighet.
Wireshark beter sig felfritt på ett Ethernet-gränssnitt och sedan, på en VPN-adapter, slutar tunneln att föra vidare trafik i samma ögonblick som inspelningen börjar. Inspelningsfönstret fortsätter att fyllas, så verktyget ser friskt ut medan anslutningen under det dör. Promiskuöst läge är den vanliga orsaken, eftersom en tunneldrivrutin som ombeds leverera varje ram på ett segment den inte har kan hamna i ett tillstånd där ingenting går ut.
Stäng av det alternativet först och bestäm sedan vilket lager du faktiskt behöver se.
Två adaptrar, två olika vyer
En VPN-klient presenterar vanligtvis två gränssnitt: det fysiska som bär den krypterade transporten, och ett virtuellt som bär den dekrypterade inre trafiken. De svarar på olika frågor. Den fysiska inspelningen visar ändpunkter, portar och paketstorlekar, medan den virtuella visar applikationsprotokollen så som tunneln levererar dem. Att välja en utan att veta vilken fråga du ställer slösar bort inspelningen.
Ingen av vyerna är en övermängd av den andra, och en inspelning svarar sällan på båda frågorna samtidigt.
Välj gränssnittet utifrån frågan och inte utifrån listordningen, eftersom en klient i PPP-stil kan presentera sin adapter som en Ethernet-enhet och visningsnamnet kommer inte att berätta vilket lager du valde. En inspelning på en gateway eller en spegelport lägger till en tredje vy, som visar vägen efter vidarebefordran, och det är där asymmetrisk routning och filtrering blir synliga.
| Capture point | What it shows | What it cannot show |
|---|---|---|
| Physical interface | Outer endpoints, ports, packet sizes | Any inner payload |
| Tunnel interface | Decrypted inner traffic | What the VPN added around it |
| Gateway or mirror | Forwarded path after the tunnel | The client's own decision process |
Varför promiskuöst läge förstör en tunneladapter
Promiskuöst läge ber drivrutinen leverera ramar som inte är adresserade till värden, vilket är meningsfullt på ett delat Ethernet-segment och mycket lite meningsfullt på en punkt-till-punkt-tunnel. Vissa drivrutiner hanterar begäran lugnt; andra slutar ta ut sändningstrafik ur kön, och gränssnittet blir tyst ett svart hål. Inspelningen registrerar fortfarande vad som kommer in, så filen ser ut som bevis på en fungerande förbindelse. Just den klyftan mellan vad filen visar och vad gränssnittet gjorde är hela fällan.
Stäng av alternativet före det första paketet, håll inspelningsfiltret smalt och använd en liten buffert. En stor ringbuffert på ett upptaget gränssnitt tappar just de ramar som spelade roll, vilket ger en inspelning som är komplett överallt utom där felet fanns.
Om förbindelsen stannar mitt i inspelningen, stoppa den och se efter återhämtning. Den enda observationen skiljer en bieffekt av inspelningen från ett verkligt tunnelfel, och den tar mindre tid än någon filterjustering.
Att göra en IPsec-inspelning läsbar
En IPsec-inspelning är i sig inte läsbar, eftersom ESP krypterar nyttolasten. Wireshark kan avkoda den när du levererar sessionsnycklarna, eller när det kan följa den IKE-förhandling som skapade dem, vilket innebär att handskakningen måste finnas i samma fil.
Nycklar går ut. Efter att parterna har förnyat nycklarna slutar en uppsättning gamla nycklar att fungera mitt i inspelningen, och resultatet ser ut som ett avkodarfel snarare än en tidsgräns.
Följ tillverkarens dokumenterade nyckelformat i stället för att importera material från en orelaterad källa, och räkna med att vissa plattformar avvisar hela arbetsflödet. När gatewayen inte lämnar ut nycklar eller tillåter inspelningen får du acceptera att nyttolasten inte kan granskas där du sitter. Ändpunktsloggar och gränssnittsräknare är de återstående bevisen, och de räcker oftast för en routingfråga.
En inspelning du kan dela säkert
En inre inspelning är närmare ett läckage av inloggningsuppgifter än en logg. Den kan innehålla namn, adresser och klartext från protokoll skrivna med antagandet att ingen någonsin skulle läsa dem, vilket gör själva filen till det känsliga artefakten och inte analysen.
Se till att värden och nätverket är sådana där du får spela in, anteckna både gränssnittet och filtret tillsammans med resultatet, begränsa sessionen till de få minuter som svarar på frågan, och ta bort filen när du är klar. Om den måste delas, beskriv flödet eller ta bort nyttolasten först.
Upprepa sedan den ursprungliga användaruppgiften. En inspelning som bevisar att ett paket kom fram är inte bevis för att applikationen accepterade svaret, och skillnaden mellan de två är oftast där det verkliga felet finns.