Portar un paquet intern fix de 1,500 bytes a través d’un VPN

Teniu un requisit que no es doblega: el costat remot ha de rebre el mateix paquet IP de 1,500 bytes que emet l’emissor, encapçalaments inclosos. Un túnel no pot embolcallar aquest paquet més el seu propi enquadrament dins d’un segon paquet IP de 1,500 bytes, així que alguna cosa del disseny ha de cedir. L’ordre següent és el que faig servir en una finestra de canvis: escriure el pressupost de bytes, demostrar què pot portar realment la xarxa subjacent, després triar exactament un mecanisme de transport i confirmar el paquet intern a l’altre costat.

Escriviu el pressupost de bytes abans d’editar un perfil

L’encapsulament afegeix bytes a diverses capes, i el total és una propietat del vostre perfil, no una constant que pugueu consultar. La família d’adreces, l’elecció de xifratge, el protocol de transport i qualsevol opció de compressió o enquadrament mouen el número, per això una resta copiada d’un altre desplegament no serveix com a pressupost. Comenceu pel requisit intern, afegiu la sobrecàrrega mesurada per paquet de la vostra configuració i escriviu la mida externa resultant al tiquet de canvi abans que ningú editi un fitxer.

Dos números decideixen el disseny: el paquet extern més gran que el camí porta sense fragmentació i els bytes addicionals que necessita el vostre encapsulament. Quan el primer és més petit que el segon més 1,500, un dels dos ha de canviar. L’elecció és llavors estreta i no creativa, per això escric tots dos números abans de parlar d’opcions. Res a la capa de túnel comprimeix aquests bytes i cap enter MTU elimina el requisit que us han donat.

Sondegeu la xarxa subjacent amb pings amb bit de no fragmentació

Mesureu el camí en lloc de confiar en la MTU de la interfície, perquè l’enllaç més petit del camí extern és el que importa. A Linux, -M do fixa el bit de no fragmentació i -s pren la càrrega ICMP, així que una trama de 1,500 bytes respon amb 1,472 bytes de càrrega un cop restats l’encapçalament IP de 20 bytes i l’encapçalament ICMP de 8 bytes. Pugeu la càrrega fins que la sonda falli i després salteu a una mida jumbo per veure si el camí la porta.

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

Un camí que passa 1,472 i falla a 8,972 no pot portar un paquet intern de 1,500 bytes més la sobrecàrrega en un sol paquet extern. Aquesta és la resposta que necessitàveu abans d’obrir la configuració del VPN. També decideix quin dels dos apartats següents us escau, així que guardeu els dos resultats de la sonda al costat del tiquet. Endevinar aquí costa una finestra de manteniment, perquè un túnel que es declara actiu no diu res sobre el paquet més gran que acceptarà el camí.

Apugeu la MTU del camí només on tots els salts hi estiguin d’acord

Les trames jumbo són una propietat d’extrem a extrem, no un paràmetre que activeu als dos extrems que controleu. Tots els commutadors, encaminadors i punts de lliurament del proveïdor al camí extern han d’acceptar la mida més gran, i un sol salt de 1,500 bytes descartarà silenciosament el paquet que acabeu d’engrandir. Apujar només la interfície local és el mig canvi clàssic que fa que el túnel sembli trencat mentre la xarxa subjacent deixa caure paquets en silenci.

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

Canvieu la interfície i torneu a sondar el mateix camí abans de canviar res més. Si la sonda encara falla, revertiu amb ip link set dev eth1 mtu 1500 i passeu a la fragmentació en lloc de discutir amb un proveïdor per un enllaç que no posseïu.

Useu la fragmentació del túnel quan la xarxa subjacent no pot créixer

Un mecanisme de fragmentació suportat per sota del paquet intern permet que diversos paquets externs portin un paquet intern, i l’extrem remot del túnel els reassembla abans de lliurar l’original a la pila. L’opció de fragmentació UDP de Community OpenVPN és una implementació d’aquesta idea i no és el mateix que la fragmentació IP ordinària del paquet extern. Tots dos parells han d’executar una versió que suporti el format, i el camí de dades ha de ser el que creieu: els clients OpenVPN 3 i els canals de dades accelerats al nucli tenen límits diferents, així que un perfil que funciona en un client pot fallar en un altre.

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

La fragmentació externa ordinària és l’altra opció i és la més feble. Els encaminadors IPv6 no fragmenten gens un paquet reenviat, així que un paquet extern massa gran simplement mor i l’emissor només ho sabrà si el missatge ICMPv6 corresponent sobreviu al camí. Els fragments també conviden al filtratge i a l’amplificació de pèrdues, per això ho tracto com un pla B i no com un pla.

Un portador extern basat en flux evita la qüestió de la mida segmentant el seu propi flux de bytes, i el paquet intern reconstruït pot seguir tenint 1,500 bytes. És una decisió de transport amb el seu propi cost, inclòs el conegut comportament de TCP dins de TCP, així que preneu-la deliberadament i no com a efecte secundari d’una discussió sobre MTU.

Confirmeu que el paquet intern arriba sense canvis

La verificació no és un handshake correcte. Captureu a la interfície del túnel als dos extrems i compareu la mida i el contingut del paquet que l’aplicació ha enviat realment amb el que ha rebut el costat remot.

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'

Si la captura mostra el paquet intern de mida completa a l’extrem remot, l’elecció de transport funciona i només queda enregistrar-la. Si no mostra res mentre el túnel es declara actiu, el paquet extern es descarta en algun punt entre els extrems, cosa que us torna a la sonda i no a la configuració del xifratge.

Enregistreu tres coses al tiquet abans de tancar-lo: el pressupost extern mesurat, el mecanisme que heu triat i l’ordre que va demostrar que el paquet intern va sobreviure. La propera persona que toqui aquest túnel necessitarà les tres, i cap no es pot reconstruir només a partir del fitxer de configuració.