TCP MSS-i piiramine Linuxi IPsec-lüüsil: mida see parandab

Ping töötab, SSH töötab, väike leht laaditakse, ja siis jääb iga suur vastus kinni, kuni aegub. Klassikaline muster viitab paketi suurusele, mitte kättesaadavusele: tee kannab kätlust ja esimesi kilobaite, seejärel kaob täissuuruses segment. Linuxi IPsec-lüüsil on TCP MSS-i reegel sageli lahendus, kuid ainult siis, kui mõistate, mida see muudab ja kus pakett, mida see puudutab, tegelikult asub. Allpool järgib järjekord paketti sümptomist reegli paigutuseni, nii et saate peatuda niipea, kui seletus enam ei sobi.

Sümptom, mis viitab MSS-ile

TCP lepib kätluses kokku maksimaalse segmendi suuruse. Kui see väärtus on suurem kui tee suudab pärast kapseldamist kanda, jätkab saatja segmentide tootmist, mis kunagi kohale ei jõua, ja ühendus jääb pärast esimest ringi kinni. Väikesed vastused mahuvad; suured mitte.

ICMP tagasiside võib ühenduse tee-MTU avastamise kaudu päästa, ja tulemüür, mis need sõnumid ära viskab, muudab kinnijäämise vaikseks mustaks auguks. Seetõttu töötab sama tunnel ühe rakenduse jaoks ja ebaõnnestub teise jaoks ilma nähtava erinevuseta konfiguratsioonis.

Mida TCPMSS-reegel teeb ja mida mitte

Reegel kirjutab MSS-valiku TCP kätluspakettides ümber nende möödumisel. See ei määra tunneliliidese MTU-d, ei muuda IPsec-poliitikat ja praegustel tuumadel ainult langetab teatatud väärtust, selle asemel et tõsta juba väiksemat. See puudutab ka ainult TCP-d; UDP kasulik koormus, DNS-i käitumine ja kokku lepitud liiklusvalijad jäävad selle haardeulatusest välja.

Kuna muudatus toimub kätluse ajal, säilitab enne reeglit loodud olemasolev ühendus oma vana väärtuse. Testige uue ühendusega ja oodake, et muudatusele järgnev esimene katse on see, mis teile midagi ütleb. Miski reeglis ei jõua ühenduseni, mis on juba avatud. Seetõttu võib juhtumi keskel rakendatud parandus näida, nagu poleks see üldse midagi teinud.

Pange reegel sisemisele TCP-teele

Poliitikapõhisel Linuxi lüüsil näeb edastatud pakett tulemüüri jaoks endiselt välja nagu tavaline TCP. IPsec-poliitika otsustab, et pakett on kaitstud; tulemüür ei näe sisemise voolu jaoks ESP-päist, seega ESP-ga sobitamine kirjeldab siin hoopis teist paketti. Just see lahknevus on põhjus, miks mõned reeglid tunduvad õiged ja ei sobi kunagi.

iptablesi terminites kuulub reegel edastustee mangle-tabelisse, piiratud kätluspakettidega: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Arv on näide, mitte universaalne konstant; tuletage see kapseldamise kulust ja tee tegelikust MTU-st. nftablesi ekvivalent määrab maksimaalse segmendi suuruse forward- või postrouting-ahelas.

Hoidke IKE ja ESP välised kuulamisreeglid sisemistest edastusreeglitest eraldi. Üks reegel, mis üritab autoriseerida nii rakenduse voolu kui ka välist protokolli, ei sobi lõpuks usaldusväärselt kummagagi.

Austage tulemüüri omanikku ja NAT-i järjekorda

Kui UFW omab hosti tulemüüri, lisage mangle- ja edastusmuudatused selle toetatud püsiva konfiguratsiooni kaudu, mitte kirjutades käsku, mis järgmisel uuestilaadimisel kaob. Valesse tabelisse või lõpliku reegli järele sisestatud reeglil pole mõju, ja aktiivne tabel varjab seda teie eest.

Lähtekoodi tõlkimine on eraldi otsus, mis sageli sellega koostoimib. Üldise masquerade-reegli ette paigutatud erand hoiab ära, et kaitstud liiklus kaotaks allika, mida selle poliitika nõuab; see ei paranda suuruse probleemi ja suuruse reegel ei paranda tõlkimise probleemi.

Kontrollige kitsalt, siis lõpetage

Avage nurjuvale teenusele värske ühendus ja jälgige nii rakendust kui ka reegli loendureid. Kui kinnijäämine kaob, on teil tõend selle TCP-tee kohta selle kapseldamisega. Teil pole tõendit, et iga VPN-protokoll sobib, et iga UDP-rakendus on parandatud või et konkreetne ülesvoolu teenus oli algne põhjus.

Laske ICMP suuruse tagasisidel töötada seal, kus poliitika lubab, ja suhtuge ettevaatlikult marsruudi MTU-l põhinevasse automaatsesse piiramisse, kui välist IPsec-teed ei esinda sisemine marsruut. Mida kitsam on järeldus, seda kergem on järgmist juhtumit diagnoosida.