VPN-шлюз Windows: три задачи, три владельца

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

Читаемый проект называет владельца каждого потока, а не описывает машину как роль.

Завершить, передать, преобразовать

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

Преобразование адресов — третья и самая необязательная задача. Она идёт после передачи и меняет адрес источника, который видит удалённая сеть. Нужна ли она вам, зависит от того, что сеть назначения примет в качестве источника, а не от того, что машину называют VPN-шлюзом.

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

Когда несколько продуктов делят хост, четырём вещам нужен по одному владельцу: порты прослушивания, время жизни адаптера, пул клиентских адресов и маршруты. Адаптер — самый неудобный случай, потому что служба VPN может создавать его динамически и уничтожать при отключении. Отношение к этому интерфейсу как к постоянно именованной сетевой карте и правила, написанные против его имени, работают до следующего переподключения. Используйте поддерживаемую продуктом точку интеграции, а не жёстко задавайте имя интерфейса.

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

Сохранить источник или перезаписать его

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

Доступ к частной сети, выход в интернет и соединения, завершающиеся на самом шлюзе, — это три разных пути. Им не всем нужен одинаковый подход.

Опишите поток одним предложением

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

Держите перечень ролей рядом с конфигурацией: какой продукт завершает, какой передаёт, какой преобразует и кто может менять каждый из них. Именно этот список делает следующее изменение проверяемым.

Когда предложение становится неясным, добавление ещё одного уровня преобразования редко его проясняет. Удаление одного обычно проясняет.