Почему адрес туннеля VPN не открывает входящий порт
Адрес туннеля идентифицирует ваш клиент для узлов, которые умеют маршрутизировать к нему, и никогда не создаёт слушателя. Проверьте привязку, обратный маршрут, затем политику.
Подключитесь к офисному VPN, запустите небольшой сервис на порту 8443, отправьте адрес туннеля коллеге и наблюдайте, как соединение не удаётся, пока клиент по-прежнему сообщает о подключении. В туннеле ничего не сломано: адрес выдан, сессия установлена, а пакеты, которые должны были бы нести ответ, просто никогда не пропускаются. Выполните три проверки ниже по порядку и остановитесь на той, которая не удалась, потому что у каждой своё исправление и только одна из них касается VPN.
Начните с того, куда на самом деле привязан сокет
Прежде чем что-либо будет маршрутизировано, что-то должно слушать адрес, до которого вызывающий может добраться. Серверы разработки — обычный виновник, потому что многие по умолчанию привязываются к loopback и принимают только соединения с той же машины. Адрес туннеля эту привязку не меняет, и операционная система откажет в соединении задолго до того, как VPN вообще будет задействован.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Читайте столбец локального адреса, а не состояние. 127.0.0.1:8443 означает только loopback, и исправление — привязка к 0.0.0.0 или к самому адресу туннеля. 0.0.0.0:8443 принимает на всех интерфейсах, что шире, чем большинство имеет в виду, когда у машины есть и публичный адрес; 10.64.7.15:8443 — узкая версия, которая слушает только там, куда может добраться коллега. Обратите внимание и на имя процесса в том же выводе, потому что забытый экземпляр из прошлого теста — частая причина того, что порт выглядит открытым и отвечает неверным содержимым.
Затем спросите, может ли что-нибудь маршрутизировать к этому адресу
Адрес туннеля имеет смысл только для узлов, настроенных отправлять этот префикс в туннель. У машины коллеги есть своя таблица, и если для подсети туннеля нет маршрута, пакет уходит на шлюз по умолчанию и погибает в месте, которое понятия не имеет о существовании адреса. Это вопрос маршрутизации на стороне вызывающего, а не разрешение на вашей стороне.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
Сервер между двумя клиентами значит не меньше. В обычной схеме удалённого доступа каждый клиент открывает исходящее соединение к шлюзу, и шлюз хранит состояние этих потоков, поэтому ответы возвращаются по уже известному ему пути. Соединение от одного клиента к другому — это новый поток, который шлюз должен принять и передать, и многие развёртывания намеренно отключают это, чтобы держать клиентов изолированными друг от друга. Потребительские VPN-сервисы обычно изолируют по умолчанию; корпоративные шлюзы иногда разрешают это по группам.
Проверьте направление, прежде чем что-то менять на хосте. Если адрес туннеля отвечает с самого шлюза, но не от узла-партнёра, разница в настройке клиент-к-клиенту на шлюзе, и никакая правка локального межсетевого экрана её не заменит.
Наконец, найдите политику, разрешающую поток
Между маршрутизируемым пакетом и отвечающим сервисом стоят три уровня политики: решение VPN-сервера о пересылке, межсетевой экран хоста и любая облачная группа безопасности перед экземпляром. Все три должны согласиться, и они отказывают по-разному, поэтому симптом из таблицы выше полезнее сообщения об ошибке в браузере.
Межсетевой экран хоста — тот уровень, о котором забывают после успешной привязки, потому что правило, разрешающее порт на интерфейсе LAN, не разрешает его автоматически на интерфейсе туннеля. Правила, ограниченные интерфейсом, — правильный дизайн и одновременно обычная причина сервиса, который работает из офиса, но не из дома. Читайте область действия правила, а не номер порта.
Фильтрация с учётом состояния объясняет обратный случай. Исходящее соединение с вашего ноутбука создаёт состояние, и ответы на него пропускаются без входящего правила. Соединение коллеги — совершенно новый поток без состояния за ним, поэтому ему нужно явное разрешение. Эта асимметрия и есть вся причина, по которой работающая сессия браузера на вашей машине ничего не говорит о доступности сервиса снаружи.
Когда одна проверка не удалась, меняйте дизайн, а не туннель
Если требование в том, чтобы коллега открыл ваш локальный сервис, честный ответ обычно — механизм, построенный для входящего доступа. Обратный SSH-туннель — самый маленький: ваша машина исходящим соединением подключается к хосту, до которого коллега уже может добраться, и слушатель существует на этом хосте.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Ретранслятору нужен GatewayPorts clientspecified в конфигурации SSH-сервера, иначе переданный слушатель привязывается к loopback на ретрансляторе, и коллега получает тот же отказ, что и раньше. Для всего, что живёт дольше одного дня, лучший инструмент — балансировщик нагрузки или ingress с проверкой состояния и сертификатом для опубликованного имени, а туннель между площадками с маршрутами для обеих подсетей — верный ответ, когда две сети действительно должны разговаривать.
Каждый из этих вариантов делает экспозицию явной, и в этом смысл. VPN перемещает пакеты между сетями, для которых вы уже были авторизованы; он не публикует сервис и не превращает ноутбук в хост, обращённый в интернет. Задача — решить, какой из трёх уровней менять, и туннель редко оказывается одним из них.