PostgreSQL через VPN: яку адресу джерела побачить pg_hba

Слухач, міжмережевий екран і перше відповідне правило HBA — це три рішення. Перевірте джерело, яке PostgreSQL справді отримує, перш ніж вибирати префікс.

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. Ці три результати відокремлюють мережеву межу від авторизації бази даних, у чому й полягає весь сенс розділення рішень.

Схожі статті