Promiscue modus op een VPN-adapter doodt de verbinding
Een opname op een tunneladapter kan de doorsturing stopzetten. Schakel promiscue modus uit, kies de laag die de vraag beantwoordt en behandel het bestand als een geheim.
Wireshark gedraagt zich perfect op een Ethernet-interface en dan, op een VPN-adapter, stopt de tunnel met het doorlaten van verkeer op het moment dat de opname begint. Het opnamevenster blijft vollopen, dus de tool ziet er gezond uit terwijl de verbinding eronder sterft. Promiscue modus is de gebruikelijke oorzaak, want een tunneldriver die elk frame op een segment aanvraagt dat hij niet heeft, kan in een toestand belanden waarin niets meer naar buiten gaat.
Schakel die optie eerst uit en bepaal daarna welke laag u werkelijk moet zien.
Twee adapters, twee verschillende weergaven
Een VPN-client biedt meestal twee interfaces: de fysieke die het versleutelde transport draagt, en een virtuele die het ontsleutelde interne verkeer draagt. Ze beantwoorden verschillende vragen. De fysieke opname toont eindpunten, poorten en pakketgroottes, terwijl de virtuele de applicatieprotocollen toont zoals de tunnel ze aflevert. Eén kiezen zonder te weten welke vraag u stelt, verspilt de opname.
Geen van beide weergaven is een superset van de andere, en één opname beantwoordt zelden beide vragen tegelijk.
Kies de interface op basis van de vraag en niet van de volgorde in de lijst, want een client in PPP-stijl kan zijn adapter als Ethernet-apparaat presenteren en de weergegeven naam zal u niet vertellen welke laag u hebt gekozen. Een opname op een gateway of een spiegelpoort voegt een derde weergave toe, die het pad na de doorsturing toont, en daar worden asymmetrische routing en filtering zichtbaar.
| 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 |
Waarom promiscue modus een tunneladapter sloopt
Promiscue modus vraagt de driver frames af te leveren die niet aan de host zijn geadresseerd, wat zinvol is op een gedeeld Ethernet-segment en heel weinig zinvol op een punt-tot-punt-tunnel. Sommige drivers behandelen het verzoek rustig; andere stoppen met het uit de wachtrij halen van verzendverkeer, en de interface wordt stil een zwart gat. De opname blijft vastleggen wat er aankomt, dus het bestand lijkt het bewijs van een werkende verbinding. Juist die kloof tussen wat het bestand toont en wat de interface deed, is de hele valstrik.
Schakel de optie uit vóór het eerste pakket, houd het opnamefilter smal en gebruik een kleine buffer. Een grote ringbuffer op een drukke interface laat precies de frames vallen die ertoe deden, wat een opname oplevert die overal compleet is behalve waar de fout zat.
Als de verbinding midden in de opname vastloopt, stop dan en kijk of hij herstelt. Die ene observatie scheidt een bijwerking van de opname van een echte tunnelfout, en het kost minder tijd dan welke filterafstelling dan ook.
Een IPsec-opname leesbaar maken
Een IPsec-opname is op zichzelf niet leesbaar, omdat ESP de payload versleutelt. Wireshark kan hem decoderen wanneer u de sessiesleutels aanlevert, of wanneer het de IKE-onderhandeling kan volgen die ze heeft opgeleverd, wat betekent dat de handshake in hetzelfde bestand moet staan.
Sleutels verlopen. Nadat de peers de sleutels hebben vernieuwd, werkt een set oude sleutels halverwege de opname niet meer, en het resultaat lijkt op een decoderfout in plaats van op een tijdsgrens.
Volg het gedocumenteerde sleutelformaat van de leverancier in plaats van materiaal uit een niet-verwante bron te importeren, en verwacht dat sommige platforms de hele werkwijze weigeren. Als de gateway geen sleutels afgeeft of de opname niet toestaat, accepteer dan dat de payload vanaf uw positie niet te inspecteren is. Eindpuntlogboeken en interfacetellers zijn het resterende bewijs, en die zijn meestal genoeg voor een routeringsvraag.
Een opname die u veilig kunt delen
Een interne opname lijkt meer op een dump van inloggegevens dan op een logboek. Er kunnen namen, adressen en platte tekst in staan van protocollen die zijn geschreven in de veronderstelling dat niemand ze ooit zou lezen, waardoor het bestand zelf het gevoelige artefact is en niet de analyse.
Zorg dat de host en het netwerk er een zijn waarop u mag opnemen, noteer zowel de interface als het filter bij het resultaat, beperk de sessie tot de paar minuten die de vraag beantwoorden, en verwijder het bestand als u klaar bent. Als het gedeeld moet worden, beschrijf dan eerst de stroom of verwijder de payload.
Herhaal daarna de oorspronkelijke gebruikerstaak. Een opname die bewijst dat een pakket aankwam, is geen bewijs dat de toepassing het antwoord accepteerde, en het verschil tussen die twee is meestal waar de echte fout zit.