Как получить удалённый доступ к домашней или офисной сети без белого IP

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

Обычно пользователь сначала настраивает проброс портов и DDNS, но при сером IP или CGNAT эти способы не дают ожидаемого результата: входящее соединение не доходит до пользовательского роутера.

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

В этой статье рассмотрим вариант с Linux VPS. Устройство внутри домашней или офисной сети самостоятельно устанавливает исходящий защищённый туннель к VPS, а удалённый пользователь подключается к тому же серверу и получает доступ только к разрешённым внутренним ресурсам.

В качестве транспорта используем WireGuard. Основное внимание уделим архитектуре подключения, маршрутам, работе сети за CGNAT и правилам firewall. Полную базовую установку WireGuard повторять не будем — для неё в блоге уже есть отдельная инструкция.

Почему проброс портов и DDNS не работают без белого IP

Чтобы принять соединение из Интернета, домашний или офисный роутер должен иметь публичный IP-адрес. Такой адрес маршрутизируется в Интернете и доступен с внешних сетей, если соединение не блокируют firewall или правила провайдера.

В разговорной речи публичный адрес часто называют белым IP.

Чем NAT отличается от CGNAT

NAT — механизм преобразования сетевых адресов. Он позволяет нескольким устройствам локальной сети выходить в Интернет через один внешний IP-адрес.

В обычной домашней схеме NAT выполняет роутер:

Ноутбук или сервер
192.168.50.10
        │
        ▼
Домашний роутер
192.168.50.1
        │
        ▼
Публичный IP
        │
        ▼
Интернет

CGNAT — Carrier-Grade NAT, то есть преобразование адресов на стороне оператора связи. В такой схеме за одним публичным IP провайдера находятся сразу несколько абонентов.

Схема выглядит так:

Внутренний сервер
192.168.50.10
        │
        ▼
Роутер
192.168.50.1
        │
        ▼
Адрес провайдера
100.64.0.0/10
        │
        ▼
CGNAT провайдера
        │
        ▼
Общий публичный IP

Пользователь может управлять своим роутером, но не правилами на узле CGNAT. Поэтому настроенный на домашнем или офисном роутере проброс порта не создаёт доступный из Интернета маршрут.

Как проверить, используется ли CGNAT

Сначала посмотрите WAN-адрес в интерфейсе роутера. Название поля зависит от модели устройства: WAN IP, Internet IP, IPv4 address или похожий вариант.

Затем сравните его с адресом, который показывает сервис проверки внешнего IP.

На CGNAT указывают следующие признаки:

• WAN-адрес роутера отличается от внешнего адреса;
• роутер получил адрес из диапазона 100.64.0.0/10;
• на WAN-интерфейсе используется частный адрес из диапазонов 10.0.0.0/8, 172.16.0.0/12 или 192.168.0.0/16;
• проброс портов настроен правильно, но проверка с внешней сети показывает, что порт недоступен;
• трассировка обнаруживает дополнительные частные узлы сети провайдера.

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

Почему DDNS не решает проблему

DDNS связывает доменное имя с текущим внешним IP-адресом. Это полезно, когда провайдер выдаёт публичный, но динамический адрес.

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

Как устроен доступ к локальной сети через VPS

Если домашняя или офисная сеть не может принимать входящие соединения, она может сама установить исходящее соединение с доступным сервером.

В роли такого сервера используется Linux VPS с публичным IP.

Удалённый компьютер
10.77.0.10
        │
        │ защищённый туннель
        ▼
Linux VPS с публичным IP
10.77.0.1
        │
        │ уже установленный туннель
        ▼
Шлюз в локальной сети
10.77.0.2
        │
        ▼
Внутренняя сеть
192.168.50.0/24
        │
        ▼
NAS, сервер или рабочий компьютер
192.168.50.10

Роль VPS с публичным IP

VPS выполняет три задачи:

• принимает соединения от разрешённых устройств;
• поддерживает туннель с локальным шлюзом;
• маршрутизирует трафик между удалённым устройством и внутренней подсетью.

При этом VPS не переносит внутреннюю сеть в Интернет и не делает все её устройства публичными. Он предоставляет контролируемую точку входа, доступную только участникам туннеля.

Зачем локальный шлюз сам устанавливает соединение

Исходящие соединения обычно проходят через NAT и CGNAT без дополнительного проброса портов. Поэтому инициатором подключения становится устройство внутри локальной сети.

Таким устройством может быть:

• отдельный мини-компьютер;
• Linux-сервер;
• поддерживающий WireGuard роутер;
• виртуальная машина, которая работает постоянно;
• сам внутренний сервер, если доступ требуется только к нему.

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

Как проходит трафик

Когда удалённый пользователь обращается к адресу 192.168.50.10, его устройство направляет пакет в туннель.

