PostgreSQL през VPN: кой адрес на източника ще види pg_hba

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. Тези три резултата разделят мрежовата граница от оторизацията на базата данни, което е целият смисъл решенията да се държат отделно.