Домашний VPN-сервер против облачного: какой доберётся до вашего NAS?

Туннель поднимается, клиент показывает зелёную точку, и ssh 192.168.1.20 всё ещё висит до тайм-аута. Именно это я испытал, сняв маленький облачный инстанс и поставив на него WireGuard: рукопожатие в порядке, DNS в порядке, а NAS на моём столе так же недоступен, будто он на Луне. С туннелем всё было в порядке. Endpoint стоял в сети, из которой нет маршрута к моему дому. Расположение endpoint определяет, какие сети соседние, поэтому выбирайте его по ресурсу, до которого нужно добраться первым, а хостинг сравнивайте вторым.

Туннель достаёт только до сетей, которые endpoint умеет маршрутизировать

VPN даёт клиенту адрес внутри собственного домена маршрутизации endpoint. Когда клиент отправляет пакет на 192.168.1.20, endpoint должен знать, куда тот идёт. Таблица облачной VM знает подсети VPC провайдера; о вашей LAN она никогда не слышала. Подключено и доступно — два разных факта, и большая часть путаницы между домом и облаком возникает из-за того, что первое принимают за доказательство второго.

Одна команда всё решает. На endpoint ip route get 192.168.1.20 либо называет интерфейс LAN, либо указывает на маршрут по умолчанию. На домашней машине ответ — сторона LAN. На облачном инстансе пакет уходит в интернет и умирает. Включение net.ipv4.ip_forward=1 и добавление правила MASQUERADE этого не меняет, потому что пересылать некуда, пока что-то на домашней стороне не завершит связь в облако.

У домашнего случая есть вторая половина: обратный путь. Пакеты, покидающие LAN через коробку туннеля, проходят NAT, или LAN нужен статический маршрут назад к подсети туннеля. Когда работает только одно направление, проверьте sysctl net.ipv4.conf.all.rp_filter. Строгая фильтрация обратного пути отбрасывает ответы, приходящие на другой интерфейс, чем предсказывает маршрут, и симптом выглядит в точности как правило брандмауэра.

Прочитайте симптом, прежде чем трогать конфигурацию

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

Входящая доступность из дома заслуживает отдельной проверки, потому что она решает, возможен ли хостинг дома вообще. Сравните WAN-адрес, который сообщает роутер, с адресом, который видит внешний хост. Если он попадает в 100.64.0.0/10 или они не совпадают, вы за carrier-grade NAT и никакая переадресация порта никогда не заработает. Реальные варианты — релей, облачная связка, которая звонит наружу из дома, или перенос endpoint.

Что даёт домашний хостинг и сколько он стоит

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

Затраты физические. Домашняя отдача — потолок для всех клиентов сразу, поэтому видеозвонок и резервная копия конкурируют за одну трубу. Электричество, износ диска, патчи, динамический адрес, которому нужен DDNS, роутер, который должен пересылать UDP внутрь, и возможно двойной NAT — всё это ложится на вас. То, что люди пропускают, — восстановление: если коробка умрёт, пока вас нет, единственный путь домой умрёт вместе с ней. Держите второе устройство с теми же ключами или хотя бы план физического доступа.

Если хотите доступ к LAN без коробки дома, постройте связку вместо того, чтобы притворяться. Облачный endpoint становится роутером: туннель с домашней стороны с AllowedIPs = 192.168.1.0/24 на облачном peer, плюс пересылка и NAT на облачной коробке. Руководство strongSwan по пересылке разбирает обратную половину этой схемы, и именно там терпят крах большинство таких попыток. Домашний peer теперь должен быть поднят, чтобы хоть что-то работало, так что вы обменяли одну зависимость на другую и стоит это записать.

Для чего на самом деле нужен облачный endpoint

Облачный endpoint меняет ваш публичный выход. Трафик уходит из диапазона адресов провайдера, и сайты видят этот адрес вместо домашнего. В этом ценность, и поэтому облачный VPN не даёт вам NAS: вы перенесли выход, а не LAN.

Вы по-прежнему управляете гостевой системой, службой VPN и её учётными данными, пока провайдер управляет гипервизором и физической сетью, и это разделение важно, когда что-то ломается в 2 часа ночи. Публичный endpoint постоянно сканируется, поэтому держите порт управления закрытым, разрешайте только порт VPN и ставьте патчи по расписанию. Группы безопасности и брандмауэры провайдера должны разрешать этот порт, а некоторые облака отбрасывают перенаправленный трафик, пока вы не настроите проверку источника и назначения на инстансе.

Маленький инстанс покрывает горсть клиентов, но шифрование — работа CPU, а burstable-инстанс, у которого кончились кредиты, ведёт себя неровно под постоянной нагрузкой. Смотрите на путь, которым реально пользуетесь, а не на спецификацию.

Решение, которое можно записать

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

Проверяйте с клиента по порядку: рукопожатие, адрес peer, хост LAN, затем IP выхода. curl -s https://ifconfig.me показывает, что видит интернет, а ip route get 192.168.1.20 показывает, что думает endpoint. Когда проверка выхода проходит, а проверка NAS висит, ответ о размещении у вас уже есть; настройка AllowedIPs на клиенте маршрут не создаст. Разделённая строка вроде 10.8.0.0/24, 192.168.1.0/24 держит трафик LAN внутри туннеля только когда этот маршрут действительно существует.