VPS получает пакет и видит, что подсеть 192.168.50.0/24 находится за локальным шлюзом 10.77.0.2. Сервер передаёт пакет этому участнику WireGuard, после чего локальный шлюз отправляет его нужному устройству.

Для ответа должен существовать обратный маршрут:

Внутренний сервер
192.168.50.10
        │
        ▼
Локальный шлюз
        │
        ▼
VPS
        │
        ▼
Удалённый компьютер
10.77.0.10

Если прямой маршрут обратно не настроен, запрос может дойти до внутреннего сервера, но ответ уйдёт через обычный интернет-шлюз и потеряется.

Что можно открыть через такую схему

Через туннель можно предоставить доступ к конкретным внутренним ресурсам:

• файловому серверу;
• NAS;
• системе мониторинга;
• внутренней CRM;
• тестовому стенду;
• административной панели;
• серверу резервного копирования;
• рабочему компьютеру;
• базе данных, если прямой доступ действительно необходим.

Не следует автоматически разрешать удалённому пользователю всю домашнюю или офисную подсеть. Сначала определите, какие адреса, порты и протоколы ему нужны.

Что подготовить перед настройкой

Для примера используем следующую адресацию:

Проверьте конфликты подсетей

Удалённая и локальная сети не должны использовать одинаковую адресацию.

Например, если дома у удалённого сотрудника и в офисе используется сеть 192.168.1.0/24, операционная система не всегда сможет определить, куда направлять пакет: локальному роутеру или в туннель.

Для офисной сети лучше заранее выбрать менее распространённый частный диапазон, например:

192.168.50.0/24
10.30.40.0/24
172.20.50.0/24

Сеть WireGuard тоже должна быть отдельной и не пересекаться с существующими сетями.

Подготовьте Linux VPS

На VPS должны быть:

• публичный IPv4-адрес;
• SSH-доступ;
• обновлённая операционная система;
• отдельный административный пользователь;
• настроенный firewall;
• открытый UDP-порт WireGuard;
• возможность включить пересылку IPv4-пакетов.

Базовую подготовку сервера мы разобрали в статье «Первичная настройка Ubuntu VPS после заказа».

Если вы ещё не настроили административное подключение, сначала воспользуйтесь инструкцией «Как подключиться к Linux VPS по SSH».

Подготовьте локальный шлюз

Локальный шлюз должен:

• постоянно работать;
• иметь доступ в Интернет;
• находиться в нужной локальной сети;
• поддерживать WireGuard;
• уметь пересылать пакеты;
• иметь постоянный локальный IP или зарезервированный адрес DHCP;
• автоматически восстанавливать туннель после перезагрузки.

Если шлюз периодически выключается, доступ к внутренним ресурсам будет пропадать даже при полностью исправном VPS.

Определите минимально необходимый доступ

До настройки составьте таблицу ресурсов и разрешений:

Такая таблица поможет не создавать избыточные правила вида «разрешить всем доступ ко всей подсети».

Как связать VPS и сеть за CGNAT

Полную установку WireGuard, создание ключей и базовые правила подключения мы разбирали в статье «WireGuard на Linux VPS для сотрудников». Здесь рассмотрим параметры, которые нужны именно для маршрутизации сети за CGNAT.

Устанавливаем WireGuard

На Ubuntu или Debian пакет можно установить штатным менеджером:

sudo apt update
sudo apt install wireguard

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

Перед созданием ключей ограничьте права на новые файлы:

umask 077
wg genkey | tee privatekey | wg pubkey > publickey

Команда создаст два файла:

• privatekey — закрытый ключ;
• publickey — открытый ключ.

Закрытый ключ каждого узла должен оставаться только на этом узле.

Настраиваем WireGuard на VPS

Условная конфигурация файла /etc/wireguard/wg0.conf на VPS:

[Interface]
Address = 10.77.0.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_VPS>

[Peer]
PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_ЛОКАЛЬНОГО_ШЛЮЗА>
AllowedIPs = 10.77.0.2/32, 192.168.50.0/24

[Peer]
PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_УДАЛЕННОГО_КОМПЬЮТЕРА>
AllowedIPs = 10.77.0.10/32

Запись AllowedIPs = 10.77.0.2/32, 192.168.50.0/24 сообщает VPS, что локальный шлюз отвечает не только за свой адрес WireGuard, но и за внутреннюю сеть 192.168.50.0/24.

У разных участников WireGuard диапазоны AllowedIPs на VPS не должны пересекаться. Иначе сервер не сможет однозначно определить, какому участнику отправлять пакет.

Защитите конфигурацию:

sudo chmod 600 /etc/wireguard/wg0.conf

Настраиваем локальный шлюз

Конфигурация WireGuard на устройстве внутри офиса:

[Interface]
Address = 10.77.0.2/24
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ЛОКАЛЬНОГО_ШЛЮЗА>

