На каких портах на самом деле слушает OpenVPN Access Server?
Пройдите по списку сокетов на хосте Access Server: узнайте стандартные слушатели, отличите loopback от опубликованных портов и проверьте перенаправление, прежде чем закрывать порт.
Вы запускаете ss -lntup на хосте Access Server и получаете список вдвое длиннее ожидаемого. Половина записей — это порты в форме демонов, о которых никто не упоминал при установке. Рефлекс — закрыть всё, что не 443 и не 1194, и именно так люди ломают собственный клиентский портал.
Access Server — это не один слушатель. Это VPN-сервис, веб-сервис и участник кластера, и он может создавать дополнительные порты, специфичные для демонов, и перенаправления брандмауэра в зависимости от того, сколько демонов TCP вы настроили.
Пройдите по инвентарю по порядку: прочитайте сокеты, сопоставьте знакомые, классифицируйте остальные по владельцу и привязке, а затем проверьте, что именно их публикует.
Начните с одной команды только для чтения
sudo ss -lntup даёт вам транспорт, локальный адрес, порт и процесс-владелец для каждого слушающего сокета. Флаги важны: -l прослушивание, -n числовой, -t TCP, -u UDP, -p процесс. Без root вы получите сокеты, но не имена процессов, а это именно тот столбец, который нужен для классификации.
Запишите четыре поля на строку, прежде чем формировать мнение: протокол, адрес привязки, порт и команду. Держите версию Access Server и настроенное число демонов рядом с этим списком, потому что оба меняют ожидаемое.
Две строки, которые выглядят одинаково, не одинаковы. TCP и UDP на одном номере — это отдельные сокеты с отдельной экспозицией, а 0.0.0.0 и :: — отдельные привязки для отдельных семейств адресов. Сервис, привязанный только к 127.0.0.1 , не доступен напрямую с другого хоста, хотя локальное перенаправление всё ещё может его опубликовать.
Слушатели, которые вы должны узнавать
Эти значения по умолчанию покрывают большинство развёртываний и дают базовую линию для сравнения. Это значения по умолчанию, а не полный список разрешённых.
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
Всё сверх этого требует объяснения, а не предположения. Вы часто будете видеть только локальные слушатели, принадлежащие компонентам, которые продукт устанавливает для себя. Подтверждайте их через PID и конфигурацию сервиса, а не по запомненному номеру порта, и не считайте незнакомый порт враждебным только из-за незнакомости.
Сокет вне знакомой пары тоже не обязательно остаток. Когда настроено несколько демонов TCP, Access Server создаёт слушатели для каждого демона и перенаправляет трафик к ним, поэтому их количество и значения портов следуют этой конфигурации.
Классифицируйте, прежде чем что-либо закрывать
Для каждой неясной строки ответьте на три вопроса в этом порядке.
- Владелец и назначение. Сопоставьте PID с юнитом или процессом и прочитайте конфигурацию этого сервиса. Если вы не можете назвать владельца, вы не готовы решать что-либо о сокете.
- Область привязки. Loopback локален для пространства имён. Привязка wildcard доступна только если это разрешают маршрутизация, фильтрация хоста и любые правила на уровне облака, поэтому адрес привязки необходим, но недостаточен. Проверяйте IPv4 и IPv6 как отдельные решения.
- Опубликованный путь. Ищите перенаправление сервиса, перенаправления, специфичные для демонов, внешний прокси и действующую политику брандмауэра. Это шаг, который люди пропускают, и именно он превращает безобидный на вид backend-порт в доступный административный путь.
Тот же вопрос читается иначе снаружи хоста. Порт без правила брандмауэра хоста всё ещё может быть закрыт облачной группой безопасности, а порт с разрешающим правилом хоста может быть недоступен, потому что к нему ничего не маршрутизируется. Посмотрите на оба конца, прежде чем писать вывод инвентаря.
Где опубликованный путь отличается от списка сокетов
Собственная документация Access Server охватывает случай, который вызывает больше всего путаницы: когда работают несколько демонов TCP, фронтальный порт перенаправляет на порты, специфичные для демонов, и видимая раскладка перестаёт соответствовать списку сокетов. руководство по фильтрации веб-интерфейса описывает эти правила и то, почему фильтр, написанный только для очевидного порта, может полностью упустить перенаправленный путь.
Управление кластером — второе место, где важна версия. Начиная с 3.0 он делит 943; более старые конфигурации кластера использовали 945. Открытие или блокировка одного из них без проверки версии даёт аккуратный на вид и неверный инвентарь.
Итак, внешне видимая поверхность — это объединение трёх вещей: слушающих сокетов, правил перенаправления, которые их публикуют заново, и сетевых контролей перед хостом. Любой инвентарь, где записано только первое, неполон, а любое изменение, которое учитывает только первое, либо оставит путь открытым, либо отрежет сервис.
Проверьте после любого изменения
Меняйте настройки слушателей через поддерживаемого владельца конфигурации и держите открытой консоль восстановления, пока делаете это. Потеря административного доступа к веб-интерфейсу на удалённом хосте не восстанавливается через VPN, который вы только что отключили.
Затем проверьте четыре вещи, которые обычно нужны развёртыванию: VPN-клиент подключается, клиентский портал загружается, административный доступ работает, и связь кластера продолжает работать, если вы запускаете больше одного узла. Тест только VPN спокойно проходит, пока портал сломан.
Завершите, записав разрешённый путь для каждого сервиса: какой сокет, какая привязка, какое правило перенаправления, какой сетевой контроль. Этот документ и есть полезный результат по безопасности. Минимальное число сокетов — нет, как и массовый сброс, который закрывает слушатели, которые никто не успел идентифицировать.