TCP-MSS-tilpasning på en Linux IPsec-gateway: hvad den løser

Ping virker, SSH virker, en lille side indlæses, og så hænger hvert stort svar, indtil det løber ud i en timeout. Det klassiske mønster peger på pakkestørrelse snarere end på rækkevidde: stien bærer håndtrykket og de første par kilobyte, derefter forsvinder et segment i fuld størrelse. På en Linux IPsec-gateway er en TCP-MSS-regel ofte løsningen, men kun hvis du forstår, hvad den ændrer, og hvor den pakke, den berører, faktisk befinder sig. Rækkefølgen nedenfor følger pakken fra symptom til regelplacering, så du kan stoppe, så snart forklaringen holder op med at passe.

Symptomet, der tyder på MSS

TCP forhandler en maksimal segmentstørrelse i håndtrykket. Hvis denne værdi er større, end stien kan bære efter indkapsling, bliver afsenderen ved med at producere segmenter, der aldrig ankommer, og forbindelsen hænger efter den første tur. Små svar passer; store gør ikke.

ICMP-tilbagemelding kan redde forbindelsen gennem opdagelse af stiens MTU, og en firewall, der dropper disse meddelelser, gør hænget til et stille sort hul. Derfor virker den samme tunnel til én applikation og fejler for en anden uden nogen tydelig forskel i konfigurationen.

Hvad en TCPMSS-regel gør, og hvad den ikke gør

Reglen omskriver MSS-indstillingen i TCP-håndtrykspakker, mens de passerer. Den sætter ikke tunnelinterfacet MTU, den ændrer ikke IPsec-politikken, og på nuværende kerner sænker den kun en annonceret værdi i stedet for at hæve en, der allerede er mindre. Den berører også kun TCP; UDP-nyttelaster, DNS-adfærd og de forhandlede trafikvælgere ligger uden for dens rækkevidde.

Fordi ændringen sker under håndtrykket, beholder en eksisterende forbindelse, der blev oprettet før reglen, sin gamle værdi. Test med en ny forbindelse, og forvent, at det første forsøg efter ændringen er det, der fortæller dig noget. Intet i reglen når en forbindelse, der allerede er åben. Derfor kan en rettelse, der anvendes midt i en hændelse, se ud, som om den slet ikke gjorde noget.

Sæt reglen på den indre TCP-sti

På en politikbaseret Linux-gateway ser den videresendte pakke stadig ud som almindelig TCP, når firewallen ser den. IPsec-politikken afgør, at pakken bliver beskyttet; firewallen ser ingen ESP-header for den indre strøm, så en match på ESP her beskriver en helt anden pakke. Den uoverensstemmelse er grunden til, at nogle regler ser korrekte ud og aldrig matcher.

I iptables-termer hører reglen til mangle-tabellen på videresendelsesstien, begrænset til håndtrykspakker: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Tallet er et eksempel, ikke en universel konstant; udled det af indkapslingsomkostningen og stiens reelle MTU. En nftables-ækvivalent sætter den maksimale segmentstørrelse i en forward- eller postrouting-kæde.

Hold de ydre lytteregler for IKE og ESP adskilt fra de indre videresendelsesregler. En enkelt regel, der forsøger at autorisere både applikationsstrømmen og den ydre protokol, ender med ikke at matche nogen af dem pålideligt.

Respekter firewallens ejer og NAT-rækkefølgen

Hvis UFW ejer værtens firewall, skal du tilføje mangle- og videresendelsesændringerne gennem dens understøttede permanente konfiguration i stedet for at skrive en kommando, der forsvinder ved næste genindlæsning. En regel, der indsættes i den forkerte tabel eller efter en terminal regel, har ingen effekt, og den levende tabel skjuler det for dig.

Kildeoversættelse er en separat beslutning, der ofte spiller sammen med denne. En undtagelse placeret før en generel masquerade-regel forhindrer, at beskyttet trafik mister den kilde, dens politik kræver; den reparerer ikke et størrelsesproblem, og en størrelsesregel reparerer ikke et oversættelsesproblem.

Verificer snævert, og stop så

Åbn en ny forbindelse til den fejlende tjeneste, og hold øje med både applikationen og reglens tællere. Hvis hænget forsvinder, har du bevis for den TCP-sti med den indkapsling. Du har ikke bevis for, at enhver VPN-protokol passer, at enhver UDP-applikation er rettet, eller at en bestemt opstrøms tjeneste var den oprindelige årsag.

Lad ICMP-størrelsestilbagemelding virke, hvor politikken tillader det, og behandl automatisk tilpasning baseret på rute-MTU med omhu, når den ydre IPsec-sti ikke repræsenteres af den indre rute. Jo snævrere konklusionen er, jo lettere er den næste hændelse at diagnosticere.