Ping attraverso una VPN: perché le regole di risposta eco mancano il percorso di ritorno

Fate ping verso un host attraverso una VPN e la richiesta esce con un tipo ICMP e torna con un altro, il che basta a confondere qualsiasi regola scritta in termini di porte. In uno scambio eco non esiste alcuna porta di servizio di destinazione da copiare nella regola di ritorno, e un filtro che si aspetta simmetria scarterà la risposta mentre la richiesta passa indisturbata. La correzione inizia leggendo il pacchetto così com’è realmente, poi decidendo quale confine del percorso prende la decisione. Di solito lavorano due livelli mentre il terzo scarta silenziosamente la risposta. Le sezioni seguenti li separano nell’ordine in cui un pacchetto li incontra.

Il pacchetto cambia tipo, non porta

Una richiesta eco è ICMP di tipo 8, codice 0, e porta un identificatore e un numero di sequenza. La risposta è di tipo 0, codice 0, con lo stesso identificatore e la stessa sequenza, e gli estremi IP invertiti. La RFC 792 definisce questi campi, e l’identificatore è ciò che consente a un mittente di abbinare le risposte alle proprie richieste.

Ciò che manca è altrettanto importante: non c’è intestazione TCP né UDP, quindi non c’è alcuna porta da consentire. Una regola che nomina una porta per una risposta eco descrive un pacchetto che non esisterà mai. È l’errore più comune nei ticket di ping VPN. La regola sembra specifica, non si applica a nulla e lascia il guasto esattamente dov’era.

Tre contesti decidono il pacchetto

Se il ping punta a un host della LAN remota, la richiesta deve essere inoltrata dal gateway. Se punta a un indirizzo che appartiene al gateway stesso, termina nel percorso di ingresso locale. Se è il gateway a originare il ping, il pacchetto parte nel proprio percorso di uscita e non attraversa affatto la decisione di inoltro.

Questi tre contesti hanno catene di regole e contatori diversi, e trattarli come uno solo è il motivo per cui «il firewall consente ICMP» può comunque produrre un ping fallito. Il tunnel esterno è un quarto contesto: consentire l’ascoltatore VPN non consente automaticamente la richiesta interna decapsulata, e un’autorizzazione interna non dice nulla sul fatto che il tunnel esterno sia attivo.

I filtri con stato e senza stato trattano la risposta in modo diverso

Un firewall con stato che ha visto uscire la richiesta può associare la risposta a quel flusso e ammetterla senza una seconda regola. Un filtro senza stato non ha tale memoria, quindi la direzione di ritorno ha bisogno della propria autorizzazione esplicita, con origine e destinazione invertite.

Verificate quale modello il prodotto implementa davvero prima di scrivere qualsiasi cosa. Una regola per la richiesta eco non copre necessariamente la risposta eco, e un prodotto che traccia le query ICMP può comunque applicare una politica diversa alle risposte che arrivano su un’altra interfaccia.

Limitate ciò che consentite. Consentire ogni risposta eco da qualunque luogo non equivale a completare un’associazione con stato, e un numero di tipo non autentica il mittente.

La traduzione cambia anche l’identificatore

Se la traduzione di origine è intenzionale, la tupla all’estremità remota non corrisponde a quella inviata dal client. Un NAT può tradurre l’identificatore della query ICMP insieme agli indirizzi, quindi insistere perché lo stesso numero compaia su entrambi i lati produce una discrepanza falsa.

Correlate invece la mappatura che il traduttore riporta. Un traduttore che riscrive l’identificatore non conserverà il numero che il vostro client ha registrato, quindi trattate la mappatura come identità e non il numero. Poi seguite una richiesta identificabile lungo il percorso: confermate che raggiunge la destinazione con l’origine attesa, confermate che la destinazione ha emesso una risposta, seguite il percorso di quella risposta al ritorno, e confermate che il client l’ha ricevuta invece di limitarvi a guardare un contatore del gateway salire.

Non fondete gli errori ICMP nella politica eco

Il messaggio «fragmentazione necessaria» usato dal rilevamento MTU del percorso non è una risposta eco, e il suo payload cita il pacchetto che l’ha innescato. Un’autorizzazione solo per l’eco che scarta in silenzio questi errori trasforma un problema di dimensione in una connessione bloccata, che è l’opposto di utile.

La stessa cautela vale per le famiglie di indirizzi. ICMPv6 usa tipi di messaggio diversi e porta funzioni essenziali che IPv4 non ha, quindi copiare questi numeri in una regola IPv6 è semplicemente sbagliato.

Quando lo scambio eco funziona, testate l’applicazione reale separatamente. Un ping riuscito dimostra l’andata e ritorno di un protocollo, a una dimensione e verso una destinazione, e non è una licenza per supporre che HTTPS, SMB o qualsiasi altro flusso sia consentito.