Cosa può e cosa non può dimostrare una schermata di iftop su una VPN

Una schermata di iftop risponde a una domanda per volta: quali coppie di host si scambiano byte attraverso l’interfaccia verso cui l’avete indirizzata. Non risponde se ogni applicazione segue una politica VPN, e una schermata vuota non dimostra che non sia trapelato nulla. È proprio nello scarto tra queste due affermazioni che sbagliano la maggior parte delle discussioni sui test di perdita. Tre condizioni decidono cosa significa davvero la visualizzazione, e tutte e tre sono visibili nella riga di comando che avete usato.

Tre condizioni decidono cosa significa la schermata

Le condizioni sono quale interfaccia viene mostrata, cosa nascondono il filtro e lo strumento stesso, e cosa ha davvero esercitato il test. Rispondete nell’ordine, perché un errore nella prima rende inutili le altre due.

La condizione dell’interfaccia conta perché la vista del tunnel e la vista fisica mostrano strati diversi dello stesso traffico. Guardare l’interfaccia del tunnel mostra i flussi dentro il tunnel; guardare l’interfaccia fisica mostra il portatore del tunnel, più qualsiasi traffico legittimo di configurazione, controllo o locale che condivida quel collegamento. Nessuna delle due viste è sbagliata, e nessuna è l’immagine completa. Nominare quella che state guardando è la differenza tra una prova e un’impressione.

Condizione uno: quale interfaccia viene mostrata

iftop prende l’interfaccia esplicitamente con -i, e il suo manuale descrive il comportamento quando non lo fate: ne sceglie una, che può essere il dispositivo dall’aspetto esterno invece del tunnel. Quel valore predefinito è una scelta ragionevole per uno strumento di banda e pessima per un test di perdita.

Passate sempre l’interfaccia, e annotatela accanto al risultato. Uno screenshot senza il nome dell’interfaccia non è riproducibile.

Condizione due: cosa nascondono il filtro e lo strumento

iftop accetta un’espressione di filtro, e un flusso che il filtro esclude è invisibile per costruzione e non per assenza. Lo strumento esegue anche, per impostazione predefinita, ricerche di nomi host per etichettare gli indirizzi, e quelle ricerche generano traffico DNS proprio, cioè traffico che non intendevate osservare. -n disattiva le ricerche e rende numerica la visualizzazione; nascondere poi le righe DNS non è lo stesso che non generare le query.

Vale la pena dire quella distinzione senza giri di parole, perché compare anche in altri strumenti: sopprimere la visualizzazione di un’attività non è lo stesso che impedirla. Se le ricerche DNS fanno parte di ciò che state testando, eseguite il test con le ricerche disattivate, così che l’osservazione non sia contaminata dall’osservatore.

Condizione tre: cosa ha davvero esercitato il test

Una sola richiesta da un’applicazione, verso una destinazione, in una famiglia di indirizzi dimostra qualcosa su quella richiesta. Non dimostra nulla su un’altra applicazione, un’altra destinazione o l’altra famiglia di indirizzi, e IPv6 è la famiglia che più spesso si dimentica proprio in questo tipo di verifica.

Definite quindi la richiesta prima di iniziare: una destinazione innocua, dall’applicazione che vi interessa, nella famiglia che vi interessa, con il tunnel nel suo stato approvato. Poi controllate il lato ricevente o la diagnostica del client stesso, perché l’estremità remota sa cosa è arrivato in un modo che la schermata locale non può. Poi esercitate il caso approvato del tunnel non disponibile e guardate se il traffico si ferma, perché è il comportamento a cui il requisito di solito si riferisce davvero.

Il DNS merita una sua osservazione. Il destinatario della query e il percorso che la query ha preso sono due fatti, e una schermata di banda non mostra né l’uno né l’altro.

Usare iftop come prova di supporto

Solo allora iftop aggiunge valore, e lo aggiunge come conferma. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" mostra se il flusso atteso compare sull’interfaccia attesa, con conteggi di byte che rendono verificabile un’affermazione di inattività.

Confrontatelo con ss -tnp per la vista a livello di socket e ip route get per il percorso che il kernel sceglierebbe, e avete tre osservazioni di una richiesta invece di un’impressione di una macchina. Il manuale di iftop documenta la selezione dell’interfaccia, la sintassi del filtro e il comportamento delle ricerche, che sono le tre cose da cui dipende un test di perdita. Una schermata di banda localizza l’attività; il percorso, le eccezioni e il comportamento in caso di guasto decidono se quell’attività soddisfa il requisito.