NAT і перенаправлення портів на Linux: налаштування iptables/nftables

Чому NAT розриває з'єднання під час пробросу портів

Проброс портів на Linux — це не одне правило, а два незалежні перетворення. Вхідний пакет отримує нову адресу призначення, відповідний — нову адресу джерела.

Поки обидва напрямки проходять через один вузол з одним набором правил, з'єднання живе; щойно симетрія порушується, відповідь іде в обхід таблиці станів, і клієнт бачить обрив.

Перший типовий сценарій — зміна зовнішньої адреси: резервний канал, другий провайдер, динамічна адресація. З'єднання в таблиці станів прив'язане до пари адрес, і під час перемикання лінії відповідь приходить уже з іншої — NAT не може зіставити її з вихідним потоком. Короткі запити це переживають, довгі сесії рвуться на середині.

Асиметрична відповідь ламає доступ тихіше: внутрішній хост відповідає через шлюз, відмінний від того, куди прийшов запит, і виходить назовні з внутрішньою адресою джерела.

Зовнішня сторона відкидає такий пакет, а в логах видно лише «з'єднання встановлено» без корисного навантаження.

Пересічні підмережі додають своє: за збігу діапазонів офісу й хмари проброс попадає не на той хост, і правкою одного правила це не лікується.

Окрема категорія — втрата правил після перезавантаження: iptables/nftables тримають набір у пам'яті ядра, і до застосування збереженої конфігурації вузол або відкритий назовні, або закритий для своїх.

Нижче — як кожен сценарій закривається схемою адресації, постійним зберіганням правил і контролем стану з'єднань.

Що змінюється після наведення ладу в правилах

Лад починається з того, що правила трансляції адрес перестають бути шаром накопичених правок. Кожен сервіс отримує свій набір з описаним призначенням, а ланцюжки збираються в передбачуваному порядку обходу.

Новий сервіс додається одним блоком за шаблоном — без пошуку місця, куди вклинитися між старими записами.

Введення нового сервісу скорочується з кількох годин до десятків хвилин. Раніше зміна адреси чи порту вимагала правок у кількох місцях, і кожну перевіряли на стенді; тепер конфігурація збирається з опису сервісу, і розбіжність видно одразу, а не на етапі приймання.

Окремо закривається найнеприємніший клас відмов — асиметрична трансляція. Якщо правило для вхідного трафіку є, а зворотне перетворення описане інакше, з'єднання встановлюється і рветься на першій відповіді: ззовні це виглядає як «працює через раз».

Стабільність з'єднань тримається не на удачі, а на узгодженості обох напрямків, і єдине джерело правил прибирає саму можливість такої розбіжності.

Час відновлення сервісу вимірюється читанням, а не пошуком: журнал скидань і лічильники на ланцюжках показують, на якому кроці пакет відкидається.

Зміна зовнішньої адреси перестає бути подією — правила прив'язані до інтерфейсу та ролі, а не до конкретного значення, тому переїзд займає хвилини.

Звернень до підтримки стає менше не тому, що їх фільтрують, а тому що зникає привід: типове «порт не відкривається» закривається перевіркою конфігурації до того, як дійде до чергового.

Режими NAT: порівняння підходів та обмежень

Режим трансляції визначає, що бачить зовнішня сторона і наскільки передбачувано поводиться з'єднання зі зростанням навантаження. Нижче — чотири варіанти, між якими реально обирають під час налаштування iptables або nftables, з їхніми сильними сторонами та межами застосовності.

Різниця проявляється не під час первинного налаштування, а під час першої зміни топології: один режим переживає переїзд сервісу правкою одного рядка, інший вимагає перезбирання правил цілком.

Спільне обмеження для всіх варіантів — трансляція працює з адресами та портами, але не розрізняє сенс трафіку: фільтрація за вмістом запиту й захист від прикладних атак залишаються на самому сервісі.

Тому режим обирають разом із політикою фільтрації, інакше проброс відкриває назовні більше, ніж передбачалося.

Порядок робіт: збирання правил NAT, перевірка, передача

Правила трансляції адрес майже ніколи не збирають з нуля: на живій машині вже є ланцюжки, частину додано вручну й ніде не описано.

Тому ми спочатку фіксуємо фактичну топологію та поточний набір правил і лише потім проєктуємо цільову схему — інакше перша ж зміна ламає чужий трафік.

