VPN-шлюз Windows: три завдання, три власники

Три функції об’єднуються щоразу, коли хтось каже «сервер VPN»: завершення зашифрованого тунелю, переміщення пакетів між мережами та, за потреби, перезапис адрес. У Windows вони живуть у різних частинах стека, навіть якщо одна машина виконує всі три. Кожна має свої входи та свій режим відмови, і кожну можна передати іншому продукту. Розділити їх на папері — найдешевший спосіб зберегти зрозумілість невеликого розгортання.

Читабельний проєкт називає власника кожного потоку, а не описує машину як роль.

Завершити, переслати, перетворити

RRAS обслуговує тунель у рідному випадку Windows: автентифікує користувача, видає адресу з пулу та вирішує, які призначення дозволені. Інший продукт VPN може натомість володіти слухачем і віртуальним адаптером, залишивши Windows пересилання розшифрованих пакетів. Документація Microsoft щодо Remote Access розділяє ролі VPN, «мережа — мережа» та маршрутизації, і встановлення ролі маршрутизації не створює другої ідентичності VPN. Додавання ще одного VPN-застосунку також не передає його адаптер усім наявним функціям шлюзу.

Перетворення адрес — третє й найнеобов’язковіше завдання. Воно йде після пересилання й змінює адресу джерела, яку бачить віддалена мережа. Чи потрібне воно вам, залежить від того, що мережа призначення прийме як джерело, а не від того, що машину називають VPN-шлюзом.

Кому належать адаптер і пул

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

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

Збережи джерело або перезапиши його

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

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

Опиши потік одним реченням

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

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

Коли речення стає неясним, додавання ще одного рівня перетворення рідко його прояснює. Видалення одного зазвичай прояснює.