Клієнти нижчої мережі за вищим VPN: маршрут чи NAT?

Один шлюз запускає WireGuard для ваших власних пристроїв і клієнт OpenVPN у чиюсь іншу мережу. Передавання між двома внутрішніми інтерфейсами працює, і легко зробити висновок, що нижча підмережа тепер є частиною вищої служби. Це не так. Маршрут, який отримує клієнт, повідомляє вашому шлюзу, куди надсилати запити; він нічого не каже про те, як віддалена мережа повертає трафік пристроям, про які ніколи не чула. Виберіть модель повернення, яку вища служба справді підтримує, перш ніж додати хоч одне правило.

Вирішіть модель повернення, перш ніж торкатися маршрутизації

У цьому огляді клієнти нижчої мережі використовують 10.90.0.0/24, призначена шлюзу адреса вищого тунелю — 10.80.0.6, а схвалений віддалений ресурс — 172.20.0.30. Цій формі відповідають дві моделі: зберегти нижче джерело і змусити дальню сторону його маршрутизувати або перетворити джерело на власну адресу тунелю шлюзу. Усе після цього рішення механічне, а саме рішення потребує власника служби. Один рядок вище — це угода про маршрутизацію з дальньою стороною; інший — локальна зміна політики, яку ви можете зробити самі. Саме плутанина між ними перетворює десятихвилинну зміну на переговори.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

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

Збереження джерела через маршрутизацію

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

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

Навмисне перетворення джерела

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

IPv6 потребує власного проєкту; копіювання рядка masquerade для IPv4 — не архітектура. Перевіряйте перетворений шлях новим з'єднанням, а не закешованим.

Локальний шлях даних усе одно має працювати

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

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

Одне джерело означає одну ідентичність сеансу

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

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

Визначте стан розриву, потім перевірте три запити

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

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