1. Розбір топології. Які інтерфейси дивляться назовні, де шлюз за замовчуванням, які сервіси мають бути доступні ззовні, а які — лише всередині мережі.
2. Аудит правил. Вивантажуємо чинні ланцюжки iptables або nftables разом зі лічильниками пакетів: правила без трафіку, дублі, перетини, «тимчасові» записи, що живуть роками. Підсумок — таблиця «правило — призначення — власник».
3. Схема трансляції адрес. Розділяємо, де потрібна підміна адреси джерела, а де — проброс вхідного порту на внутрішній вузол, і розводимо потоки окремими ланцюжками, щоб правка одного сервісу не зачіпала сусідні.
4. Перевірка правил на стенді. Повторюємо топологію в тестовому контурі й проганяємо цільові правила: потрібні з'єднання проходять, зайві закриті. Конфігурацію зберігаємо в репозиторій.
5. Контрольне перемикання. Застосовуємо на бойовому вузлі з прописаним відкатом за таймером: не пройшли узгоджені перевірки — конфігурація повертається до попередньої автоматично, без ручної роботи.
6. Спостереження. Першу добу стежимо за лічильниками, журналами та кількістю встановлених з'єднань, звіряємо з прогнозом і окремо перевіряємо поведінку за пікового навантаження.
7. Передача конфігурації. Віддаємо файл правил під контролем версій, схему трансляції, карту портів та інструкцію з відкату, розбираємо з вашою командою порядок подальших правок.

Пакет передачі: конфігурації, схеми, регламенти

Пакет передачі — це не набір скриншотів із консолі, а робочі конфігурації в репозиторії замовника.

Кожен артефакт розрахований на людину, яка за пів року правитиме правило, не писала його сама: вона має зрозуміти призначення рядка, знайти власника сервісу та відкотити зміну без нічного розбору.

• Файли правил із коментарями — розбиті за зонами: зовнішній периметр, публічний сегмент, внутрішні мережі. Для кожного набору зазначено, який трафік він пропускає, чому правила стоять саме в такому порядку і що зламається за їх перестановки.
• Схема мережевих потоків — таблиця трансляції адрес, проброси, ініціатори з'єднань і зворотні шляхи. Дозволяє за хвилину відповісти, звідки прийшов трафік і куди він іде після перетворення.
• Політики доступу — матриця «сервіс → джерело → порт → обґрунтування». За замовчуванням закрито все, що в матриці не описано, а кожен виняток має власника та строк перегляду.
• Регламент чергування — строки реакції на обрив зв'язку й підозрілу активність, порядок ескалації, вікна планових змін і той, хто підтверджує правку периметра.
• Інструкції з типових операцій — додати або зняти проброс, перевірити лічильники правил, зняти дамп трафіку, відновити набір із резерву. З командами, очікуваним виводом і ознаками того, що пішло не так.
• Резервне копіювання конфігурацій і перевірена процедура відкату: відновлення проганяється на стенді, а не описується «на словах».
• Карта відповідальності — відповідність «правило → сервіс → власник», щоб узгодження не впиралося в одного інженера.

Пакет улаштований так, щоб правки вносилися силами вашої команди, без звернення до нас за кожним рядком. Під час передачі проходимо кожен документ на живому стенді та відповідаємо на запитання по ходу.

Кейс: обриви з'єднань після перебудови мережі

Сервіс працював рівно, поки мережу не перебудували: додали другий зовнішній канал і винесли частину підмереж за окремий шлюз. У пікові години до 4% звернень закінчувалися помилкою з'єднання, а кожне перезавантаження правил NAT на шлюзі рвало вже встановлені сесії.

Вікно простою під час планової зміни розтягувалося на 30–40 хвилин — частина з'єднань не відновлювалася сама, і клієнти приходили з повторами.

Що знайшли

Причина виявилася в одній спільній таблиці відстеження з'єднань на два зовнішні інтерфейси: відповідні пакети поверталися не через той канал, з якого йшов запит, і ядро позначало з'єднання недійсним.

Другий шар — повне перезавантаження правил: старий набір знімався цілком, разом з ним губилася таблиця з'єднань і весь активний трафік.

Що змінили

Перейшли на атомарне застосування набору правил: нова конфігурація завантажується однією операцією, старі сесії живуть, тому планова зміна перестала бути простоєм.

Розвели відстеження з'єднань за контурами, підняли граничний розмір таблиці та запас за хеш-кошиками, вирівняли таймаути під реальний профіль трафіку. Маскарадинг вихідного трафіку налаштовано з випадковим вибором порту — це зняло колізії за двох каналів.

Що вийшло

Після переведення частка невдалих звернень у пік знизилася з 4% до 0,15%, планові зміни шлюзу проходять без розриву активних сесій, а інцидентів із викликом чергового стало нуль–один на місяць замість семи–дев'яти.

