Сотрудник работает из дома и открывает внутреннюю систему компании, которая не опубликована в Интернете. Филиал передаёт данные в центральный офис через обычного провайдера. Администратор подключается к серверу через управляемую сеть доступа, сохраняя закрытыми RDP и SSH на внешнем адресе. Эти задачи объединяет VPN: поверх существующей связи создаётся логический канал между определёнными участниками.
В повседневной речи под VPN обычно понимают зашифрованный туннель. Но виртуальная частная сеть шире шифрования: некоторые операторские VPN изолируют маршруты клиентов без самостоятельного шифрования полезных данных. Дальше рассмотрим защищённый IP-туннель, который чаще всего нужен компании для удалённого доступа. Его работа складывается из аутентификации, передачи пакетов, маршрутизации и правил доступа. Если забыть хотя бы один слой, можно получить зелёный значок подключения и неработающее приложение.
Два адреса назначения и два маршрута одного пакета
Представим ноутбук с VPN-адресом 10.250.0.7, корпоративный шлюз с внешним адресом 203.0.113.10 и сервер приложения 10.20.0.15. Внешний адрес из диапазона документации здесь служит примером; в реальной сети используют адрес своего шлюза. Пользователь открывает HTTPS-приложение на внутреннем сервере.
Операционная система сначала создаёт обычный пакет: источник 10.250.0.7, назначение 10.20.0.15, порт назначения TCP 443. По таблице маршрутизации он попадает в VPN-интерфейс. VPN защищает внутренний пакет и помещает его во внешнюю оболочку, адресованную 203.0.113.10. Домашний маршрутизатор и провайдер передают внешнюю оболочку, а не маршрутизируют адрес 10.20.0.15 через Интернет.
Шлюз проверяет подлинность полученного пакета, расшифровывает его и отправляет внутреннему серверу. На обратном пути сервер должен знать, как доставить ответ сети 10.250.0.0/24. Если такого маршрута нет, ответ уйдёт через другой шлюз или будет отброшен. Успешное установление туннеля не создаёт маршруты во всех внутренних подсетях автоматически.
| Участок | Какой пакет передаётся | Кто принимает решение |
|---|---|---|
| Приложение → VPN-интерфейс | Внутренний IP-пакет | Таблица маршрутов клиента |
| Клиент → внешний шлюз | Защищённая внешняя оболочка | Домашний роутер и провайдер |
| VPN-шлюз → сервер | Расшифрованный внутренний пакет | Маршруты и firewall компании |
| Сервер → VPN-клиент | Ответ внутреннему адресу | Обратный маршрут или согласованный NAT |
Наличие IP-туннеля не отменяет защиту приложения. Если HTTPS заканчивается на сервере, его TLS остаётся отдельным слоем поверх VPN. Если же внутри туннеля передавался незашифрованный HTTP, после выхода из VPN-шлюза HTTP снова будет незашифрованным. Архитектура IPsec отдельно описывает границы защиты на IP-уровне в RFC 4301.
Аутентификация, ключи и разрешения — разные решения
До передачи данных стороны должны установить, с кем они разговаривают. В разных решениях используются сертификаты, пары ключей, учётные записи, второй фактор и комбинации этих средств. Аутентификация отвечает на вопрос о личности пользователя или устройства. Шифрование защищает содержимое, контроль целостности помогает обнаружить подмену, а защита от повторов — повторно переданный старый пакет.
Установленная защищённая сессия не означает, что участнику разрешены все корпоративные ресурсы. Например, сотруднику бухгалтерии нужен доступ к определённому приложению, а подрядчику — к одному серверу на согласованный срок. Эти разрешения задаются политикой шлюза, межсетевыми правилами и самим приложением. Публичный ключ устройства не заменяет должностную роль пользователя.
| Свойство | Что обеспечивает | Чего не обеспечивает |
|---|---|---|
| Проверка сертификата или ключа | Идентичность участника | Автоматическое разрешение всех ресурсов |
| Шифрование | Скрытие содержимого на защищённом участке | Защиту заражённого ноутбука |
| Контроль целостности | Выявление изменённых защищённых сообщений | Правильность запроса приложения |
| MFA | Дополнительное подтверждение входа | Безопасность уже похищенной активной сессии |
| ACL и сегментация | Ограничение достижимых сервисов | Корректность файлов, переданных пользователем |
| Журналирование | Следы подключения и событий | Восстановление потерянных данных |
Администратору нужен жизненный цикл доступа: выдача, изменение, отзыв и проверка действующих подключений. Увольнение сотрудника требует отключить доступ и отозвать его средства аутентификации; удаления ярлыка на ноутбуке недостаточно. Если применяется WireGuard, сам протокол идентифицирует peer по публичному ключу, а пользовательские роли и MFA строятся дополнительной системой управления. Этот принцип описан в документации WireGuard.
Split tunnel и full tunnel: какие данные пойдут через компанию
При split tunnel через VPN направляются выбранные сети, например 10.20.0.0/16, а обычный Интернет остаётся через домашнего провайдера. Это экономит полосу корпоративного шлюза и снижает задержки для внешних сервисов. Но администратор должен понимать, что устройству одновременно доступны корпоративная и внешняя сеть; политики защиты конечной точки сохраняют значение.
При full tunnel через корпоративный выход направляется весь предусмотренный политикой трафик. Для IPv4 это обычно маршрут по умолчанию или эквивалентные более специфичные маршруты; IPv6 нужно настроить отдельно. Добавление только 0.0.0.0/0 не описывает судьбу IPv6. DNS и доступ к локальной сети также зависят от клиента и политики.
| Сценарий | Обычно подходит | Что продумать |
|---|---|---|
| Доступ к нескольким внутренним приложениям | Split tunnel | Нужные сети, корпоративный DNS, ограничения клиента |
| Единая политика выхода и фильтрации | Full tunnel | Пропускная способность, IPv6, отказ шлюза |
| Связь филиалов | Маршруты между площадками | Непересекающиеся подсети и обратный путь |
| Доступ подрядчика к одному сервису | Узкая сеть или ресурсная политика | Срок, отдельная роль, журнал и отзыв |
Домашняя сеть 192.168.1.0/24 и такая же подсеть внутри компании создают конфликт. Клиент может считать корпоративный сервер локальным соседом и посылать ARP вместо передачи через VPN. Два разных устройства тогда имеют одинаковые адреса с точки зрения клиента. Планирование непересекающихся диапазонов предпочтительнее постоянных обходов NAT. Если перенумерация невозможна, нужна явно разработанная схема трансляции или публикации конкретного сервиса.
Протокол также не решает выбор маршрута сам по себе. В WireGuard AllowedIPs участвует в выборе peer и проверке внутренних адресов, а попадание трафика на интерфейс определяется маршрутизацией ОС; автоматическое создание маршрутов зависит от инструмента настройки. В IPsec могут использоваться политики выбора трафика или отдельные маршрутизируемые интерфейсы. Поэтому в диагностике всегда смотрят и состояние протокола, и маршруты.
DNS: почему по адресу работает, а по имени нет
VPN-приложение может быть доступно по IP, но не открываться по имени crm.corp.example. Для разрешения имени нужен DNS-сервер, знающий корпоративную зону, и корректная политика отправки запроса к нему. Обычный домашний DNS такой зоны не знает. Использование одного публичного DNS для всех запросов не исправит внутреннее имя.
На Windows проверьте адреса DNS интерфейсов и отдельно запрос к корпоративному серверу. 10.20.0.53 и имя ниже — примеры:
Get-DnsClientServerAddress
Resolve-DnsName crm.corp.example -Server 10.20.0.53
Resolve-DnsName crm.corp.exampleПервый запрос проверяет конкретный сервер, второй — обычный выбор резолвера системы. Если явный запрос успешен, а обычный нет, исследуйте выбор DNS, suffix и правила split DNS. Если не работает и явный, сначала проверьте маршрут и доступность сервера; изменение приоритета DNS не откроет заблокированный порт.
В Linux с systemd-resolved:
resolvectl status
resolvectl query crm.corp.example
ip route get 10.20.0.53В системах без resolved используйте nslookup или dig, учитывая реальное устройство /etc/resolv.conf и DNS-менеджера. Не редактируйте генерируемый файл вслепую: NetworkManager может переписать его. Для split DNS важно, какой интерфейс обслуживает конкретный домен, а не только порядок серверов в списке.
DNS-имя не доказывает доступность приложения, а успешный ping не доказывает открытый TCP-порт. Проверки нужно разделять, чтобы не менять сеть из-за ошибки сертификата или учётной записи.
Диагностика: от интерфейса до приложения
Сравните состояние до подключения и после. На Windows:
Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.0.15
Test-NetConnection 10.20.0.15 -Port 443Find-NetRoute показывает выбранный интерфейс и источник для нужного адреса, а Test-NetConnection проверяет попытку TCP-соединения. Если маршрут выбран через Wi-Fi вместо VPN, искать причину в веб-приложении рано. Успешный TCP-connect тоже не означает успешный вход в приложение.
На Linux аналогичная последовательность:
ip -br address
ip route get 10.20.0.15
ip rule show
ping -c 3 10.20.0.15
curl --connect-timeout 5 --max-time 15 https://crm.corp.example/ip rule нужен при нескольких таблицах маршрутизации: вывод одной основной таблицы бывает недостаточен. Отказ ping может быть следствием запрета ICMP, поэтому не останавливайте диагностику только на нём. При ошибке TLS проверьте имя, время и доверенный сертификат, не отключая проверку через -k как постоянное решение.
| Этап | Успешный признак | Если неудача |
|---|---|---|
| Внешний транспорт | Шлюз достижим, есть ответы протокола | Провайдер, firewall, endpoint, NAT |
| Аутентификация | Установлена сессия или свежий handshake | Ключи, сертификат, часы, MFA |
| Маршрутизация клиента | Нужное назначение идёт в туннель | Профиль, пересечение сетей, таблицы |
| Передача на шлюзе | Есть счётчики и правильная политика | Forwarding, ACL, traffic selectors |
| Обратный путь | Ответ приходит в VPN-пул | Внутренние маршруты или NAT |
| DNS и приложение | Имя разрешается, TCP/TLS и вход работают | Резолвер, сертификат, права приложения |
На шлюзе не добавляйте безусловный ACCEPT между VPN и всей локальной сетью ради одного теста. Проверьте существующие правила и счётчики, затем разрешите необходимое назначение и порт. Если применяется NAT, он скрывает исходный адрес клиента от внутреннего сервера; это может упростить обратный путь, но меняет журналирование и возможность различать участников.
MTU, задержки и почему большой файл зависает
Туннель добавляет заголовки и криптографические данные. Внешний пакет становится больше внутреннего. Если канал допускает 1500 байт, нельзя считать, что внутренний пакет размером 1500 пройдёт без дополнительной обработки. Размер накладных данных зависит от протокола, IPv4/IPv6, транспорта и согласованных алгоритмов.
Типичный симптом проблемы MTU: handshake работает, небольшой ping проходит, а сайт зависает на загрузке или файл передаётся плохо. Если сообщения о необходимости уменьшить размер блокируются, Path MTU Discovery не помогает конечным точкам найти допустимый размер. При TCP также учитывают MSS — максимальный размер полезных данных TCP-сегмента.
На Linux можно исследовать путь и пробовать размер IPv4-пакета без фрагментации:
tracepath 10.20.0.15
ping -4 -M do -s 1300 -c 3 10.20.0.151300 — стартовое диагностическое значение, не универсальная настройка MTU. У IPv4 ping к полезной нагрузке добавляются заголовки IP и ICMP, обычно 28 байт без опций. Найдите границу на контролируемом пути и сопоставьте её с реальной инкапсуляцией. Отсутствие ответа ещё не доказывает превышение MTU: ICMP могут запрещать независимо от размера.
Скорость ограничивается не только шифрованием. Влияют RTT, потери, загрузка процессора и криптоускорение шлюза, скорость обоих провайдеров, число одновременных потоков и диски приложения. Для сравнения используйте одинаковые условия и контролируемый iperf3 внутри туннеля, а не разные публичные speedtest-серверы. Пробный сервер iperf3 должен быть доступен только тестовым участникам.
Что VPN скрывает и где остаются риски
На защищённом участке провайдер обычно не видит содержимое внутренних пакетов, но видит внешний адрес шлюза, время и объём обмена. Компания или коммерческий оператор выхода может наблюдать доступную ему сетевую информацию. HTTPS продолжает защищать содержимое приложения до своего TLS-терминатора. VPN не делает пользователя анонимным для сайтов, в которые он вошёл под собственной учётной записью.
Заражённый ноутбук получает доступ к разрешённым ресурсам так же, как легитимное устройство. Поэтому корпоративный VPN дополняется обновлениями конечных точек, защитой от вредоносного ПО, MFA, ограничением ресурсов и журналированием. Пароль нельзя заменять общим ключом, который передают всем сотрудникам без учёта владельца и возможности индивидуального отзыва.
При приёмке проверяйте не только соединение, но и поведение при разрыве: какие приложения продолжат работать напрямую, куда пойдут DNS-запросы, останется ли внешний IPv6 и восстановится ли профиль после смены Wi-Fi на мобильную сеть. Сохраните протокол проверки VPN с маршрутом, DNS, нужным приложением, результатом отказа и отзывом доступа. Рабочий VPN — это предсказуемая доставка разрешённых данных между проверенными участниками, а не один значок «подключено».