TCP MSS szabályozás Linux IPsec átjárón: mit javít meg

A ping működik, az SSH működik, egy kis oldal betöltődik, aztán minden nagy válasz elakad, amíg le nem jár az idő. A klasszikus minta a csomagméretre utal, nem az elérhetőségre: az útvonal viszi a kézfogást és az első néhány kilobájtot, aztán egy teljes méretű szegmens eltűnik. Egy Linux IPsec átjárón a TCP MSS szabály gyakran a megoldás, de csak akkor, ha érti, mit változtat meg, és hol van valójában az a csomag, amelyet megérint. Az alábbi sorrend a tünetektől a szabály elhelyezéséig követi a csomagot, így abbahagyhatja, amint a magyarázat már nem illik.

A tünet, amely MSS-re utal

A TCP a kézfogásban egy maximális szegmensméretet tárgyal meg. Ha ez az érték nagyobb annál, mint amit az útvonal a beágyazás után el tud vinni, a küldő továbbra is olyan szegmenseket állít elő, amelyek soha nem érkeznek meg, és a kapcsolat az első kör után elakad. A kis válaszok beférnek; a nagyok nem.

Az ICMP-visszajelzés megmentheti a kapcsolatot az útvonal MTU-jának felderítésével, és az a tűzfal, amely eldobja ezeket az üzeneteket, csendes fekete lyukká teszi az elakadást. Ezért működik ugyanaz az alagút az egyik alkalmazásnál, és hiúsul meg a másiknál minden látható különbség nélkül a beállításokban.

Mit tesz meg a TCPMSS szabály, és mit nem

A szabály átírja az MSS-beállítást a TCP kézfogási csomagokban, miközben azok áthaladnak. Nem állítja be az alagút interfészének MTU-ját, nem változtatja meg az IPsec-házirendet, és a jelenlegi kerneleken csak csökkenti egy meghirdetett értéket ahelyett, hogy növelne egy már kisebbet. Ráadásul csak a TCP-t érinti; az UDP-terhek, a DNS viselkedése és a megtárgyalt forgalomszelektorok az elérésén kívül esnek.

Mivel a változás a kézfogás alatt történik, a szabály előtt létrehozott meglévő kapcsolat megtartja régi értékét. Teszteljen új kapcsolattal, és számítson arra, hogy a változtatás utáni első próbálkozás lesz az, amely mond valamit. Semmi a szabályban nem ér el egy már nyitott kapcsolatot. Ezért tűnhet úgy egy incidens közepén alkalmazott javítás, mintha egyáltalán semmit sem tett volna.

Tegye a szabályt a belső TCP útvonalra

Egy házirend-alapú Linux átjárón az átadott csomag még mindig közönséges TCP-nek látszik, amikor a tűzfal látja. Az IPsec-házirend dönti el, hogy a csomag védett lesz; a tűzfal nem lát ESP-fejlécet a belső folyamhoz, ezért az ESP-vel való egyeztetés itt teljesen más csomagot ír le. Ez az eltérés az oka annak, hogy egyes szabályok helyesnek tűnnek, és soha nem egyeznek.

Az iptables fogalmaival a szabály a továbbítási útvonal mangle táblájába tartozik, a kézfogási csomagokra korlátozva: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. A szám példa, nem egyetemes állandó; vezesse le a beágyazás többletköltségéből és az útvonal valódi MTU-jából. Az nftables megfelelője a maximális szegmensméretet egy forward vagy postrouting láncban állítja be.

Tartsa az IKE és ESP külső figyelő szabályait külön a belső továbbítási szabályoktól. Egyetlen szabály, amely egyszerre próbálja engedélyezni az alkalmazás folyamát és a külső protokollt, végül egyikkel sem egyezik megbízhatóan.

Tisztelje a tűzfal tulajdonosát és a NAT sorrendjét

Ha az UFW birtokolja a gazdagép tűzfalát, a mangle és továbbítási változtatásokat a támogatott állandó konfigurációján keresztül adja hozzá, ne pedig egy parancsot gépeljen be, amely a következő újratöltéskor eltűnik. A rossz táblába vagy egy lezáró szabály után beszúrt szabály semmilyen hatással nem jár, és az élő tábla ezt elrejti Ön elől.

A forrásfordítás külön döntés, amely gyakran kölcsönhat ezzel. Az általános masquerade-szabály elé helyezett kivétel megakadályozza, hogy a védett forgalom elveszítse azt a forrást, amelyet a házirendje megkövetel; nem javítja meg a méretproblémát, és egy méretszabály nem javítja meg a fordítási problémát.

Szűken ellenőrizzen, aztán álljon le

Nyisson új kapcsolatot a meghibásodó szolgáltatáshoz, és figyelje az alkalmazást és a szabály számlálóit is. Ha az elakadás megszűnik, bizonyítéka van arról a TCP útvonalról azzal a beágyazással. Nincs bizonyítéka arra, hogy minden VPN-protokoll illeszkedik, hogy minden UDP-alkalmazás javítva van, vagy hogy egy adott felsőbb szolgáltatás volt az eredeti ok.

Hagyja működni az ICMP méret-visszajelzést ott, ahol a házirend engedi, és óvatosan kezelje az útvonal MTU-ján alapuló automatikus szabályozást, amikor a külső IPsec útvonalat nem a belső útvonal képviseli. Minél szűkebb a következtetés, annál könnyebb a következő incidenst diagnosztizálni.