[Peer]
PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPS>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.77.0.0/24
PersistentKeepalive = 25

Параметр PersistentKeepalive = 25 заставляет шлюз периодически отправлять служебный пакет. Это помогает сохранять запись NAT на роутере и оборудовании провайдера, даже когда полезного трафика временно нет.

Именно локальный шлюз указывает Endpoint VPS. Серверу не нужно знать внешний адрес домашнего или офисного подключения: локальный узел сам устанавливает соединение и может работать при смене адреса у провайдера.

Настраиваем удалённое устройство

Пример конфигурации удалённого компьютера:

[Interface]
Address = 10.77.0.10/32
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_УДАЛЕННОГО_КОМПЬЮТЕРА>

[Peer]
PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPS>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.77.0.0/24, 192.168.50.0/24
PersistentKeepalive = 25

Через туннель направляются только адреса WireGuard 10.77.0.0/24 и офисная сеть 192.168.50.0/24. Обычный интернет-трафик удалённого компьютера продолжает идти через его текущее подключение.

Эта схема не подменяет шлюз по умолчанию и не предназначена для перенаправления всего пользовательского трафика через VPS.

Включаем маршрутизацию

VPS и локальный шлюз должны пересылать IPv4-пакеты между интерфейсами. Текущее значение можно проверить командой:

sysctl net.ipv4.ip_forward

Значение 0 означает, что пересылка отключена, 1 — включена.

Временно включить маршрутизацию можно так:

sudo sysctl -w net.ipv4.ip_forward=1

Чтобы сохранить настройку после перезагрузки, создайте отдельный файл /etc/sysctl.d/99-ip-forward.conf со следующим содержимым:

net.ipv4.ip_forward=1

Затем примените параметры:

sudo sysctl --system

Настраиваем обратный маршрут

Допустим, локальный шлюз имеет адрес 192.168.50.2. Устройства внутренней сети должны знать, что адреса 10.77.0.0/24 доступны через него.

Предпочтительный вариант — добавить на основном офисном роутере статический маршрут:

Сеть назначения: 10.77.0.0/24
Шлюз: 192.168.50.2

Тогда внутренний сервер увидит настоящий адрес удалённого участника, например 10.77.0.10, и отправит ответ через локальный шлюз.

Если добавить маршрут на основном роутере невозможно, на локальном шлюзе можно применить source NAT или masquerade для трафика из туннеля. Внутренние устройства будут считать, что запрос пришёл от самого шлюза.

У такого решения есть недостатки:

• в журналах внутренних сервисов не будет реального адреса удалённого участника;
• сложнее создавать отдельные правила для разных пользователей;
• диагностика становится менее прозрачной.

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

Запускаем соединение

На Linux-узлах WireGuard можно включить командой:

sudo systemctl enable --now wg-quick@wg0

Проверить состояние:

sudo systemctl status wg-quick@wg0
sudo wg show

В выводе wg show обратите внимание на:

• latest handshake;
• объём принятого и переданного трафика;
• публичные ключи участников;
• разрешённые адреса;
• endpoint подключившегося узла.

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

Как ограничить доступ и не открыть всю сеть

Работающий туннель — только транспорт. Какие именно соединения разрешены, должен определять firewall.

Откройте на VPS только нужный порт WireGuard

Если используется UFW, входящий UDP-порт можно разрешить командой:

sudo ufw allow 51820/udp

Проверить действующие правила можно командой:

sudo ufw status verbose

Подробная работа с политиками firewall разобрана в статье «UFW или nftables на Ubuntu VPS».

Ограничьте пересылаемый трафик

Не создавайте без необходимости правило, которое разрешает любому участнику WireGuard обращаться ко всей сети 192.168.50.0/24.

Безопаснее разрешить конкретные направления:

10.77.0.10 → 192.168.50.10 → TCP 443
10.77.0.10 → 192.168.50.20 → TCP 22

Остальные соединения должны блокироваться политикой по умолчанию.

Точный синтаксис зависит от того, используется UFW, nftables или другой firewall. Важно, чтобы правила проверялись не только на VPS, но и на локальном шлюзе.

Не публикуйте внутренние сервисы напрямую

Если доступ организован через WireGuard, не нужно одновременно открывать в Интернет:

• веб-интерфейс NAS;
• RDP;
• SSH внутреннего сервера;
• административную панель роутера;
• интерфейс гипервизора;
• базу данных;
• панель видеонаблюдения.

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

Выдавайте отдельные ключи

Каждому пользователю и устройству нужна отдельная пара ключей.

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

При отзыве доступа достаточно удалить соответствующий блок [Peer] на VPS и применить конфигурацию.

Разделяйте пользовательский и административный доступ

Сотруднику, которому нужна внутренняя веб-панель, необязательно давать SSH-доступ к серверам. Аналогично администратору NAS может быть не нужен доступ к рабочим станциям.

