Блокирует ли коммерческий VPN порт 5432? Сравните варианты

Приложение каждый день общалось со своей базой данных из офиса. Затем кто-то включил коммерческий VPN-клиент на том же ноутбуке, и соединение начало сбрасываться после рукопожатия. В приложении ничего не изменилось, туннель сообщает, что здоров, а в вашем межсетевом экране нет правила блокировки. Изменился путь выхода: серверы провайдера — это общие высоконагруженные конечные точки, а провайдеры фильтруют исходящие порты, чтобы снизить злоупотребления. Порты баз данных и отправки почты получают большую часть этого, потому что именно они привлекают сканирование и спам из анонимного пула адресов.

Пятиминутная проверка, которая отделяет фильтрацию от всего остального

С той же машины проверьте один порт, который должен быть открыт, и порт, который не работает, на том же хосте: сначала с включённым туннелем, затем с выключенным. Используйте одну и ту же команду оба раза, чтобы единственной переменной был туннель:

Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432

Четыре результата охватывают почти все случаи. Если 443 работает, а 5432 сбоит только при включённом туннеле, вы видите фильтрацию портов на пути выхода. Если оба сбоят с туннелем и оба работают без него, проблема в маршрутизации или DNS, а не в политике портов. Если оба порта соединяются, но приложение всё равно сбоит, виновата аутентификация или TLS, а не доступность. И если сбоит только одно расположение сервера провайдера, это политика конкретного сервера, поэтому попробуйте другое расположение, прежде чем трогать какую-либо конфигурацию.

Первый вариант: раздельный туннель для подсети базы данных

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

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

Второй вариант: своя конечная точка, свой выход

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

Сравните оба по стабильности адреса источника, по тому, кто может читать ваш трафик, и по тому, что происходит в день, когда провайдер конечной точки меняет собственную фильтрацию.

Третий вариант: уберите ноутбук из этого пути

Задание CI, запуск контейнера по расписанию или бастионный хост внутри разрешённой сети не зависят от состояния туннеля человека. Доберитесь до базы данных через SSH-туннель с хоста, который уже разрешён, и ноутбук никогда не обращается к порту напрямую. Это вариант, который масштабируется, когда несколько человек упираются в одно и то же ограничение, и он же устраняет проблему, а не обходит её.

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

Почему добавление адреса провайдера в список разрешённых — неверное сравнение

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

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

Что бы вы ни выбрали, запишите путь и причину. Следующий человек столкнётся с тем же сбрасывающимся соединением и начнёт винить приложение.