Доступ к домашнему устройству через VPN удалённого доступа: пять шлюзов

Коммерческий VPN с выходом в интернет скрывает ваш адрес; он не соединяет вас с вашим собственным домом. Чтобы добраться до NAS или принтера в домашней сети, нужен шлюз в этой сети и клиент, который строит к нему туннель. Затем пакет должен пройти пять проверок, и любой их сбой снаружи выглядит одинаково.

Шлюз 1: клиент должен выбрать туннель

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

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

Прежде чем продолжать, убедитесь, что адрес пула клиента и домашняя подсеть не пересекаются.

Шлюз 2: шлюз должен пересылать

VPN завершается на хосте, который должен переслать расшифрованный пакет в LAN. Для этого нужна включённая пересылка IP и политика межсетевого экрана, разрешающая поток из интерфейса VPN в интерфейс LAN. На роутере это обычно встроено; на машине Linux с strongSwan или WireGuard это две настройки, которые люди забывают. Проверьте обе перед тестированием службы, потому что каждая сама по себе даёт одинаковый тайм-аут.

Проверяйте с захватом на интерфейсе LAN, потому что пакет, который там никогда не появляется, был отброшен или так и не переслан.

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

Шлюз 3: путь ответа решает всё

Цель отвечает на увиденный адрес источника — это адрес пула клиента или шлюз, в зависимости от того, транслируете ли вы. Если шлюз по умолчанию у цели — домашний роутер, и у этого роутера нет маршрута к пулу VPN, ответ уходит через интернет и умирает. Это классическое одностороннее соединение.

Есть два законных решения: добавить маршрут к пулу на шлюзе LAN или сделать source-NAT на шлюзе VPN, чтобы цель всегда видела только адрес шлюза. Второе проще и теряет исходную идентичность источника.

Выберите одно осознанно и запишите, какое, потому что правила межсетевого экрана и журналы зависят от этого. Руководство strongSwan по пересылке проходит по стороне Linux этого решения.

Шлюз 4: имена и перекрытие префиксов

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

Перекрывающиеся префиксы — другая ловушка: если пул клиента 192.168.1.0/24 и домашняя сеть тоже, клиент считает назначение локальным и никогда не отправляет его через туннель.

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

Шлюз 5: проверяйте снаружи дома

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

Если служба отвечает, а имя нет, у вас проблема DNS, а не туннеля.

Храните рабочую конфигурацию в заметке с пулом, маршрутом и выбором NAT, потому что следующая замена роутера сбросит все три.