TCP MSS -sovitus Linux IPsec -yhdyskäytävässä: mitä se korjaa

Ping toimii, SSH toimii, pieni sivu latautuu, ja sitten jokainen suuri vastaus jumittuu, kunnes aikakatkaisu tulee. Klassinen kuvio viittaa paketin kokoon eikä tavoitettavuuteen: polku kuljettaa kättelyn ja ensimmäiset kilotavut, minkä jälkeen täysikokoinen segmentti katoaa. Linux IPsec -yhdyskäytävässä TCP MSS -sääntö on usein korjaus, mutta vain jos ymmärrät, mitä se muuttaa ja missä paketti, johon se koskee, todella on. Alla oleva järjestys seuraa pakettia oireesta säännön sijoittamiseen, joten voit lopettaa heti, kun selitys lakkaa sopimasta.

Oire, joka viittaa MSS:ään

TCP neuvottelee kättelyssä suurimman segmentin koon. Jos tämä arvo on suurempi kuin minkä polku pystyy kuljettamaan kapseloinnin jälkeen, lähettäjä jatkaa segmenttien tuottamista, jotka eivät koskaan saavu, ja yhteys jumittuu ensimmäisen kierroksen jälkeen. Pienet vastaukset mahtuvat; suuret eivät.

ICMP-palaute voi pelastaa yhteyden polun MTU:n löytämisen kautta, ja palomuuri, joka pudottaa nämä viestit, muuttaa jumittumisen hiljaiseksi mustaksi aukoksi. Siksi sama tunneli toimii yhdelle sovellukselle ja epäonnistuu toiselle ilman mitään selvää eroa asetuksissa.

Mitä TCPMSS-sääntö tekee ja mitä ei

Sääntö kirjoittaa MSS-asetuksen uudelleen TCP:n kättelypaketeissa niiden kulkiessa. Se ei aseta tunnelin liitännän MTU:ta, ei muuta IPsec-käytäntöä, ja nykyisillä ytimillä se vain laskee ilmoitettua arvoa sen sijaan, että nostaisi jo pienempää. Se koskee myös vain TCP:tä; UDP-hyötykuormat, DNS:n käyttäytyminen ja neuvotellut liikenteen valitsimet ovat sen ulottumattomissa.

Koska muutos tapahtuu kättelyn aikana, ennen sääntöä muodostettu olemassa oleva yhteys säilyttää vanhan arvonsa. Testaa uudella yhteydellä ja odota, että muutoksen jälkeinen ensimmäinen yritys on se, joka kertoo jotain. Mikään säännössä ei tavoita yhteyttä, joka on jo auki. Siksi kesken tapahtuman tehty korjaus voi näyttää siltä, ettei se tehnyt yhtään mitään.

Sijoita sääntö sisemmälle TCP-polulle

Käytäntöpohjaisessa Linux-yhdyskäytävässä välitetty paketti näyttää palomuurille yhä tavalliselta TCP:ltä. IPsec-käytäntö päättää, että paketti suojataan; palomuuri ei näe sisemmälle virralle ESP-otsikkoa, joten ESP:hen yhdistäminen tässä kuvaa täysin eri pakettia. Tämä ristiriita on syy siihen, miksi jotkin säännöt näyttävät oikeilta eivätkä koskaan täsmää.

iptablesin termein sääntö kuuluu välityspolun mangle-tauluun, rajoitettuna kättelypaketteihin: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Luku on esimerkki, ei yleinen vakio; johda se kapseloinnin ylimääräisestä kuormasta ja polun todellisesta MTU:sta. nftables-vastine asettaa suurimman segmentin koon forward- tai postrouting-ketjussa.

Pidä IKE:n ja ESP:n ulommat kuuntelusäännöt erillään sisemmistä välityssäännöistä. Yksi sääntö, joka yrittää valtuuttaa sekä sovelluksen virran että ulomman protokollan, ei lopulta täsmää luotettavasti kumpaankaan.

Kunnioita palomuurin omistajaa ja NAT-järjestystä

Jos UFW omistaa isäntäkoneen palomuurin, lisää mangle- ja välitysmuutokset sen tuetun pysyvän asetusten kautta sen sijaan, että kirjoittaisit komennon, joka katoaa seuraavassa uudelleenlatauksessa. Väärään tauluun tai päätössäännön jälkeen lisätty sääntö ei vaikuta mihinkään, ja elävä taulu kätkee sen sinulta.

Lähteen käännös on erillinen päätös, joka usein vaikuttaa tähän. Yleisen masquerade-säännön eteen sijoitettu poikkeus estää suojattua liikennettä menettämästä lähdettä, jota sen käytäntö vaatii; se ei korjaa kokoon liittyvää ongelmaa, eikä kokosääntö korjaa käännökseen liittyvää ongelmaa.

Varmista kapeasti ja lopeta sitten

Avaa uusi yhteys epäonnistuvaan palveluun ja seuraa sekä sovellusta että säännön laskureita. Jos jumittuminen poistuu, sinulla on näyttöä kyseisestä TCP-polusta kyseisellä kapseloinnilla. Sinulla ei ole näyttöä siitä, että jokainen VPN-protokolla sopii, että jokainen UDP-sovellus on korjattu tai että tietty ylävirran palvelu oli alkuperäinen syy.

Jätä ICMP:n kokopalaute toimimaan siellä, missä käytäntö sallii, ja käsittele reitin MTU:hun perustuvaa automaattista rajoittamista varoen, kun ulompaa IPsec-polkua ei edusta sisempi reitti. Mitä kapeampi johtopäätös, sitä helpompi seuraava tapahtuma on diagnosoida.