Рішення відтворюване на будь-якому шлюзі: логіка однакова і для старих наборів правил, і для нового стеку (Netfilter).

Чим маскарадинг відрізняється від статичного перетворення адрес?

Різниця в тому, звідки береться підставлювана адреса. Маскарадинг — динамічне перетворення джерела: ядро саме бере адресу того інтерфейсу, через який пакет іде назовні, а правило працює в ланцюжку після маршрутизації.

Статичне перетворення адрес оперує явно заданою парою «внутрішній — зовнішній», і ця пара не змінюється за зміни маршруту чи перезапуску шлюзу.

Маскарадинг закриває лише сценарій, де ініціатива з'єднання зсередини: сесію відкриває клієнт за шлюзом, а зворотні пакети повертаються за таблицею станів. Розпочати з'єднання ззовні не можна — запис з'являється лише від вихідного пакета.

Статичне перетворення це обмеження знімає: проброс публікує внутрішній сервіс, і вхідне з'єднання встановлюється незалежно від вихідного трафіку.

За супроводом режими розходяться сильніше. Маскарадинг не прив'язаний до конкретної адреси й переживає її зміну на зовнішньому інтерфейсі без правки правил, але приховує реальне джерело: для зовнішньої сторони всі клієнти виглядають одним вузлом.

Статична схема читабельна за адресами, зате кожна зміна зовнішньої адресації вимагає синхронного оновлення правил і маршрутів.

Ламаються режими теж по-різному. Маскарадинг упирається в таблицю станів: за множини одночасних з'єднань до одного зовнішнього вузла вільних портів-джерел не вистачає, нові сесії відкидаються, а причина видна лише в лічильниках ядра.

Статичний варіант відмовляє за асиметричного маршруту та за звернення до зовнішньої адреси зсередини тієї ж мережі.

Вибір режиму зводиться до одного: потрібен лише вихідний доступ і зовнішня адреса не зафіксована — маскарадинг; сервіс має приймати з'єднання ззовні або адреса постійна — статичне перетворення.

Спірні моменти: подвійна трансляція, асиметрія, журнали

Подвійна трансляція, асиметричні відповіді та конфлікт правил — три випадки, де NAT поводиться не так, як на схемі. Нижче — короткі відповіді на запитання, які зазвичай виринають на прийманні та в перший місяць експлуатації.

Відповідь не повернулася — асиметрична маршрутизація

Пакет пішов через один канал, а відповідь прийшла через інший: стан з'єднання не збігся, і запит мовчки скидається, хоча правило на місці. Вирівнюємо маршрути — один вхід і один вихід для трафіку, а політика маршрутизації для резервних каналів враховує таблицю з'єднань.

Де дивитися, яке правило спрацювало

Лічильники пакетів показують, які правила збіглися, але не порядок обходу ланцюжків. На час розбору ставимо логувальне правило перед термінальним — воно фіксує пакет до вердикту, і конфлікт двох сусідніх ланцюжків видно одразу. Логування обмежуємо за частотою, щоб налагодження не забило диск, і знімаємо після розбору.

Обговоримо задачу: надішліть схему мережі та поточні правила

Чим точніші ввідні, тим менше припущень в оцінці робіт. Розбір схеми мережі та поточного набору правил займає менше часу, ніж відновлення логіки за уривками конфігурацій на сервері — тому просимо саме те, що знімає невизначеність.

• Схему мережі або список підмереж: хто з ким має бачитися, де шлюзи, які сегменти ізольовані, де зараз рветься зв'язність.
• Поточні правила у вигляді дампу: таблиці фільтрації, трансляції та маршрутизації цілком, а не фрагмент — частина проблем живе на стику ланцюжків і видна лише в повному виводі.
• Чим керується конфігурація: iptables чи nftables, чи є поверх обгортка на кшталт firewalld або ufw, чи зберігається стан після перезавантаження.
• Формулювання задачі: проброс порту назовні, трансляція для виходу в інтернет, публікація сервісу за балансувальником або доступ із філії.
• Як правила застосовуються сьогодні: руками за інструкцією, через систему керування конфігураціями, шаблоном чи юнітом під час завантаження.
• Обмеження: допустиме вікно змін, вимога до відкату, хто має доступ до вузлів і чи є резервний канал.
• Симптоми та журнали: що саме не працює, чи відтворюється збій постійно чи під навантаженням, що пише ядро та служби в момент відмови.

З цим набором ми повертаємося з планом впровадження та оцінкою робіт: порядок правок, точки перевірки після кожного кроку і спосіб повернути попередній стан однією командою. Опишіть задачу та додайте те, що вже є під рукою — решту уточнимо в листуванні.