Ajustament de MSS de TCP en una passarel·la Linux IPsec: què corregeix
Les peticions petites funcionen i les respostes grans s'encallen. Comproveu si una regla MSS al camí TCP interior és la solució correcta i on ha de viure.
El ping funciona, l'SSH funciona, una pàgina petita es carrega, i llavors cada resposta gran s'encalla fins que esgota el temps. El patró clàssic apunta a la mida del paquet i no a la connectivitat: el camí porta l'apretada de mans i els primers quants kilobytes, i després un segment de mida completa desapareix. En una passarel·la Linux IPsec, una regla TCP MSS sovint és la solució, però només si enteneu què canvia i on és realment el paquet que toca. L'ordre de sota segueix el paquet des del símptoma fins a la col·locació de la regla, de manera que podeu aturar-vos tan bon punt l'explicació deixi d'encaixar.
El símptoma que suggereix MSS
TCP negocia una mida màxima de segment a l'apretada de mans. Si aquest valor és més gran del que el camí pot portar després de l'encapsulament, l'emissor continua produint segments que no arriben mai, i la connexió s'encalla després del primer intercanvi. Les respostes petites hi caben; les grans no.
La retroalimentació ICMP pot rescatar la connexió mitjançant el descobriment de l'MTU del camí, i un tallafoc que descarta aquests missatges converteix l'encallament en un forat negre silenciós. Per això el mateix túnel funciona per a una aplicació i falla per a una altra sense cap diferència òbvia en la configuració.
Què fa una regla TCPMSS i què no fa
La regla reescriu l'opció MSS en els paquets de l'apretada de mans TCP mentre passen. No fixa l'MTU de la interfície del túnel, no canvia la política IPsec, i en els nuclis actuals només baixa un valor anunciat en lloc d'apujar-ne un que ja és més petit. També només toca TCP; les càrregues UDP, el comportament del DNS i els selectors de trànsit negociats queden fora del seu abast.
Com que el canvi passa durant l'apretada de mans, una connexió existent establerta abans de la regla conserva el valor antic. Proveu-ho amb una connexió nova, i espereu que el primer intent després del canvi sigui el que us diu alguna cosa. Res de la regla arriba a una connexió que ja és oberta. Per això una correcció aplicada enmig d'un incident pot semblar que no ha fet absolutament res.
Poseu la regla al camí TCP interior
En una passarel·la Linux basada en polítiques, el paquet reenviat encara sembla TCP corrent quan el tallafoc el veu. La política IPsec decideix que el paquet serà protegit; el tallafoc no veu cap capçalera ESP per al flux interior, així que comparar amb ESP aquí descriu un paquet completament diferent. Aquesta discrepància és el motiu pel qual algunes regles semblen correctes i no coincideixen mai.
En termes d'iptables, la regla pertany a la taula mangle al camí de reenviament, restringida als paquets de l'apretada de mans: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. El número és un exemple, no una constant universal; deriveu-lo del sobrecost de l'encapsulament i de l'MTU real del camí. Un equivalent d'nftables fixa la mida màxima de segment en una cadena forward o postrouting.
Manteniu les regles d'escolta exteriors per a IKE i ESP separades de les regles de reenviament interiors. Una sola regla que intenta autoritzar alhora el flux de l'aplicació i el protocol exterior acaba no coincidint de manera fiable amb cap dels dos.
Respecteu el propietari del tallafoc i l'ordre del NAT
Si UFW gestiona el tallafoc de l'amfitrió, afegiu els canvis de mangle i de reenviament mitjançant la seva configuració persistent compatible en lloc d'escriure una ordre que desapareix en la propera recàrrega. Una regla inserida a la taula equivocada o després d'una regla terminal no té cap efecte, i la taula activa us ho amaga.
La traducció d'origen és una decisió separada que sovint interactua amb aquesta. Una exempció col·locada abans d'una regla general de masquerade evita que el trànsit protegit perdi l'origen que la seva política requereix; no repara cap problema de mida, i una regla de mida no repara cap problema de traducció.
Verifiqueu de manera estreta, i després atureu-vos
Obriu una connexió nova al servei que falla i observeu tant l'aplicació com els comptadors de la regla. Si l'encallament desapareix, teniu proves sobre aquell camí TCP amb aquell encapsulament. No teniu proves que tots els protocols VPN hi encaixin, que cada aplicació UDP estigui arreglada o que un servei concret aigües amunt fos la causa original.
Deixeu que la retroalimentació de mida per ICMP continuï funcionant allà on la política ho permeti, i tracteu amb cura l'ajustament automàtic basat en l'MTU de la ruta quan el camí IPsec exterior no està representat per la ruta interior. Com més estreta sigui la conclusió, més fàcil serà diagnosticar el proper incident.