NAT на сервері VPN чи на маршрутизаторі? Працюють обидва варіанти

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

Міф: маршрут клієнта створює вихід

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

Ця невідповідність і є вся проблема, яку розв'язує решта статті. Щось має зробити приватну адресу клієнта зворотною, і вибір — де.

Спершу намалюйте зворотний шлях

Запишіть шлях із реальними адресами, перш ніж чіпати будь-яке налаштування, і позначте на ньому дві можливі точки трансляції. Ця лабораторія використовує пул VPN 10.70.0.0/24 з одним клієнтом на 10.70.0.37, адресу LAN сервера 172.16.40.10, маршрутизатор на 172.16.40.1 і публічний вихід 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

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

Варіант A: трансляція на сервері VPN

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

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Використайте ці читання, щоб побачити, що сервер уже має, замість припускати наявність NAT. Скопійоване з блогу правило masquerade у Linux — не конфігурація Windows, а дозвіл у брандмауері хоста для слухача VPN — не та сама політика, що дозвіл пересилати запит клієнта далі. Підтвердьте роль пересилання сервера на його власній панелі керування, а потім подивіться на трансляцію окремо, бо ці дві речі часто вмикаються різними частинами розгортання.

Варіант B: перенести пул на маршрутизатор

У другій схемі сервер пересилає справжню адресу джерела клієнта, і маршрутизатор транслює її. Це залишає пул клієнтів видимим на краю, що допомагає, якщо саме маршрутизатор є місцем політики трафіку, журналювання чи перевірки. Це також означає, що маршрутизатору потрібен зворотний маршрут для 10.70.0.0/24, який указує на 172.16.40.10, плюс інтернет-політика, що справді включає цей префікс; правило, написане для підмережі LAN, мовчки не поширюється на пул.

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

Зробіть DNS, IPv6 і приймання явними

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

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

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