Il sovraccarico di IPsec: modalità, NAT-T e algoritmi lo cambiano
Un solo valore pubblicato di sovraccarico descrive un incapsulamento su un percorso. Sommate le intestazioni che il vostro tunnel negozia davvero, poi misurate il percorso.
Da qualche parte in una guida c’è un numero, di solito tra sessanta e ottanta byte, che qualcuno ha sottratto da 1500 per ottenere una MTU dell’interfaccia. Quel numero descrive un incapsulamento preciso su un percorso preciso. Cambiate la modalità, la famiglia di indirizzi esterna, la cifratura o la presenza di NAT, e l’aritmetica non vale più per il vostro tunnel.
Il numero veniva da un altro tunnel
Il sovraccarico non è una proprietà di IPsec in astratto. È una proprietà del pacchetto che viene realmente costruito: una modalità negoziata, un’intestazione esterna, un’intestazione di protezione, il riempimento, un campo di integrità e forse un ulteriore involucro UDP.
Un valore citato per la modalità trasporto con IPv4 e senza NAT descrive un pacchetto più piccolo della modalità tunnel con IPv6 sotto attraversamento NAT. Entrambi sono corretti per il proprio caso. Copiare l’uno o l’altro in una distribuzione diversa è il modo in cui la gente finisce con una MTU che rompe i trasferimenti grandi. Il guasto è silenzioso perché le richieste piccole continuano a funzionare.
Sommate gli strati che ci sono davvero
Partite dall’intestazione IP esterna e procedete verso l’interno. In modalità tunnel il pacchetto originale sta dentro, quindi l’intestazione esterna è un’aggiunta e non una sostituzione. RFC 4303 descrive l’intestazione ESP, il riempimento e i dati di integrità che la seguono.
| Layer | What it adds | When it applies |
|---|---|---|
| Outer IP header | 20 bytes for IPv4, 40 for IPv6 | Always, and 40 rather than 20 if the outer path is v6 |
| ESP header | 8 bytes of SPI and sequence number | Always |
| Block cipher IV | 8 to 16 bytes depending on the transform | When the negotiated cipher uses one |
| Padding and trailer | Padding to the block size, plus two trailer bytes | Always, and the amount varies with payload length |
| Integrity data | 12 to 16 bytes for common authenticated ciphers | When integrity protection is negotiated |
| UDP encapsulation | 8 bytes | NAT traversal on port 4500, which is common for clients behind NAT |
Nessuna di quelle righe è costante tra distribuzioni, e la riga del riempimento non è costante nemmeno all’interno di una sola distribuzione. È tutta questa la ragione per cui un solo valore pubblicato di sovraccarico delude.
Due sedi possono non essere d’accordo sullo stesso tunnel
Il pacchetto protetto deve comunque attraversare il percorso esterno, e il percorso esterno non è lo stesso ovunque. Un collegamento di accesso PPPoE porta meno di un segmento Ethernet pulito. Una rete mobile può restringersi ancora, e un provider che incapsula il proprio traffico aggiunge un altro incapsulamento che nessuno ha menzionato. Un tunnel che funziona su un collegamento e fallisce su un altro sta descrivendo il secondo collegamento, non il protocollo.
Anche le due direzioni possono differire. Una rotta asimmetrica può darvi un caricamento che funziona e uno scaricamento bloccato, il che si legge come un problema dell’applicazione finché non guardate le dimensioni dei pacchetti invece della raggiungibilità. Un ping piccolo che riesce dimostra molto poco su una risposta a dimensione piena.
Misurate invece di sottrarre
Trovate il datagramma più grande che sopravvive al percorso. Poi confrontatelo con il valore che l’interfaccia riporta:
ip link show eth0 | grep -o 'mtu [0-9]*' ip xfrm state list ping -M do -s 1400 198.51.100.7 ping -M do -s 1372 198.51.100.7 tcpdump -ni any -c 20 'esp or udp port 4500'
Scendete con la dimensione del ping finché arrivano risposte, e trattate il valore più grande che funziona come il budget per quel percorso. L’output di xfrm vi dice quale modalità e quali algoritmi sono stati negoziati, ed è l’input di qualsiasi calcolo onesto. La cattura conferma se sul filo c’è ESP o ESP incapsulato in UDP, e questo risolve la questione NAT senza indovinare.
Riservate un valore anche per il piano di controllo. I pacchetti di stretta di mano IKE hanno una struttura diversa da quella dei pacchetti dati, quindi una dimensione derivata da una cattura di stretta di mano non è una MTU del piano dati.
Mettete il numero dove deve stare
Per TCP attraverso un tunnel, un blocco MSS è spesso il controllo meno invasivo, perché riduce ciò che gli estremi inviano senza cambiare il tunnel stesso. Per un tunnel basato su rotte, impostate di proposito la MTU dell’interfaccia del tunnel e documentate perché. Fare entrambe le cose insieme e poi misurare non vi dice nulla su quale abbia aiutato.
Tenete insieme nel ticket la modalità negoziata, la famiglia esterna, la condizione NAT e il sintomo riproducibile. Un insieme registrato di quattro fatti batte una costante ricordata, ed è l’unica versione di questo che sopravvive al prossimo aggiornamento del client.