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

Что значит «подсеть через VPN» и зачем это нужно

Под выражением «подсеть через VPN» обычно понимают ситуацию, когда удалённый пользователь или филиал получает доступ к внутренней сети организации или дома через зашифрованный туннель. В отличие от простого VPN-подключения к одному серверу, здесь речь идёт о маршрутизации трафика к целой подсети (например, 192.168.2.0/24), которая находится за роутером или файерволом.

Такая схема нужна, когда требуется работать с NAS, системами видеонаблюдения, внутренними веб-интерфейсами, базами данных или другими ресурсами, которые не должны быть доступны из интернета напрямую. VPN позволяет «расширить» домашнюю или офисную сеть на любое устройство, где бы оно ни находилось.

Ключевое отличие от простого прокси или проброса портов — в том, что VPN даёт полноценный сетевой доступ: вы можете обращаться к любому IP-адресу внутри подсети, а не только к одному порту одного сервера. Это удобно и безопасно, так как все данные шифруются, а наружу не торчат никакие сервисы.

Основные схемы подключения к подсети

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

Схема 1: VPN-сервер на граничном роутере. В этом случае VPN-сервер работает на том же устройстве, которое является шлюзом для нужной подсети. Например, роутер MikroTik с белым IP-адресом принимает PPTP, L2TP или WireGuard-подключения, а затем маршрутизирует трафик клиента во внутреннюю сеть. Это самый простой вариант, если роутер поддерживает нужный протокол.

Схема 2: VPN-сервер за роутером. Если VPN-сервер находится не на граничном устройстве, а на отдельном хосте внутри сети, то на роутере необходимо пробросить порты для VPN-протокола и настроить маршрутизацию. Например, если VPN-сервер имеет адрес 192.168.88.2, а целевая подсеть — 192.168.2.0/24, то роутер должен знать, как доставить пакеты в эту подсеть.

Схема 3: VPN-туннель между двумя роутерами (site-to-site). Здесь два роутера (например, в офисе и дома) соединяются VPN-туннелем, и обе локальные сети становятся доступными друг другу. Это удобно для объединения филиалов или для доступа к домашней сети с работы.

Схема 4: VPN-сервер в облаке. Если у вас нет белого IP-адреса или вы хотите получить доступ к нескольким сетям, можно поднять VPN-сервер на VPS (например, WireGuard на Debian) и подключить к нему домашний роутер и клиентов. В этом случае VPS выступает в роли центрального хаба.

Маршрутизация: как пакеты попадают в нужную подсеть

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

Во-первых, на VPN-сервере (или на роутере, который принимает VPN-подключения) должен быть маршрут до целевой подсети. Например, если VPN-сервер находится в сети 192.168.88.0/24, а целевая подсеть — 192.168.2.0/24 за вторым роутером, то на первом роутере нужно прописать статический маршрут: 192.168.2.0/24 via 192.168.88.2.

Во-вторых, на втором роутере (к которому подключена целевая подсеть) должен быть обратный маршрут до VPN-клиентов. Если VPN-клиентам выдаются адреса из отдельной подсети, например 192.168.89.0/24, то на втором роутере нужно указать, что трафик в эту подсеть должен идти через первый роутер (шлюз 192.168.88.1).

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

Пример из практики: на MikroTik с белым IP-адресом уже работал PPTP-сервер, и доступ к первой сети (192.168.88.0/24) был настроен. Для доступа ко второй сети (192.168.2.0/24) потребовалось добавить статический маршрут на первом роутере и маршрут до VPN-подсети на втором, а также скорректировать правило NAT.

Выбор VPN-протокола: PPTP, L2TP, IPsec, WireGuard

От выбора протокола зависит безопасность, скорость и сложность настройки.

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

L2TP/IPsec — более безопасный, но требует настройки IPsec и часто блокируется в некоторых сетях из-за использования UDP-портов 500 и 4500.

IPsec (IKEv2) — современный стандарт, хорошо поддерживается на большинстве устройств, включая Windows, Android и iOS. Обеспечивает высокую безопасность и стабильность.

WireGuard — относительно новый протокол, который набирает популярность благодаря простоте настройки, высокой скорости и современной криптографии. Он работает поверх UDP и легко проникает через NAT, если настроен PersistentKeepalive. WireGuard идеально подходит для подключения домашней сети к VPS и для доступа с мобильных устройств.

