Túnels VPN imbricats: per què l’interior s’encalla amb paquets grans

El DNS es resol, la sessió SSH es manté, i llavors una pujada gran es bloqueja mentre un ping al mateix amfitrió encara respon. Aquesta divisió apunta a la mida del paquet més que a un túnel espatllat. Els túnels imbricats hi arriben a mides que cap dels dos túnels no assoliria sol. La sessió interior està bé; el que passa és que se li lliuren paquets que ja no hi caben.

On va realment l’MTU del camí

Cada encapsulació gasta bytes abans que la capa següent tingui el seu torn. Un camí Ethernet ofereix 1500 bytes al paquet exterior, i el túnel exterior pren la seva part abans que res a dins es pugui adreçar. Un sol valor estimat de sobrecàrrega serà incorrecte exactament en la quantitat que importa.

Enumereu les capes per ordre: camí d’accés, transport exterior, túnel exterior, transport interior, túnel interior, aplicació. Compteu cada capçalera una vegada, i manteniu l’UDP separat de la capçalera i l’etiqueta pròpies del túnel.

Dues capes de WireGuard, comptades una vegada

Preneu un camí d’accés IPv4 amb un túnel WireGuard dins d’un altre. La capa exterior costa 20 bytes d’IPv4, 8 d’UDP i 32 per a la capçalera de dades de WireGuard més la seva etiqueta d’autenticació. A dins, el túnel interior necessita la seva pròpia capçalera IPv4 de 20 bytes i una capçalera UDP de 8 bytes abans dels seus segons 32 bytes de sobrecàrrega de WireGuard. El que queda conté una capçalera IPv4, una capçalera TCP i les dades. Un camí exterior IPv6 costa 40 en lloc de 20 i en deixa 1320.

L’aritmètica acaba en 1340 bytes. Una sola capa amb les mateixes regles en deixa 1400 per a la càrrega útil TCP, que és 1500 menys 20, 8, 32, 20 i 20, i la diferència de 60 bytes és exactament l’encapsulació interior que afegeix el segon túnel.

Apliqueu 1400 a un camí imbricat i el túnel interior queda 60 bytes curt, invisible fins que un paquet és prou gran per necessitar-los. El farciment i l’opció de fragmentació pròpia del protocol tornen a moure les xifres, així que confieu en la taula.

MTU, MSS i fragmentació actuen en llocs diferents

L’MTU de la interfície limita què emetrà la interfície, mentre que el clamping d’MSS de TCP canvia què està disposat a enviar un parell TCP. El clamping arregla les sessions TCP i no fa res per a un datagrama UDP gran, que és com una solució sembla reeixida per a una aplicació i falla en silenci per a la següent. L’opció de fragmentació pròpia del protocol és una tercera palanca amb els seus propis fracassos. L’MTU de la interfície és el primer moviment habitual i el més contundent.

Els túnels amb pont i els encaminats porten trames diferents, així que les xifres d’un altre desplegament poques vegades es transfereixen. El descobriment d’MTU del camí, descrit a RFC 8201, només ajuda mentre es deixen passar els missatges ICMP dels quals depèn.

Trobar la capa que queda curta

Verifiqueu cada túnel per separat abans d’imbricar-los, si els requisits permeten una comparació. Una sonda de mida fixa ho resol: ping -M do -s 1472 -c 3 10.8.0.1 envia un paquet IPv4 complet de 1500 bytes dins d’aquella capa. Afegiu la segona capa i repetiu la mateixa sonda, perquè qualsevol fallada pertanyi a un canvi conegut.

Quan una transferència s’encalla, canvieu un paràmetre documentat alhora i anoteu la mida que falla. Comproveu també el camí de tornada, perquè la recursió imbricada de rutes pot imitar un problema de mida de paquet prou bé per costar una tarda. Una resposta ICMP filtrada pot amagar el límit real, així que la sonda importa més que el raonament.

Escriviu el pressupost on el trobarà la propera persona

Una taula amb una fila per capa sobreviu a una regla mnemotècnica. Tingueu-la al costat del diagrama del túnel perquè ningú no refaci l’aritmètica sota pressió.

Més túnels volen dir més dependències, així que un pla de reversió es guanya el seu lloc al costat del pressupost. Si les xifres encara no quadren, mesureu el camí en lloc de tornar a endevinar. L’objectiu és una xifra que pugueu defensar, no recordar.