Verificare una VPN senza interfaccia: un flusso alla volta, con prove
Una macchina senza interfaccia ha bisogno di una richiesta di cui si possa leggere la risposta. Testate ogni famiglia di indirizzi, contesto e destinazione, poi annotate cosa il risultato non ha coperto.
Su una macchina senza interfaccia non c’è un browser da aprire né un lucchetto da guardare, quindi la verifica deve essere una richiesta di cui potete leggere la risposta. Sembra banale finché non notate che un solo risultato di indirizzo di uscita viene usato per certificare un dispositivo che esegue una dozzina di servizi, due famiglie di indirizzi e un proxy. Il percorso seguente costruisce una prova circoscritta alla volta, nello stesso contesto in cui il carico di lavoro viene realmente eseguito.
Decidete cosa deve dimostrare il test
Prima di eseguire qualsiasi cosa, scrivete l’attesa su una riga: quale flusso, attraverso quale interfaccia, verso quale destinazione e cosa si dovrebbe osservare all’altro capo. Un test senza un’attesa dichiarata produce un numero che nessuno può interpretare.
La versione più utile nomina un endpoint approvato che riporta l’indirizzo sorgente che ha visto.
Quell’endpoint è l’unica parte che dovete predisporre. Tutto il resto è un’osservazione lato client, e le osservazioni lato client vanno storte in modi interessanti.
Eseguite l’osservazione nel contesto giusto
La shell di un amministratore non è l’ambiente del carico di lavoro. Può portare una variabile proxy diversa, una tabella di routing diversa in un altro namespace o il file d’ambiente di un altro utente. Eseguite il test nello stesso contesto di host, container, namespace o servizio di ciò che state verificando. Altrimenti state misurando la vostra shell.
Su un host normale significa lo stesso utente e la stessa unità. In un parco di container significa entrare nel namespace di rete del container invece di testare dall’host. Su un servizio systemd può significare un’unità transitoria con le stesse impostazioni.
La richiesta che segue ha senso solo quando siete nel contesto giusto.
Verificate le famiglie di indirizzi separatamente
Chiedete ogni famiglia esplicitamente, perché una richiesta IPv4 riuscita non esercita affatto un percorso IPv6. I selettori --ipv4 e --ipv6 forzano la scelta, e la differenza tra i due risultati è essa stessa informazione.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceUna richiesta IPv6 fallita non è prova di un blocco efficace. Può significare che l’endpoint non ha un indirizzo IPv6, che il DNS non ha restituito nulla di utilizzabile o che il dispositivo non ha alcun percorso IPv6. Leggete il fallimento prima di trarne una conclusione. Una richiesta IPv6 riuscita attraverso il tunnel è l’unico risultato che dimostra che il percorso IPv6 è coperto.
Annotate entrambe le risposte fianco a fianco. Una sola di esse è metà di un fatto.
Aggiungete le quattro cose che una verifica di uscita trascura
Un indirizzo di uscita risponde a una domanda. Altre quattro decidono se il tunnel si comporta come progettato.
| Check | What it proves | What it does not |
|---|---|---|
| Included and excluded destinations | The split behaves as designed for those flows | Coverage of any other destination |
| Resolver path | Where a fresh lookup actually travelled | Where a cached answer came from |
| Tunnel-down behaviour | The failure policy for a new request | What an already open connection does |
| Reconnect and restart | The requirement survives the lifecycle event | Behaviour under load or partial failure |
La politica delle destinazioni viene prima: testate un flusso che dovrebbe essere incluso e uno che dovrebbe essere escluso, quando il progetto prevede una separazione. Poi il DNS, dove ispezionate il percorso reale del resolver invece del valore configurato, perché una risposta in cache o un’impostazione stampata non dice nulla su dove sia andata una nuova interrogazione.
Il comportamento in caso di guasto richiede un piano e un percorso di ripristino preservato. Osservate una nuova richiesta mentre il tunnel non è disponibile, e ricordate che una vecchia connessione aperta non è prova della politica di guasto. Il ciclo di vita viene per ultimo: ripetete l’osservazione dopo una riconnessione o un riavvio del servizio se questi eventi influenzano il requisito.
Registrate prove, non un verdetto
Per ogni risultato conservate il contesto del processo, la destinazione, la famiglia di indirizzi, l’ora e l’origine osservata. Quell’insieme è una prova circoscritta sui flussi che avete esercitato, ed è difendibile proprio perché dice cosa ha coperto.
Non è un audit dei registri dell’operatore VPN, né un certificato per ogni futura applicazione sul dispositivo.
Scrivete i limiti accanto al risultato. Un test che dichiara cosa non ha coperto sopravvive alla revisione, mentre uno che afferma che il dispositivo è verificato no. Tenete il manuale di curl accanto ai selettori di famiglia usati, e tenete la tabella a quattro righe insieme ai risultati.