TCP MSS-justering på en Linux IPsec-gateway: vad den åtgärdar

Ping fungerar, SSH fungerar, en liten sida laddas, och sedan hänger varje stort svar tills tiden tar slut. Det klassiska mönstret pekar på paketstorlek och inte på nåbarhet: vägen bär handskakningen och de första kilobyten, därefter försvinner ett segment i full storlek. På en Linux IPsec-gateway är en TCP MSS-regel ofta lösningen, men bara om du förstår vad den ändrar och var paketet den rör faktiskt finns. Ordningen nedan följer paketet från symtomet till regelns placering, så att du kan sluta så snart förklaringen inte längre passar.

Symtomet som tyder på MSS

TCP förhandlar en maximal segmentstorlek i handskakningen. Om det värdet är större än vad vägen kan bära efter inkapsling, fortsätter avsändaren att producera segment som aldrig kommer fram, och anslutningen hänger sig efter första rundan. Små svar får plats; stora inte.

ICMP-återkoppling kan rädda anslutningen genom upptäckt av vägens MTU, och en brandvägg som släpper dessa meddelanden gör hängningen till ett tyst svart hål. Därför fungerar samma tunnel för en applikation och misslyckas för en annan utan någon uppenbar skillnad i konfigurationen.

Vad en TCPMSS-regel gör och vad den inte gör

Regeln skriver om MSS-alternativet i TCP-handskakningspaket när de passerar. Den ställer inte in tunnelgränssnittets MTU, den ändrar inte IPsec-policyn, och på nuvarande kärnor sänker den bara ett annonserat värde i stället för att höja ett som redan är mindre. Den rör också bara TCP; UDP-nyttolaster, DNS-beteende och de förhandlade trafikväljarna ligger utanför dess räckvidd.

Eftersom ändringen sker under handskakningen behåller en befintlig anslutning som upprättades före regeln sitt gamla värde. Testa med en ny anslutning och förvänta dig att det första försöket efter ändringen är det som säger dig något. Ingenting i regeln når en anslutning som redan är öppen. Därför kan en rättelse som tillämpas mitt i en incident se ut som om den inte gjorde någonting alls.

Sätt regeln på den inre TCP-vägen

På en policybaserad Linux-gateway ser det vidarebefordrade paketet fortfarande ut som vanlig TCP när brandväggen ser det. IPsec-policyn avgör att paketet ska skyddas; brandväggen ser ingen ESP-rubrik för det inre flödet, så matchning på ESP här beskriver ett helt annat paket. Det missförhållandet är anledningen till att vissa regler ser korrekta ut och aldrig matchar.

I iptables-termer hör regeln till mangle-tabellen på vidarebefordringsvägen, begränsad till handskakningspaket: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Talet är ett exempel, inte en universell konstant; härled det från inkapslingskostnaden och vägens verkliga MTU. En nftables-motsvarighet ställer in den maximala segmentstorleken i en forward- eller postrouting-kedja.

Håll de yttre lyssnarreglerna för IKE och ESP åtskilda från de inre vidarebefordringsreglerna. En enda regel som försöker auktorisera både applikationens flöde och det yttre protokollet matchar till slut ingen av dem pålitligt.

Respektera brandväggens ägare och NAT-ordningen

Om UFW äger värdens brandvägg, lägg till mangle- och vidarebefordringsändringarna genom dess stödda beständiga konfiguration i stället för att skriva in ett kommando som försvinner vid nästa omladdning. En regel som infogas i fel tabell eller efter en terminal regel har ingen effekt, och den levande tabellen döljer det för dig.

Källöversättning är ett separat beslut som ofta samspelar med detta. Ett undantag placerat före en allmän masquerade-regel hindrar skyddad trafik från att förlora den källa som dess policy kräver; det reparerar inte ett storleksproblem, och en storleksregel reparerar inte ett översättningsproblem.

Verifiera snävt, och sluta sedan

Öppna en ny anslutning till tjänsten som misslyckas och följ både applikationen och regelns räknare. Om hängningen försvinner har du bevis om den TCP-vägen med den inkapslingen. Du har inte bevis för att varje VPN-protokoll passar, att varje UDP-applikation är åtgärdad eller att en viss uppströms tjänst var den ursprungliga orsaken.

Låt ICMP-storleksåterkoppling fungera där policyn tillåter det, och behandla automatisk justering baserad på rutens MTU försiktigt när den yttre IPsec-vägen inte representeras av den inre rutten. Ju snävare slutsatsen är, desto lättare är nästa incident att diagnostisera.