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. Гэтыя тры вынікі аддзяляюць сеткавую мяжу ад аўтарызацыі базы даных, у чым і ўвесь сэнс раздзялення рашэнняў.

Падобныя артыкулы