При выборе протокола учитывайте совместимость с вашим оборудованием. Например, MikroTik поддерживает PPTP, L2TP, IPsec и WireGuard (в новых версиях). OpenWRT поддерживает WireGuard, OpenVPN и другие. Для корпоративного использования чаще выбирают IPsec или WireGuard.

Настройка VPN-сервера на MikroTik для доступа к двум подсетям

Рассмотрим практический пример, когда на роутере MikroTik с белым IP-адресом уже настроен PPTP-сервер для доступа к основной сети 192.168.88.0/24, и требуется открыть доступ к дополнительной подсети 192.168.2.0/24, которая находится за вторым роутером.

Для этого необходимо:

1. На первом роутере добавить статический маршрут до сети 192.168.2.0/24 через IP-адрес второго роутера (например, 192.168.88.2).
2. На втором роутере добавить маршрут до VPN-подсети (например, 192.168.89.0/24) через первый роутер (192.168.88.1).
3. Убедиться, что на втором роутере нет NAT для трафика из VPN-подсети, иначе пакеты будут маскироваться и не смогут вернуться к клиенту. Правило NAT должно исключать подсеть 192.168.89.0/24.
4. Настроить пул адресов для VPN-клиентов. Лучше выделить отдельную подсеть, например 192.168.89.0/24, чтобы не конфликтовать с существующими сетями.
5. В настройках PPTP-сервера указать локальный адрес (например, 192.168.89.1) и пул удалённых адресов (192.168.89.2-192.168.89.255).

После этого VPN-клиент, подключившись к первому роутеру, получит адрес из подсети 192.168.89.0/24 и сможет обращаться к устройствам в обеих сетях — 192.168.88.0/24 и 192.168.2.0/24.

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

Особенности настройки Windows-клиентов и проблемы с классовой адресацией

При подключении к VPN с помощью встроенного клиента Windows могут возникать проблемы с маршрутизацией, связанные с так называемой «классовой адресацией». Windows автоматически добавляет маршруты для сетей класса A, B или C в зависимости от IP-адреса, выданного VPN-сервером.

Например, если VPN-клиент получает адрес из диапазона 192.168.x.x, Windows может автоматически добавить маршрут для всей подсети 192.168.x.0/24 через VPN-интерфейс. Это может быть удобно, но иногда приводит к конфликтам, если локальная сеть клиента использует тот же диапазон.

Чтобы избежать проблем, рекомендуется использовать для VPN-подсети адреса из диапазона 172.16.0.0/12 или 10.0.0.0/8, так как Windows по-разному обрабатывает эти диапазоны. Например, если VPN-клиент получает адрес 172.16.100.5, Windows автоматически добавит маршрут для всей сети 172.16.0.0/16 через VPN, что позволит получить доступ ко всем подсетям внутри этого диапазона.

Если же вы используете адреса 192.168.x.x, возможно, потребуется вручную прописывать маршруты на стороне клиента. Например, для доступа к сети 192.168.2.0/24 через VPN-сервер с адресом 192.168.89.1 нужно выполнить команду:

route add 192.168.2.0 mask 255.255.255.0 192.168.89.1 metric 1 -p

Также важно проверить, не установлен ли на VPN-подключении флажок «Использовать основной шлюз в удаленной сети». Если он снят, то маршруты по умолчанию не будут добавляться, и доступ к удалённой подсети может не работать без ручной настройки.

Подключение домашней сети к VPS через WireGuard

Если у вас нет белого IP-адреса или вы хотите получить доступ к домашней сети из любой точки мира, удобно использовать VPS в качестве VPN-сервера. Рассмотрим схему с WireGuard, которая описана в одном из источников.

Вам понадобится:

• VPS (например, на Debian) с установленным WireGuard.
• Домашний роутер с поддержкой OpenWRT или любым другим VPN-клиентом.
• Мобильные устройства с установленным приложением WireGuard.

На VPS создаётся конфигурация, в которой задаётся VPN-подсеть (например, 192.168.99.0/24) и ключи для каждого пира. Для домашнего роутера в AllowedIPs указывается не только его собственный адрес, но и домашняя подсеть (например, 192.168.0.0/24). Это позволяет маршрутизировать трафик к домашним устройствам через роутер.

