Когда клиент удалённого доступа должен работать как шлюз филиала

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

Чего не говорит вам ярлык протокола

OpenVPN документирует схему сайт — сайт, в которой коннектор передаёт целую подсеть, а Access Server реализует её с ролью шлюза и явной маршрутизацией. Другой продукт, продаваемый как SSL VPN, может предоставлять только функции удалённого пользователя, без поддерживаемого способа объявить сеть за клиентом. Версия тоже имеет значение, потому что функция в одном выпуске не обещание о другом. Читайте реализацию, которую действительно запускаете, и считайте рецепт, написанный для другого продукта, подсказкой, а не проектом.

Вопрос, который нужно решить первым, — поддерживает ли владелец VPN роль передачи вообще. Если нет, никакая маршрутизация на стороне клиента не сделает её поддерживаемой.

У договора две стороны: филиал и головной офис

На стороне филиала передачей, фильтрацией и восстановлением владеет один хост. Ему нужен продуманный путь от каждого устройства филиала, а внешнее VPN-соединение должно оставаться доступным через базовую сеть даже при выключенном туннеле. На стороне головного офиса кто-то должен определить подсеть филиала, принять идентичность шлюза и разрешить конкретные ресурсы. Ни одна половина не работает сама по себе.

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

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

Маршрутизация или трансляция: выбирайте обратный путь осознанно

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

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

Полезная проверка асимметрична: запросите ресурс с устройства филиала, затем подтвердите, что ответ покидает головной офис в сторону префикса филиала. traceroute -n 10.60.4.20 с хоста в головном офисе показывает, идёт ли этот путь через VPN-шлюз.

Эксплуатируйте это как инфраструктуру, а не как вход

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

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

Проверьте предполагаемые приложения филиала, их обратный трафик и один запрещённый получатель в рамках утверждённого плана. Успех выглядит как собственный сетевой сервис с назначенной идентичностью филиала и явной политикой, а не как окно клиента с надписью Подключено.