TCP-MSS-aanpassing op een Linux IPsec-gateway: wat het oplost

Ping werkt, SSH werkt, een kleine pagina laadt, en dan blijft elk groot antwoord hangen tot de time-out. Het klassieke patroon wijst op pakketgrootte en niet op bereikbaarheid: het pad draagt de handshake en de eerste paar kilobyte, daarna verdwijnt een segment van volledige grootte. Op een Linux IPsec-gateway is een TCP-MSS-regel vaak de oplossing, maar alleen als je begrijpt wat die verandert en waar het pakket dat hij raakt werkelijk is. De volgorde hieronder volgt het pakket van symptoom tot regelplaatsing, zodat je kunt stoppen zodra de uitleg niet meer past.

Het symptoom dat op MSS wijst

TCP onderhandelt een maximale segmentgrootte in de handshake. Als die waarde groter is dan het pad na inkapseling kan dragen, blijft de afzender segmenten produceren die nooit aankomen, en de verbinding blijft hangen na de eerste ronde. Kleine antwoorden passen; grote niet.

ICMP-feedback kan de verbinding redden via het ontdekken van de MTU van het pad, en een firewall die die berichten dropt, maakt van het hangen een stil zwart gat. Daarom werkt dezelfde tunnel voor de ene toepassing en faalt hij voor de andere zonder enig duidelijk verschil in de configuratie.

Wat een TCPMSS-regel doet en wat niet

De regel herschrijft de MSS-optie in TCP-handshakepakketten terwijl ze passeren. Hij stelt niet de MTU van de tunnelinterface in, hij verandert het IPsec-beleid niet, en op huidige kernels verlaagt hij alleen een aangekondigde waarde in plaats van een al kleinere te verhogen. Hij raakt ook alleen TCP; UDP-payloads, DNS-gedrag en de onderhandelde verkeersselectors vallen buiten zijn bereik.

Omdat de wijziging tijdens de handshake plaatsvindt, behoudt een bestaande verbinding die vóór de regel tot stand kwam haar oude waarde. Test met een nieuwe verbinding, en verwacht dat de eerste poging na de wijziging degene is die je iets vertelt. Niets in de regel bereikt een verbinding die al open is. Daarom kan een oplossing die midden in een incident wordt toegepast, lijken alsof ze helemaal niets heeft gedaan.

Zet de regel op het interne TCP-pad

Op een beleidsgebaseerde Linux-gateway ziet het doorgestuurde pakket er voor de firewall nog steeds uit als gewoon TCP. Het IPsec-beleid bepaalt dat het pakket beschermd wordt; de firewall ziet geen ESP-header voor de interne stroom, dus overeenkomen met ESP beschrijft hier een heel ander pakket. Die mismatch is de reden dat sommige regels correct lijken en nooit overeenkomen.

In iptables-termen hoort de regel in de mangle-tabel op het doorstuurpad, beperkt tot handshakepakketten: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Het getal is een voorbeeld, geen universele constante; leid het af uit de inkapselingskosten en de werkelijke MTU van het pad. Een nftables-equivalent stelt de maximale segmentgrootte in een forward- of postrouting-keten in.

Houd de buitenste luisterregels voor IKE en ESP gescheiden van de interne doorstuurregels. Eén regel die zowel de stroom van de toepassing als het buitenste protocol probeert te autoriseren, komt uiteindelijk met geen van beide betrouwbaar overeen.

Respecteer de eigenaar van de firewall en de NAT-volgorde

Als UFW de firewall van de host beheert, voeg de mangle- en doorstuurwijzigingen dan toe via de ondersteunde permanente configuratie in plaats van een opdracht te typen die bij de volgende herlaadbeurt verdwijnt. Een regel die in de verkeerde tabel of na een terminale regel wordt ingevoegd, heeft geen effect, en de live tabel verbergt dat voor je.

Bronvertaling is een aparte beslissing die vaak met deze samenhangt. Een uitzondering vóór een algemene masquerade-regel voorkomt dat beschermd verkeer de bron verliest die zijn beleid vereist; ze repareert geen grootteprobleem, en een regel voor de grootte repareert geen vertaalprobleem.

Verifieer nauw, en stop dan

Open een nieuwe verbinding naar de falende dienst en volg zowel de toepassing als de tellers van de regel. Als het hangen verdwijnt, heb je bewijs over dat TCP-pad met die inkapseling. Je hebt geen bewijs dat elk VPN-protocol past, dat elke UDP-toepassing is opgelost of dat een specifieke upstreamdienst de oorspronkelijke oorzaak was.

Laat ICMP-groottefeedback werken waar het beleid dat toestaat, en behandel automatische aanpassing op basis van de MTU van de route voorzichtig wanneer het buitenste IPsec-pad niet door de interne route wordt vertegenwoordigd. Hoe smaller de conclusie, hoe makkelijker het volgende incident te diagnosticeren is.