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

Три решения, которые нельзя смешивать

Где сервер слушает — это первое решение. Какой трафик может достичь этого адреса — второе, его принимает межсетевой экран хоста и любая сетевая граница перед ним. Какая учётная запись базы данных может аутентифицироваться из какого источника — третье, оно принимается в pg_hba.conf.

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

Где сервер слушает

Привяжитесь к адресу, который действительно назначен машине, а не к имени интерфейса:

listen_addresses = '10.20.0.30'

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

Затем отфильтруйте порт, обычно 5432, на хосте и на каждой границе перед ним. Привязка к частному адресу не является доказательством публичного запрета, потому что перенаправление порта или сопоставление облачного адреса всё ещё может доставить пакеты этому частному слушателю.

Адрес, который HBA действительно видит

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

Для развёртывания, которое уже использует TLS и SCRAM, намеренно узкий пример удалённого доступа выглядит так:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

Это разрешает одну роль и одну базу данных по TLS из указанного пула, а затем отклоняет другой удалённый доступ по TCP. Это не замена полному файлу HBA: сохраните локальное администрирование, репликацию и любую другую разрешённую службу, а узкие правила поставьте перед более широкими разрешениями.

Когда действует трансляция, HBA не может различить клиентов по их исходным адресам. Держите сетевой допуск строгим и требуйте настоящие учётные данные базы данных, и никогда не заменяйте аутентификацию trust реальной учётной записью.

Побеждает первое совпадение, без запасного варианта

PostgreSQL читает файл сверху вниз и использует первую запись, подходящую к соединению. Второй попытки нет, если аутентификация этой записи не удалась, поэтому более раннее широкое разрешение незаметно перекрывает более поздний запрет.

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

Справочник HBA определяет как порядок, так и разницу между записями host и hostssl, что важно, когда смысл правила в том, что соединение должно быть зашифровано.

Перезагрузка, перезапуск и случай отказа

Изменения HBA применяются перезагрузкой, а представление pg_hba_file_rules помогает найти ошибки разбора. Это представление описывает текущее содержимое файла, а не то, успешно ли загрузил их работающий сервер, поэтому чистый список не является доказательством того, что новые правила действуют.

Изменения слушателя требуют собственного перезапуска, и эти две операции легко спутать, когда кажется, что изменение не даёт эффекта.

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

Похожие статьи