На роутере OpenWRT устанавливается пакет luci-app-wireguard, создаётся интерфейс wg0, указываются приватный ключ, адрес из VPN-подсети, публичный ключ VPS и его endpoint. Важно включить PersistentKeepalive, чтобы туннель не обрывался из-за NAT.

После настройки роутера и клиентов вы сможете с телефона или ноутбука обращаться к любому устройству в домашней сети, например, к NAS или веб-интерфейсу роутера, как будто вы находитесь дома.

Преимущества такого подхода:

• Не нужно пробрасывать порты на домашнем роутере.
• Весь трафик шифруется.
• Можно получить доступ к нескольким сетям, если настроить несколько пиров.

VPN-туннель в облаке: пример с VK Cloud и StrongSwan

Для организации VPN-туннеля между локальной сетью и облачной инфраструктурой можно использовать IPsec-решение на базе StrongSwan. В документации VK Cloud описан пример, где создаются две сети: клиентская (имитирует on-premises) и виртуальная (в облаке). Между ними поднимается VPN-туннель.

Основные шаги:

1. Создаются сети и подсети с определёнными диапазонами (например, 172.16.0.0/29 и 10.0.0.0/29).
2. В клиентской сети создаётся виртуальная машина, которая будет выступать VPN-шлюзом. На неё устанавливается StrongSwan.
3. В облачной сети создаётся VPN-туннель с параметрами IKE и IPsec (например, AES-256, SHA-256, DH group 14).
4. Настраивается StrongSwan на клиентском шлюзе: указываются left/right, подсети, PSK-ключ.
5. Добавляются статические маршруты: в облачной подсети — до клиентской сети, в клиентской — до облачной.
6. Проверяется связность с помощью ping между виртуальными машинами.

Важно отключить IP Source Guard для порта VPN-шлюза, чтобы он мог пересылать трафик с любыми адресами. Также необходимо включить IP forwarding на Linux-машине.

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

Типичные ошибки и способы их устранения

При настройке доступа к подсети через VPN часто возникают следующие проблемы:

1. VPN-клиент подключается, но не видит устройства в удалённой подсети. Причины: отсутствуют маршруты на одной из сторон, NAT маскирует трафик, файервол блокирует пакеты. Проверьте таблицы маршрутизации на всех роутерах и убедитесь, что NAT не применяется к VPN-трафику.

2. Конфликт IP-адресов. Если локальная сеть клиента и удалённая подсеть используют один и тот же диапазон (например, 192.168.1.0/24), маршрутизация может работать некорректно. Решение — изменить адресацию одной из сетей или использовать более специфичные маршруты.

3. VPN-туннель нестабилен, периодически обрывается. Для протоколов, работающих поверх UDP (WireGuard, IPsec), необходимо настроить keepalive (PersistentKeepalive для WireGuard, DPD для IPsec). Также проверьте, не блокирует ли провайдер нужные порты.

4. Нет доступа к ресурсам за вторым роутером. Убедитесь, что на втором роутере есть обратный маршрут до VPN-подсети и что файрвол разрешает трафик из VPN. Также проверьте, не включён ли на втором роутере NAT для трафика из VPN-подсети.

5. Windows-клиент не может получить доступ к нескольким подсетям. Проблема может быть связана с автоматической маршрутизацией. Используйте отдельную VPN-подсеть из диапазона 172.16.0.0/12 или 10.0.0.0/8, либо пропишите статические маршруты вручную.

Безопасность и рекомендации

Организация доступа к подсети через VPN требует внимания к безопасности.

• Используйте современные протоколы: WireGuard или IPsec (IKEv2) вместо PPTP.
• Применяйте надёжные ключи шифрования и PSK-фразы длиной не менее 16 символов.
• Ограничьте доступ к VPN-серверу по IP-адресам, если это возможно.
• Настройте файрвол таким образом, чтобы из VPN-подсети был доступен только необходимый минимум сервисов.
• Регулярно обновляйте прошивки роутеров и операционные системы VPN-серверов.
• Для корпоративных сетей используйте сертификаты и двухфакторную аутентификацию.

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

Вопросы и ответы