IPIP dentro de WireGuard: os 20 bytes extra que ninguén orzamentou

Os pings pequenos cruzan o túnel todo o día, chega o banner SSH e despois a sesión conxélase no momento en que comeza unha transferencia de ficheiros. Ese patrón apunta a un orzamento de bytes contado na capa equivocada, onde o túnel exterior se dimensionou para o seu propio sobrecusto e ninguén restou o interior. Un paquete IPIP aniñado é só outro paquete IP para WireGuard, e por iso mesmo consume bytes que nunca reservou. A corrección é aritmética, e cabe en tres ordes e unha táboa.

O síntoma que o delata

Os problemas de fragmentación anúncianse polo tamaño, nunca polos enderezos. O seu par responde a un ping de 56 bytes durante unha hora e despois cala a 1400 bytes mentres o túnel segue levantado e ningunha ruta cambiou. O aperto de mans cabe, a primeira ventá TCP completa non, e a transferencia atasca segundos despois de parecer san.

Mida o teito antes de editar nada, porque un teito sen medir é un que perseguirá dúas veces. Envíe unha sonda por baixo do tamaño sospeitoso co bit do-not-fragment activado, ping -M do -s 1000 10.9.0.2, e repítaa despois cun tamaño que xa sabe que é demasiado grande. Cando o envorco segue o tamaño da carga útil mentres o destino non cambia, o encamiñamento fai o seu traballo e falta unha cabeceira no orzamento.

Conte cada cabeceira unha vez, na capa correcta

Parta do MTU máis pequeno do camiño e non da interface do túnel, porque o muro está por riba de ambos extremos. WireGuard gasta 60 bytes nun transporte exterior IPv4: 20 para IP, 8 para UDP e 32 para a súa propia cabeceira, e 80 bytes cando ese transporte é IPv6. Un wg0 de 1420 bytes garda 20 bytes de marxe baixo os 1440 que un camiño de 1500 bytes pode entregar de verdade, e por iso a cifra copiada dunha wiki segue encaixando aquí. Debuxe toda a pila no diagrama, porque quen cambie o MTU despois elixirá se non un número redondo novo e herdará o seu erro.

A quinta fila é onde fallan os orzamentos, porque os 1400 bytes que leva unha interface aniñada xa inclúen os 40 bytes de cabeceiras do paquete orixinal. Só 1360 deses bytes chegan ao proceso que le o ficheiro. Trate 1400 como carga útil da aplicación, como lle invita a facer calquera diagrama sen esa columna, e o dispositivo interior acaba 40 bytes demasiado xeneroso contra un muro que non se moveu.

Fixe os dous MTU por separado

O portador e o dispositivo aniñado son obxectos separados, así que cada un necesita o seu propio valor. Aplíqueos nesta orde, porque o dispositivo aniñado non herda nada do portador:

ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400

A regra que paga a pena memorizar: MTU interior = MTU exterior - 20 cando o paquete que leva o túnel IPIP é IPv4, e - 40 en canto calquera lado do paquete interior é IPv6, porque a cabeceira aniñada medra de 20 bytes a 40. Nada máis pertence a esa resta. O sobrecusto de WireGuard xa se gastou cando elixiu 1420, e cobralo dúas veces produce un túnel que funciona perfectamente e queda lento mentres ninguén o mida. Un despregamento no que ambos dispositivos levan un 1400 redondo é a pegada exacta dese erro.

IPv6 en calquera dos lados do paquete aniñado invalida cada cifra anterior, así que recalcule en lugar de copiar un número dun sitio parecido. As cabeceiras restadas son de 40 bytes cada unha en canto IPv6 aparece no camiño exterior ou no datagrama orixinal, e a cifra de carga útil baixa exactamente outro tanto.

A regra de cortalumes que probablemente non necesita

Entre dous pares de WireGuard o único que hai no cable é UDP, así que unha regra de entrada para o protocolo 4, o número que RFC 2003 asigna á encapsulación IPv4-dentro-de-IPv4, nin crea o camiño aniñado nin o mantén vivo. A cabeceira IPIP vive dentro da carga útil cifrada, onde ningún cortalumes de bordo a ve. Abrir o protocolo 4 de todos os xeitos non compra nada máis alá dunha vía permitida máis cara ao host.

A política que menciona as fontes e destinos do paquete orixinal pertence despois da desencapsulación, nas interfaces do túnel e na táboa de encamiñamento. Póñaas alí e a regra de bordo pode quedar pechada.

Que valida realmente WireGuard

AllowedIPs xulga a orixe do paquete que WireGuard transporta, e o que transporta é o paquete encapsulado en IPIP. Unha orixe IPIP permitida acéptase mesmo cando a cabeceira interior nomea un host que preferiría non encamiñar. A orixe orixinal, por tanto, non é o que o par comprobou por vostede, e ese par interior de enderezos necesita a súa propia aplicación despois da desencapsulación.

O envoltorio achega estrutura de encamiñamento, non unha segunda capa de criptografía. Chamar a IPIP protección extra dentro de WireGuard describe un deseño distinto.

Verifique cunha escaleira, non cun só ping

Sondee tamaños que rodeen a fronteira que calculou e logo confirme que cre o núcleo sobre ambos dispositivos. Con 1360 bytes de carga útil máis 40 bytes de cabeceiras que fan 1400, o primeiro eco de abaixo cabe e o segundo sitúase un byte máis alá do teito:

ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0

Un paso limpo por baixo do teito e un fallo no primeiro tamaño por riba significan que a aritmética se sostén de extremo a extremo. Despois volva executar a transferencia que orixinalmente se atascou, porque unha sonda sintética demostra o orzamento e non di nada sobre os tamaños de escritura do remitente. Se o camiño aniñado aínda se rompe cun tamaño que vostede demostrou que cabe, inspeccione a desencapsulación e as rutas do extremo afastado antes de recortar dez bytes máis do MTU.