VPN нужно выбирать под конкретный сценарий: связь филиалов, доступ сотрудников или подключение подрядчика к одному сервису. Протокол туннеля не определяет автоматически права, маршруты, DNS или наличие многофакторной аутентификации. Даже установленный защищённый канал может доставлять трафик не туда или давать слишком широкий доступ.
Разберём технические отличия распространённых решений и порядок пилота. Статья описывает выбор и проверку архитектуры; для настройки конкретного сервера нужны инструкции под его ОС и реализацию.
1. Сначала определить сценарий и границы доступа
Для site-to-site выпишите сети обеих площадок, отсутствие пересечений, адреса WAN, наличие NAT и требуемые сервисы. Для remote access укажите клиентские ОС, способ выдачи доступа, маршруты, DNS и процесс увольнения пользователя. Для подрядчика определите адреса и порты, которые действительно нужны.
Решите, нужен ли полный туннель с выходом в интернет через компанию или split tunnel с маршрутами только к корпоративным сетям. У split tunnel есть зависимость от клиентской маршрутизации и локального окружения; у полного — нагрузка на шлюз и влияние на обычный интернет пользователя.
Пример требования: Windows-ноутбук получает маршрут только к 10.20.0.0/24, разрешённый HTTPS-сервис расположен на 10.20.0.10:443. Формулировка «дать VPN» вместо такой записи не задаёт границу доступа.
2. Чем шифрование отличается от туннелирования
Туннелирование переносит один пакет внутри другого. Шифрование защищает содержимое, а аутентификация подтверждает сторону соединения. Проверка прав решает, куда этой стороне можно обращаться. Это разные механизмы.
Например, L2TP сам по себе не обеспечивает нужную защиту содержимого, поэтому обычно используется с IPsec. WireGuard совмещает защищённый туннель с моделью ключей peer. OpenVPN использует TLS для организации защищённого соединения, но его возможности зависят от конкретной реализации и настроек.
HTTPS внутри VPN всё равно нужен для защиты приложения и проверки его сервера. VPN не отменяет права в приложении, фильтрацию межсетевым экраном и защиту конечного устройства.
3. WireGuard: ключи, peer и маршруты
WireGuard работает поверх UDP и использует пары ключей. В конфигурации peer параметр AllowedIPs участвует в выборе получателя и проверке адресов источника. Его не нужно путать с полноценным пользовательским ACL по портам.
В Linux утилита wg-quick может строить маршруты по AllowedIPs, а RouterOS требует проверить собственные IP-маршруты. Поведение зависит от инструмента управления. Основы и keepalive описаны в официальном Quick Start WireGuard, особенности MikroTik — в документации RouterOS.
Для диагностики Linux:
sudo wg show
ip route get 10.20.0.10Проверьте peer, endpoint, время handshake, счётчики и выбранный маршрут. Не публикуйте конфигурацию с PrivateKey или PresharedKey. PersistentKeepalive может поддерживать NAT-состояние на стороне, которая должна принимать пакеты после простоя; он не исправляет неверные маршруты.
WireGuard сам по себе не предоставляет пользовательский вход с паролем и встроенную MFA-процедуру. Для корпоративных пользователей нужны управление устройствами и ключами либо отдельная платформа контроля доступа. После потери ноутбука удаление peer должно быть частью понятного процесса.
4. IKEv2/IPsec: сертификаты и совместимость
IKEv2 согласует параметры и ключи IPsec. Важно разделять управление соединением и передачу защищённых данных. Для NAT-T обычно используется UDP 4500; начальное согласование — UDP 500. Без NAT может передаваться ESP, то есть IP-протокол 50, а не TCP или UDP-порт 50.
Корпоративное внедрение требует проверки сертификатов, доверенных центров, способов аутентификации и совместимости политик клиента и сервера. Общий PSK, клиентский сертификат и EAP-сценарий решают разные задачи; поддержку MFA нельзя вывести только из названия IKEv2.
Для встроенного клиента Windows и RRAS IKEv2 — один из современных вариантов; документация Microsoft рекомендует более современные протоколы вместо PPTP/L2TP. На другом VPN-шлюзе сверяйте его поддерживаемые сочетания алгоритмов и аутентификации.
5. OpenVPN: UDP, TCP и отдельный клиент
OpenVPN допускает разные транспортные режимы. UDP обычно выбирают для производительности, TCP может быть полезен при ограничениях сети, но перенос TCP внутри TCP способен ухудшать работу при потерях. Это не означает, что TCP всегда запрещён; выбор проверяют на реальном канале. Различия описаны в документации OpenVPN.
Обычно нужен отдельный клиент и профиль подключения. Проверьте актуальную версию, проверку сертификата сервера, поддерживаемые алгоритмы и способ отзыва доступа. Возможности OpenVPN Community, Access Server и встроенной реализации на маршрутизаторе не одинаковы.
Пилот должен включать TCP-приложение, UDP-приложение при наличии, длительное соединение и работу после смены сети. Если UDP блокируется, проверяйте доступные транспортные режимы сервера, а не просто заменяйте номер порта в профиле. Пошаговая подготовка профилей — в Creating Configuration Files.
6. L2TP/IPsec, PPTP и значение SSL VPN
L2TP/IPsec часто сохраняют ради совместимости действующего окружения. В нём есть отдельные этапы: IPsec, L2TP и PPP-аутентификация. Неправильный PSK и неверный пользовательский пароль приводят к разным отказам; диагностика должна различать эти этапы.
PPTP не выбирайте для нового корпоративного внедрения. Microsoft не рекомендует PPTP/L2TP для новых развёртываний RRAS; начиная с Windows Server 2025 новые настройки RRAS по умолчанию не принимают такие подключения. Это ограничение RRAS, а не утверждение, что клиент Windows больше не может подключаться к L2TP на MikroTik.
«SSL VPN» — общее название класса решений. Уточняйте продукт, версию, транспорт, клиент и методы входа. SSTP, OpenVPN и веб-портал доступа нельзя считать одной и той же конфигурацией только из-за использования TLS.
7. Как проверить маршруты и DNS после подключения
На Windows сначала подтвердите используемый профиль:
Get-VpnConnection |
Select-Object Name, TunnelType, ConnectionStatus, SplitTunneling
Get-NetRoute -AddressFamily IPv4 |
Select-Object DestinationPrefix, NextHop, InterfaceIndex, RouteMetricНаличие туннеля не заменяет маршрут к нужной сети. Проверьте, не совпадают ли корпоративная и домашняя подсети и нет ли более специфичного маршрута в неправильный интерфейс.
Для примера разрешённого HTTPS-сервиса:
Test-NetConnection -ComputerName 10.20.0.10 -Port 443
Resolve-DnsName app.corp.exampleЗдесь адрес и имя демонстрационные. TCP-проверка не измеряет доступность UDP-порта VPN и не проверяет вход в приложение. Если по IP сервис доступен, а по имени нет, исследуйте внутренний DNS. Если запрос DNS отправляется локальному провайдеру вместо корпоративного сервера, настройте согласованную DNS-политику профиля, а не вручную меняйте DNS всех адаптеров.
8. Как проверить firewall и реальную изоляцию
Опишите нужный путь: VPN-пул или peer → разрешённый сервер → порт приложения. Для маршрутизируемого транзита проверяйте forward, а для подключения к самому VPN-шлюзу — input. Разрешение транспортного порта не означает разрешение доступа к LAN.
Протестируйте положительный и отрицательный сценарии. Разрешённый сервис должен открываться, соседний административный интерфейс — оставаться недоступным. Проверка только положительного сценария не обнаружит случайный accept для всей внутренней сети.
Для split tunnel проверьте, что маршруты не расширены до 0.0.0.0/0 без необходимости. Для IPv6 отдельно определите, какой трафик проходит через VPN, какой остаётся вне его и какие правила применяются. IPv4-профиль не формирует автоматически такую же IPv6-политику.
9. Как проводить пилот и измерять производительность
Сравнивайте протоколы при одинаковом устройстве, канале, нагрузке и проверяемом приложении. Запишите задержку, потери, нагрузку CPU шлюза, скорость полезной передачи и поведение после простоя. Не обещайте универсальное превосходство в процентах без измерений.
Если соединение устанавливается, а крупные ответы зависают, проверьте MTU, PMTUD и повторные передачи. Не снижайте MSS случайным числом на всех интерфейсах. Изменение должно соответствовать конкретному туннелю и подтверждённой проблеме.
Добавьте сценарий отзыва доступа: отключённый пользователь или удалённый peer больше не подключается. Проверьте, что старые сессии завершаются предусмотренным способом и что журналы позволяют установить, кто и когда получил доступ.
10. Как принять решение и спланировать переход
Для связи двух управляемых MikroTik можно начать пилот WireGuard, если подходит UDP и ключевая модель. Для корпоративного доступа с существующей инфраструктурой сертификатов оцените IKEv2. Если важны отдельный клиент, поддерживаемая интеграция аутентификации и транспортные варианты, изучите конкретную платформу OpenVPN. Это исходные гипотезы, которые подтверждаются совместимостью и тестами.
При миграции оставьте контролируемый период сравнения, экспорт старых параметров и способ возврата. Не включайте одновременно два профиля с конфликтующими маршрутами. После приёмки отзовите старые доступы и удалите ненужные правила.
Настройка VPN считается завершённой после проверки маршрутов, DNS, разрешений, отзыва доступа и рабочих приложений. Для проектирования схемы под вашу инфраструктуру обратитесь в АВАНГАРД ИТ.
Нужно выбрать и настроить корпоративный VPN?
Подходящий протокол зависит от модели угроз, клиентских устройств, сетевой схемы и требований к доступу.