Настройка на MSS за TCP на Linux IPsec шлюз: какво поправя

Ping работи, SSH работи, малка страница се зарежда, а после всеки голям отговор забива, докато не изтече времето. Класическата картина сочи към размера на пакета, а не към достъпността: пътят носи ръкостискането и първите няколко килобайта, после сегмент с пълен размер изчезва. На Linux IPsec шлюз правило за TCP MSS често е решението, но само ако разбирате какво променя и къде всъщност се намира пакетът, който то докосва. Редът по-долу следва пакета от симптома до поставянето на правилото, така че да можете да спрете, щом обяснението спре да пасва.

Симптомът, който подсказва за MSS

TCP договаря максимален размер на сегмента при ръкостискането. Ако тази стойност е по-голяма от това, което пътят може да пренесе след инкапсулацията, подателят продължава да създава сегменти, които никога не пристигат, и връзката забива след първия обмен. Малките отговори минават; големите не.

Обратната връзка по ICMP може да спаси връзката чрез откриване на MTU на пътя, а защитна стена, която изхвърля тези съобщения, превръща забиването в тиха черна дупка. Затова един и същ тунел работи за едно приложение и се проваля за друго без видима разлика в конфигурацията.

Какво прави правилото TCPMSS и какво не

Правилото пренаписва опцията MSS в пакетите за ръкостискане на TCP, докато те преминават. То не задава MTU на тунелния интерфейс, не променя политиката на IPsec и на съвременните ядра само понижава обявена стойност, вместо да повишава вече по-малка. То също така докосва само TCP; полезните товари на UDP, поведението на DNS и договорените селектори на трафик са извън обсега му.

Тъй като промяната става по време на ръкостискането, съществуваща връзка, установена преди правилото, запазва старата си стойност. Тествайте с нова връзка и очаквайте първият опит след промяната да е този, който ви казва нещо. Нищо в правилото не достига до връзка, която вече е отворена. Затова поправка, приложена по средата на инцидент, може да изглежда, че не е направила нищо.

Поставете правилото на вътрешния TCP път

На Linux шлюз с политики препратеният пакет все още изглежда като обикновен TCP, когато защитната стена го види. Политиката на IPsec решава, че пакетът ще бъде защитен; защитната стена не вижда ESP заглавка за вътрешния поток, така че съпоставянето с ESP тук описва съвсем различен пакет. Именно това несъответствие е причината някои правила да изглеждат правилни и никога да не съвпадат.

В термините на iptables правилото принадлежи на таблицата mangle по пътя на препращане, ограничено до пакетите за ръкостискане: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Числото е пример, а не универсална константа; изведете го от разходите за инкапсулация и реалния MTU на пътя. Еквивалент за nftables задава максималния размер на сегмента във верига forward или postrouting.

Дръжте външните правила за слушане на IKE и ESP отделно от вътрешните правила за препращане. Едно правило, което се опитва да оторизира едновременно потока на приложението и външния протокол, в крайна сметка не съвпада надеждно с нито едно от двете.

Уважавайте собственика на защитната стена и реда на NAT

Ако UFW управлява защитната стена на хоста, добавяйте промените по mangle и препращането чрез поддържаната от него постоянна конфигурация, вместо чрез команда, която изчезва при следващото презареждане. Правило, вмъкнато в грешната таблица или след терминално правило, няма ефект, а живата таблица крие това от вас.

Транслацията на източника е отделно решение, което често взаимодейства с това. Изключение, поставено преди общо правило за masquerade, пази защитения трафик да не загуби източника, който политиката му изисква; то не поправя проблем с размера, а правило за размер не поправя проблем с транслация.

Проверете тясно, после спрете

Отворете нова връзка към проблемната услуга и наблюдавайте както приложението, така и броячите на правилото. Ако забиването изчезне, имате доказателство за този TCP път с тази инкапсулация. Нямате доказателство, че всеки VPN протокол пасва, че всяко UDP приложение е поправено или че конкретна услуга по-нагоре е била първоначалната причина.

Оставете обратната връзка по ICMP за размер да работи там, където политиката позволява, и се отнасяйте внимателно към автоматичното ограничаване на база MTU на маршрута, когато външният IPsec път не е представен от вътрешния маршрут. Колкото по-тясно е заключението, толкова по-лесно е да се диагностицира следващият инцидент.