Transportar un paquete interno fixo de 1,500 bytes a través dunha VPN

Ten un requisito que non se dobra: o lado remoto debe recibir o mesmo paquete IP de 1,500 bytes que emite o emisor, cabeceiras incluídas. Un túnel non pode envolver ese paquete máis o seu propio entramado dentro dun segundo paquete IP de 1,500 bytes, así que algo do deseño ten que ceder. A orde de abaixo é a que uso nunha xanela de cambios: escribir o orzamento de bytes, demostrar que pode transportar realmente a rede subxacente, despois elixir exactamente un mecanismo de transporte e confirmar o paquete interno no lado remoto.

Escriba o orzamento de bytes antes de editar un perfil

A encapsulación engade bytes en varias capas, e o total é unha propiedade do seu perfil e non unha constante que poida consultar. A familia de enderezos, a elección de cifrado, o protocolo de transporte e calquera opción de compresión ou entramado moven a cifra, por iso unha resta copiada doutro despregamento non serve como orzamento. Comece polo requisito interno, sume a sobrecarga medida por paquete da súa propia configuración e escriba o tamaño externo resultante no tícket de cambio antes de que ninguén edite un ficheiro.

Dous números deciden o deseño: o paquete externo máis grande que a ruta transporta sen fragmentación e os bytes adicionais que necesita a súa encapsulación. Cando o primeiro é menor que o segundo máis 1,500, un dos dous ten que cambiar. A elección é entón estreita e non creativa, por iso anoto ambos os números antes de falar de opcións. Nada na capa de túnel comprime eses bytes e ningún enteiro de MTU elimina o requisito que lle deron.

Sondee a rede subxacente con pings co bit de non fragmentar

Mida a ruta en lugar de confiar na MTU da interface, porque o enlace máis pequeno do camiño externo é o que importa. En Linux, -M do fixa o bit de non fragmentar e -s toma a carga ICMP, así que unha trama de 1,500 bytes responde con 1,472 bytes de carga unha vez restadas a cabeceira IP de 20 bytes e a cabeceira ICMP de 8 bytes. Suba a carga ata que a sonda falle e despois salte a un tamaño jumbo para ver se a ruta o transporta.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

Unha ruta que pasa 1,472 e falla a 8,972 non pode transportar un paquete interno de 1,500 bytes máis a sobrecarga nun só paquete externo. Esa é a resposta que necesitaba antes de abrir a configuración do VPN. Tamén decide cal dos dous apartados seguintes se lle aplica, así que garde os dous resultados da sonda xunto ao tícket. Adiviñar aquí custa unha xanela de mantemento, porque un túnel que se declara activo non di nada sobre o paquete máis grande que aceptará a ruta.

Suba a MTU da ruta só onde todos os saltos estean de acordo

As tramas jumbo son unha propiedade de extremo a extremo, non un axuste que active nos dous extremos que controla. Todos os conmutadores, encamiñadores e entregas do provedor no camiño externo deben aceptar o tamaño maior, e un só salto de 1,500 bytes descartará en silencio o paquete que acaba de agrandar. Subir só a interface local é o medio cambio clásico que fai que o túnel pareza roto mentres a rede subxacente descarta sen avisar.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

Cambie a interface e volva sondar a mesma ruta antes de cambiar calquera outra cousa. Se a sonda segue fallando, reverta con ip link set dev eth1 mtu 1500 e pase á fragmentación en lugar de discutir cun provedor por un enlace que non posúe.

Use a fragmentación do túnel cando a rede subxacente non poida crecer

Un mecanismo de fragmentación admitido por baixo do paquete interno permite que varios paquetes externos transporten un paquete interno, e o extremo remoto do túnel reensámblaos antes de entregar o orixinal á pila. A opción de fragmentación UDP de Community OpenVPN é unha implementación desa idea e non é o mesmo que a fragmentación IP ordinaria do paquete externo. Ambos os pares deben executar unha versión que admita o formato, e a ruta de datos debe ser a que vostede cre: os clientes de OpenVPN 3 e as canles de datos aceleradas no núcleo teñen límites distintos, así que un perfil que funciona nun cliente pode fallar noutro.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

A fragmentación externa ordinaria é a outra opción e é a máis feble. Os encamiñadores IPv6 non fragmentan en absoluto un paquete reenviado, así que un paquete externo sobredimensionado simplemente morre e o emisor só o sabe se a mensaxe ICMPv6 correspondente sobrevive á ruta. Os fragmentos tamén invitan á filtraxe e á amplificación de perdas, por iso o trato como un plan B e non como un plan.

Un portador externo baseado en fluxo evita a cuestión do tamaño segmentando o seu propio fluxo de bytes, e o paquete interno reconstruído pode seguir a ser de 1,500 bytes. É unha decisión de transporte con custo propio, incluído o coñecido comportamento de TCP dentro de TCP, así que tómea deliberadamente e non como efecto secundario dunha discusión sobre MTU.

Confirme que o paquete interno chega sen cambios

A verificación non é unha aperta de mans correcta. Capture na interface do túnel nos dous extremos e compare o tamaño e o contido do paquete que a aplicación enviou realmente co que recibiu o lado remoto.

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

Se a captura mostra o paquete interno de tamaño completo no extremo remoto, a elección de transporte funciona e só queda rexistrala. Se non mostra nada mentres o túnel se declara activo, o paquete externo descártase nalgún punto entre os extremos, o que lle devolve á sonda e non aos axustes de cifrado.

Rexiste tres cousas no tícket antes de pechalo: o orzamento externo medido, o mecanismo que elixiu e a orde que demostrou que o paquete interno sobreviviu. A seguinte persoa que toque este túnel necesitará as tres, e ningunha pode reconstruírse só co ficheiro de configuración.