Может ли роуминговый клиент VPN хостить сервис для офиса?

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

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

Направление подключения ничего не говорит о направлении сервиса

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

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

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

Проследите обратный путь, прежде чем открывать порт

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

Хорошая новость в том, что внутреннему пути не нужна переадресация порта на домашнем роутере клиента. Именно в этом смысл публиковать службу на адресе туннеля, а не на домашнем адресе WAN, где доступность извне и правила NAT были бы совсем другими. Домашний роутер может также отказаться делать hairpin для соединения из офиса, поэтому маршрут через WAN отказывает по причинам, не связанным с вашим VPN. Удержание трафика внутри туннеля избегает обеих проблем сразу.

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

Имена и адреса — это решения дизайна

Адрес внутри туннеля не становится именем автоматически. Частная запись DNS, которую вы контролируете, яснее надежды на то, что протокол обнаружения пройдёт через туннель, потому что разрешение имён через локальный multicast остаётся в локальном сегменте и не становится DNS между подсетями.

Стабильность адреса столь же важна. Если клиенты VPN получают адреса из пула с короткой арендой, внутренний адрес ноутбука меняется между сеансами, и каждая закладка, область брандмауэра и проверка мониторинга, построенные на нём, тихо ломаются. Используйте резервирование или документированный путь динамического обновления.

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

Тестируйте службу, а не членство

На цели подтвердите, что и на каком адресе слушает, затем подтвердите взгляд шлюза на обратный путь:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Теперь проверьте со стороны офиса настоящим запросом, а не эхом. Успешный curl к службе доказывает маршрут, политику и слушателя сразу, тогда как успешный ping доказывает лишь то, что ICMP разрешён. Если запрос не проходит, идите назад по трём частям, а не расширяйте брандмауэр в надежде.

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

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

Похожие статьи