TCP-MSS-aanpassing op 'n Linux-IPsec-gateway: wat dit regstel

Ping werk, SSH werk, 'n klein bladsy laai, en dan hang elke groot antwoord tot dit uit tyd loop. Die klassieke patroon dui op pakketgrootte eerder as bereikbaarheid: die pad dra die handdruk en die eerste paar kilobytes, dan verdwyn 'n segment van volle grootte. Op 'n Linux-IPsec-gateway is 'n TCP-MSS-reël dikwels die oplossing, maar net as jy verstaan wat dit verander en waar die pakket wat dit raak werklik is. Die volgorde hieronder volg die pakket van simptoom tot reëlplasing, sodat jy kan stop sodra die verduideliking nie meer pas nie.

Die simptoom wat op MSS dui

TCP onderhandel 'n maksimum segmentgrootte in die handdruk. As daardie waarde groter is as wat die pad ná inkapseling kan dra, bly die sender segmente produseer wat nooit aankom nie, en die verbinding staan ná die eerste heen-en-weer rit stil. Klein antwoorde pas; groot dié nie.

ICMP-terugvoer kan die verbinding deur pad-MTU-ontdekking red, en 'n firewall wat daardie boodskappe laat val, maak van die hanging 'n stille swart gat. Dis waarom dieselfde tonnel vir een toepassing werk en vir 'n ander faal sonder enige ooglopende verskil in die konfigurasie.

Wat 'n TCPMSS-reël doen en nie doen nie

Die reël herskryf die MSS-opsie in TCP-handdrukpakette terwyl hulle verbygaan. Dit stel nie die tonnelkoppelvlak se MTU nie, dit verander nie die IPsec-beleid nie, en op huidige kerne verlaag dit net 'n aangekondigde waarde eerder as om een wat al kleiner is te verhoog. Dit raak ook net TCP; UDP-nuttelvragte, DNS-gedrag en die onderhandelde verkeerskeuses val buite sy bereik.

Omdat die verandering tydens die handdruk gebeur, behou 'n bestaande verbinding wat voor die reël opgebou is sy ou waarde. Toets met 'n nuwe verbinding, en verwag dat die eerste poging ná die verandering die een is wat jou enigiets vertel. Niks in die reël bereik 'n verbinding wat al oop is nie. Dis waarom 'n regstelling wat midde-in 'n voorval toegepas word kan lyk of dit heeltemal niks gedoen het nie.

Plaas die reël op die binneste TCP-pad

Op 'n beleidsgebaseerde Linux-gateway lyk die deurgestuurde pakket nog steeds soos gewone TCP wanneer die firewall dit sien. Die IPsec-beleid besluit dat die pakket beskerm sal word; die firewall sien nie 'n ESP-kop vir die binneste vloei nie, so om hier op ESP te pas beskryf 'n heeltemal ander pakket. Daardie wanverhouding is waarom sommige reëls korrek lyk en nooit pas nie.

In iptables-terme hoort die reël in die mangle-tabel op die deurstuurpad, beperk tot handdrukpakette: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Die getal is 'n voorbeeld, nie 'n universele konstante nie; lei dit af uit die inkapseling-oorhoofse koste en die pad se werklike MTU. 'n nftables-ekwivalent stel die maksimum segmentgrootte in 'n forward- of postrouting-ketting.

Hou die buitenste luisteraarreëls vir IKE en ESP apart van die binneste deurstuurreëls. 'n Enkele reël wat probeer om beide die toepassingsvloei en die buitenste protokol te magtig, pas uiteindelik nie een betroubaar nie.

Respekteer die firewall se eienaar en die NAT-orde

As UFW die gasheer-firewall besit, voeg die mangle- en deurstuurveranderinge by deur sy ondersteunde blywende konfigurasie eerder as deur 'n opdrag te tik wat by die volgende herlaai verdwyn. 'n Reël wat in die verkeerde tabel of ná 'n terminale reël ingevoeg word, het geen effek nie, en die lewende tabel verberg dit vir jou.

Bronvertaling is 'n aparte besluit wat dikwels met hierdie een saamwerk. 'n Vrystelling wat voor 'n algemene masquerade-reël geplaas word, keer dat beskermde verkeer die bron verloor wat sy beleid vereis; dit herstel nie 'n grootteprobleem nie, en 'n grootttereël herstel nie 'n vertaalprobleem nie.

Verifieer eng, en stop dan

Maak 'n vars verbinding na die diens wat faal oop en kyk na beide die toepassing en die reëltellers. As die hanging opklaar, het jy bewyse oor daardie TCP-pad met daardie inkapseling. Jy het nie bewyse dat elke VPN-protokol pas nie, dat elke UDP-toepassing reggestel is nie, of dat 'n spesifieke stroomopdiens die oorspronklike oorsaak was nie.

Los ICMP-grootte-terugvoer aan die werk waar beleid dit toelaat, en hanteer outomatiese aanpassing op grond van roete-MTU met sorg wanneer die buitenste IPsec-pad nie deur die binneste roete verteenwoordig word nie. Hoe nouer die gevolgtrekking, hoe makliker is die volgende voorval om te diagnoseer.