La vostra regola VPN per IPv4 non dice nulla sul traffico IPv6

Un controllo rileva che il tunnel è filtrato strettamente per IPv4 e completamente aperto per IPv6 sulla stessa interfaccia. Nulla era configurato male nel senso di un errore di battitura; l’insieme di regole descriveva semplicemente una famiglia e tutti presumevano che l’altra la seguisse. Raramente lo fa. Tre condizioni decidono se la vostra regola copre davvero entrambe, e la prima riguarda la piattaforma e non la politica.

Prima condizione: la piattaforma ha una tabella o due

Alcuni filtri di pacchetti tengono IPv4 e IPv6 in insiemi di regole completamente separati, così una regola aggiunta a uno non ha effetto sull’altro finché qualcuno non la duplica. Altri offrono una famiglia che corrisponde a entrambe e traduce gli indirizzi per pacchetto. Un terzo gruppo mantiene un solo linguaggio di politica ma conserva dietro oggetti separati per famiglia.

Leggete la documentazione del filtro che eseguite davvero, poi elencate quali tabelle esistono e quale ha toccato la vostra modifica. Contare le regole nella tabella IPv4 risponde a una domanda che nessuno ha posto. Poi elencate quali tabelle esistono e quale ha toccato la vostra modifica.

Seconda condizione: dove si applica la politica

Tre luoghi si confondono tra loro: il listener che accetta il tunnel, il percorso che inoltra il traffico e l’interfaccia ordinaria che il client usa quando il tunnel non trasporta un flusso. Un gateway può accettare una sessione mentre scarta tutto ciò che ne viene inoltrato, e questo sembra un tunnel rotto più che un filtro. Eliminate quella confusione prima di scrivere qualsiasi cosa, perché i tre luoghi hanno proprietari e registri diversi. Nominarli nel registro delle modifiche è ciò che impedisce a una correzione di atterrare uno strato più in là del guasto.

Annotate quale dei tre la vostra regola deve governare. Una regola che protegge il listener non protegge il percorso inoltrato, e nessuna delle due chiude la rotta diretta del client. Notate chi possiede ogni luogo, perché la risposta nella maggior parte delle organizzazioni è un altro team.

Terza condizione: cosa deve fare IPv6

Decidete se IPv6 passa attraverso il tunnel, viene bloccato finché la protezione non è disponibile, o segue un’eccezione documentata. Ogni risposta produce un insieme di regole diverso, e lasciare la domanda aperta è il modo in cui un client con IPv6 nativo finisce per raggiungere fuori dal tunnel destinazioni che raggiunge al suo interno via IPv4.

Dite la risposta ad alta voce prima di scrivere regole. Il blocco è una scelta legittima per un tunnel che non trasporta IPv6, purché sia deliberato e testato e non il risultato accidentale di una tabella vuota. Qualsiasi cosa non documentata verrà ridecisa da chi toccherà le regole dopo, e di solito in fretta.

ICMPv6 è traffico di controllo

La scoperta dei vicini e il feedback del percorso viaggiano entrambi su ICMPv6, quindi un blocco indiscriminato copiato da un’abitudine IPv4 rompe indirizzamento e trasferimenti grandi nello stesso momento. Anche un permesso indiscriminato non è la risposta, perché consegna un canale che nessuno guarda.

Seguite le indicazioni di filtraggio per i tipi di messaggio che contano e rifiutate il resto con un motivo. Il guasto diagnosticato male più spesso è un messaggio Packet Too Big mancante, che si manifesta come una connessione che si apre e poi si blocca.

Dimostrarlo, una famiglia alla volta

Provate una richiesta autorizzata su ciascuna famiglia separatamente, poi ripetete dopo una riconnessione se la politica deve sopravvivere alla sessione. Un test su una rete solo IPv4 non può esercitare una rotta IPv6, quindi il superamento non dice nulla sulla fuga che state cercando di chiudere. Guardate i contatori mentre il test è in corso, perché una regola che non corrisponde mai non fa ciò che il suo commento afferma.

Cambiate una regola circoscritta per tentativo e tenete a portata di mano la configurazione precedente. Dove un profilo gestito possiede la politica, coinvolgete il suo amministratore prima di modificare localmente, perché il controllo successivo sovrascriverà una correzione locale e ripristinerà la fuga.