La modalità promiscua su un adattatore VPN uccide la connessione
Una cattura su un adattatore di tunnel può fermarne l’inoltro. Disattivate la modalità promiscua, scegliete lo strato che risponde alla domanda e trattate il file come un segreto.
Wireshark si comporta perfettamente su un’interfaccia Ethernet e poi, su un adattatore VPN, il tunnel smette di far passare traffico nel momento in cui inizia la cattura. La finestra di cattura continua a riempirsi, così lo strumento sembra sano mentre la connessione sotto di esso muore. La modalità promiscua è la causa abituale, perché un driver di tunnel a cui viene chiesto ogni frame su un segmento che non ha può finire in uno stato in cui nulla esce.
Disattivate prima quell’opzione, poi decidete quale strato avete davvero bisogno di vedere.
Due adattatori, due viste diverse
Un client VPN di solito presenta due interfacce: quella fisica che trasporta il traffico cifrato e una virtuale che trasporta il traffico interno decifrato. Rispondono a domande diverse. La cattura fisica mostra estremi, porte e dimensioni dei pacchetti, mentre quella virtuale mostra i protocolli applicativi come il tunnel li consegna. Sceglierne una senza sapere quale domanda si sta ponendo spreca la cattura.
Nessuna vista è un sovrainsieme dell’altra, e una cattura raramente risponde a entrambe le domande insieme.
Scegliete l’interfaccia dalla domanda e non dall’ordine dell’elenco, perché un client in stile PPP può presentare il suo adattatore come dispositivo Ethernet e il nome visualizzato non vi dirà quale strato avete selezionato. Una cattura su un gateway o su una porta mirror aggiunge una terza vista, che mostra il percorso dopo l’inoltro, ed è lì che l’instradamento asimmetrico e il filtraggio diventano visibili.
| 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 |
Perché la modalità promiscua rompe un adattatore di tunnel
La modalità promiscua chiede al driver di consegnare frame che non sono indirizzati all’host, cosa che ha senso su un segmento Ethernet condiviso e pochissimo senso su un tunnel punto a punto. Alcuni driver gestiscono la richiesta con calma; altri smettono di estrarre dalla coda il traffico di trasmissione, e l’interfaccia diventa silenziosamente un buco nero. La cattura registra comunque ciò che arriva, così il file sembra la prova di un collegamento che funziona. Proprio quel divario tra ciò che il file mostra e ciò che l’interfaccia ha fatto è tutta la trappola.
Disattivate l’opzione prima del primo pacchetto, mantenete stretto il filtro di cattura e usate un buffer piccolo. Un grande buffer circolare su un’interfaccia occupata scarta proprio i frame che contavano, producendo una cattura completa ovunque tranne dove stava il guasto.
Se il collegamento si blocca a metà cattura, fermate la cattura e osservate il recupero. Quella singola osservazione separa un effetto collaterale della cattura da un guasto reale del tunnel, e richiede meno tempo di qualsiasi regolazione dei filtri.
Rendere leggibile una cattura IPsec
Una cattura IPsec da sola non è leggibile, perché ESP cifra il carico utile. Wireshark può decodificarla quando fornite le chiavi di sessione, o quando può seguire la negoziazione IKE che le ha generate, il che significa che la stretta di mano deve trovarsi nello stesso file.
Le chiavi scadono. Dopo che i peer hanno rinnovato le chiavi, un insieme di chiavi vecchie smette di funzionare a metà cattura, e il risultato sembra un bug del decodificatore invece di un limite temporale.
Seguite il formato delle chiavi documentato dal fornitore invece di importare materiale da una fonte non correlata, e aspettatevi che alcune piattaforme rifiutino del tutto questo flusso di lavoro. Quando il gateway non consegna le chiavi né permette la cattura, accettate che il carico utile non sia ispezionabile da dove siete. I log degli estremi e i contatori dell’interfaccia sono le prove rimanenti, e di solito bastano per una domanda di instradamento.
Una cattura che potete condividere in sicurezza
Una cattura interna è più vicina a un dump di credenziali che a un log. Può contenere nomi, indirizzi e testo in chiaro di protocolli scritti sul presupposto che nessuno li avrebbe mai letti, il che rende il file stesso l’artefatto sensibile e non l’analisi.
Assicuratevi che l’host e la rete siano ambienti in cui vi è consentito catturare, annotate sia l’interfaccia sia il filtro insieme al risultato, limitate la sessione ai pochi minuti che rispondono alla domanda e rimuovete il file quando avete finito. Se deve essere condiviso, descrivete prima il flusso o rimuovete il carico utile.
Poi ripetete il compito originale dell’utente. Una cattura che dimostra che un pacchetto è arrivato non è la prova che l’applicazione abbia accettato la risposta, e la differenza tra le due cose è di solito dove vive il guasto reale.