Ограничения полезно реализовать сразу на нескольких уровнях:

• AllowedIPs определяет маршруты и допустимые адреса участника;
• firewall ограничивает направления и порты;
• сам внутренний сервис выполняет аутентификацию пользователя;
• журналы фиксируют успешные и отклонённые обращения.

Проверка работы и диагностика

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

Проверяем туннель до VPS

На VPS выполните:

sudo wg show

У локального шлюза и удалённого устройства должен появиться свежий latest handshake.

Если handshake отсутствует, проверьте:

• публичный адрес VPS;
• UDP-порт;
• правила firewall;
• соответствие открытых и закрытых ключей;
• доступность Интернета у локального узла;
• правильность Endpoint;
• запущен ли сервис wg-quick@wg0.

Также можно проверить, слушает ли VPS нужный UDP-порт:

sudo ss -lunp | grep 51820

Проверяем адрес локального шлюза

С удалённого компьютера сначала проверьте адрес WireGuard локального шлюза:

ping 10.77.0.2

Если 10.77.0.1 отвечает, а 10.77.0.2 — нет, проблема находится между VPS и локальным шлюзом. Проверьте AllowedIPs, forwarding и правила пересылки на VPS.

Отсутствие ответа на ping не всегда означает, что узел недоступен: ICMP может быть запрещён. Дополнительно проверяйте нужный прикладной порт.

Проверяем внутренний ресурс

Следующий шаг:

ping 192.168.50.10

Затем проверьте конкретный сервис. Например, HTTPS:

curl -I https://192.168.50.10

Если локальный шлюз доступен, а внутренний сервер — нет, проверьте:

• включена ли маршрутизация на локальном шлюзе;
• существует ли обратный маршрут;
• разрешает ли firewall пересылку между WireGuard и LAN;
• указан ли правильный адрес внутреннего сервера;
• отвечает ли сервис из самой локальной сети;
• не блокирует ли сервер подсеть WireGuard.

Проверяем маршруты

На Linux маршрут к офисной сети можно посмотреть командой:

ip route get 192.168.50.10

Трафик должен направляться через интерфейс WireGuard. Полную таблицу маршрутов можно вывести так:

ip route

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

Почему туннель работает, но ресурс не отвечает

Для проверки прохождения пакетов можно использовать tcpdump:

sudo tcpdump -ni wg0 host 192.168.50.10

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

Проверяем восстановление после перезагрузки

После успешной настройки убедитесь, что WireGuard запускается автоматически:

sudo systemctl is-enabled wg-quick@wg0

Также проверьте:

• сохранение net.ipv4.ip_forward=1;
• загрузку правил firewall;
• доступность локального шлюза;
• наличие маршрутов;
• работу внутреннего сервиса.

После запуска снова выполните:

sudo wg show
ip route
sudo systemctl status wg-quick@wg0

Затем проверьте не только handshake, но и реальное подключение к внутреннему ресурсу.

Заключение

Linux VPS с публичным IP позволяет организовать контролируемый доступ к домашней или офисной сети, даже если подключение находится за NAT или CGNAT. Локальный шлюз сам устанавливает исходящий туннель, поэтому принимать входящее соединение на адресе провайдера не требуется.

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

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

Что почитать дальше

Для подготовки и защиты серверной части пригодятся связанные материалы:

• WireGuard на Linux VPS для сотрудников — ключи, участники, адресация и базовая конфигурация WireGuard.
• Первичная настройка Ubuntu VPS после заказа — подготовка пользователя, SSH, обновлений и firewall.
• UFW или nftables на Ubuntu VPS — настройка сетевой политики и проверка правил.
• Как подключиться к Linux VPS по SSH — безопасное административное подключение и диагностика ошибок SSH.

Когда стоит обратиться к специалистам

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

Для внешней точки подключения можно использовать Linux VPS IPWAY. В зависимости от привычной серверной среды доступны VPS на Ubuntu и VPS на Debian.

Кратко

• DDNS обновляет адрес в DNS, но не создаёт входящий маршрут через CGNAT.
• VPS с публичным IP используется как промежуточная точка между удалённым устройством и закрытой локальной сетью.
• Соединение с VPS инициирует локальный шлюз, поэтому пробрасывать порт на стороне провайдера не требуется.
• Подсети WireGuard, офиса и удалённого пользователя не должны пересекаться.
• Для работы схемы нужны маршрутизация на VPS и локальном шлюзе, а также корректный обратный маршрут.
• Статический маршрут предпочтительнее NAT, поскольку сохраняет исходные адреса участников.
• Firewall должен разрешать только необходимые ресурсы и порты, а не всю внутреннюю сеть.
• После настройки нужно проверить handshake, маршруты, внутренний сервис и восстановление соединения после перезагрузки.