Налаштування 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 не представлений внутрішнім маршрутом. Що вужчий висновок, то легше діагностувати наступний інцидент.