TCP MSS-justering på en Linux IPsec-gateway: hva den retter

Ping virker, SSH virker, en liten side lastes, og så henger hvert stort svar til tiden går ut. Det klassiske mønsteret peker på pakkestørrelse og ikke på tilgjengelighet: veien bærer håndtrykket og de første kilobytene, deretter forsvinner et segment i full størrelse. På en Linux IPsec-gateway er en TCP MSS-regel ofte løsningen, men bare hvis du forstår hva den endrer og hvor pakken den berører faktisk er. Rekkefølgen nedenfor følger pakken fra symptomet til plasseringen av regelen, slik at du kan stoppe så snart forklaringen slutter å passe.

Symptomet som tyder på MSS

TCP forhandler om en maksimal segmentstørrelse i håndtrykket. Hvis denne verdien er større enn det veien kan bære etter innkapsling, fortsetter avsenderen å produsere segmenter som aldri kommer frem, og forbindelsen henger etter den første runden. Små svar passer; store gjør det ikke.

ICMP-tilbakemelding kan redde forbindelsen gjennom oppdagelse av veiens MTU, og en brannmur som dropper disse meldingene gjør hengingen til et stille svart hull. Derfor virker den samme tunnelen for én applikasjon og feiler for en annen uten noen åpenbar forskjell i konfigurasjonen.

Hva en TCPMSS-regel gjør, og hva den ikke gjør

Regelen skriver om MSS-alternativet i TCP-håndtrykkspakker mens de passerer. Den setter ikke tunnelgrensesnittets MTU, den endrer ikke IPsec-policyen, og på nåværende kjerner senker den bare en annonsert verdi i stedet for å heve en som allerede er mindre. Den berører også bare TCP; UDP-nyttelaster, DNS-atferd og de forhandlede trafikkvelgerne ligger utenfor dens rekkevidde.

Fordi endringen skjer under håndtrykket, beholder en eksisterende forbindelse som ble opprettet før regelen, sin gamle verdi. Test med en ny forbindelse, og forvent at det første forsøket etter endringen er det som forteller deg noe. Ingenting i regelen når en forbindelse som allerede er åpen. Derfor kan en rettelse som brukes midt i en hendelse, se ut som om den ikke gjorde noe som helst.

Sett regelen på den indre TCP-veien

På en policybasert Linux-gateway ser den videresendte pakken fortsatt ut som vanlig TCP når brannmuren ser den. IPsec-policyen bestemmer at pakken skal beskyttes; brannmuren ser ingen ESP-header for den indre flyten, så matching på ESP her beskriver en helt annen pakke. Det misforholdet er grunnen til at noen regler ser riktige ut og aldri matcher.

I iptables-termer hører regelen til mangle-tabellen på videresendingsveien, begrenset til håndtrykkspakker: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Tallet er et eksempel, ikke en universell konstant; utled det fra innkapslingskostnaden og veiens reelle MTU. En nftables-ekvivalent setter den maksimale segmentstørrelsen i en forward- eller postrouting-kjede.

Hold de ytre lyttende reglene for IKE og ESP atskilt fra de indre videresendingsreglene. Én enkelt regel som prøver å autorisere både applikasjonsflyten og den ytre protokollen, ender med å ikke matche noen av dem pålitelig.

Respekter brannmurens eier og NAT-rekkefølgen

Hvis UFW eier vertens brannmur, legg til mangle- og videresendingsendringene gjennom dens støttede permanente konfigurasjon i stedet for å skrive inn en kommando som forsvinner ved neste innlasting. En regel som settes inn i feil tabell eller etter en terminal regel, har ingen effekt, og den levende tabellen skjuler det for deg.

Kildeoversettelse er en separat avgjørelse som ofte samspiller med denne. Et unntak plassert før en generell masquerade-regel hindrer beskyttet trafikk i å miste kilden som policyen krever; det reparerer ikke et størrelsesproblem, og en størrelsesregel reparerer ikke et oversettelsesproblem.

Verifiser snevert, og stopp så

Åpne en ny forbindelse til tjenesten som feiler, og følg med på både applikasjonen og regeltellerne. Hvis hengingen forsvinner, har du bevis om den TCP-veien med den innkapslingen. Du har ikke bevis for at enhver VPN-protokoll passer, at enhver UDP-applikasjon er rettet, eller at en bestemt oppstrøms tjeneste var den opprinnelige årsaken.

La ICMP-størrelsestilbakemelding virke der policyen tillater det, og behandle automatisk justering basert på rute-MTU med forsiktighet når den ytre IPsec-veien ikke er representert av den indre ruten. Jo snevrere konklusjonen er, jo lettere er den neste hendelsen å diagnostisere.