PostgreSQL přes VPN: kterou zdrojovou adresu uvidí pg_hba

Listener, firewall a první odpovídající pravidlo HBA jsou tři rozhodnutí. Ověřte zdroj, který PostgreSQL skutečně přijímá, než zvolíte prefix.

PostgreSQL se nikdy nedozví, že klient je na VPN. Přijme TCP spojení z nějaké adresy a sadu přihlašovacích údajů a rozhodne, co s nimi udělá. Proto udělat přístup závislým na tunelu znamená sladit tři samostatná rozhodnutí, a pak zkontrolovat jedinou adresu, kterou server skutečně vidí, místo té, kterou jste nakreslili do diagramu.

Tři rozhodnutí, která se nesmějí slévat

Kde server naslouchá, je jedno rozhodnutí. Který provoz se může dostat na tuto adresu, je druhé, činěné hostitelským firewallem a každou síťovou hranicí před ním. Která identita databáze se může ověřit z kterého zdroje, je třetí, činěné v pg_hba.conf.

Každé vynucuje jiná komponenta a každé selhává s jinou zprávou. Jejich slévání v diskusi je způsob, jak lidé skončí úpravou souboru HBA, aby opravili problém s firewallem. Držte je v pořadí: listener, který není navázán, nelze dosáhnout, na filtrovaný port se nelze připojit a pravidlo HBA rozhoduje jen o tom, co se stane poté, co spojení existuje. Když změna nemá účinek, určete, kterou ze tří vrstev jste skutečně změnili.

Kde server naslouchá

Navažte se na adresu, která je stroji skutečně přiřazena, ne na název rozhraní:

listen_addresses = '10.20.0.30'

Databáze může sedět za VPN bránou bez vlastního tunelového rozhraní, a právě proto je adresa tou správnou věcí, kterou je třeba pojmenovat. Změna tohoto nastavení vyžaduje úplný restart; reload nestačí.

Poté filtrujte port, obvykle 5432, na hostiteli a na každé hranici před ním. Navázání na privátní adresu není důkazem veřejného odmítnutí, protože přesměrování portu nebo mapování cloudové adresy může pakety stále doručit tomuto privátnímu listeneru.

Adresa, kterou HBA skutečně vidí

Při routovaném přístupu server vidí vnitřní tunelovou adresu každého klienta. Při překladu zdroje místo toho vidí přeloženou adresu brány a každý klient se slije do této jediné hodnoty. Prozkoumejte zdroj prostřednictvím vlastních důkazů o spojeních serveru, než zvolíte prefix, který povolíte.

Pro nasazení, které již používá TLS a SCRAM, vypadá záměrně úzký příklad vzdáleného přístupu takto:

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

To povoluje jednu roli a jednu databázi přes TLS z uvedeného poolu a poté odmítá ostatní vzdálený TCP přístup. Není to náhrada za úplný soubor HBA: zachovejte místní správu, replikaci a jakoukoli další autorizovanou službu a úzká pravidla umístěte před širší povolení.

Když je překlad ve hře, HBA nedokáže klienty rozlišit podle jejich původních adres. Držte síťový vstup těsný a vyžadujte skutečné přihlašovací údaje k databázi a nikdy nenahrazujte trust autentizaci skutečným účtem.

Vyhrává první shoda, bez náhrady

PostgreSQL čte soubor shora dolů a použije první záznam, který odpovídá spojení. Pokud ověření tohoto záznamu selže, druhý pokus neexistuje, takže dřívější široké povolení tiše porazí pozdější odmítnutí.

Toto pravidlo pořadí je nejčastějším důvodem, proč pečlivě napsané odmítnutí nikdy nezačne platit. Dejte konkrétní pravidla první a široká poslední, pak čtěte soubor jako posloupnost, ne jako množinu. Pravidlo přidané na konec není politika, je to komentář. Přesuňte ho nahoru a znovu načtěte, než usoudíte, že se soubor ignoruje.

Odkaz na HBA definuje jak pořadí, tak rozdíl mezi záznamy host a hostssl, což je důležité, když smyslem pravidla je, že spojení musí být šifrované.

Reload, restart a odmítnutý případ

Změny HBA se aplikují reloadem a pohled pg_hba_file_rules vám pomůže najít chyby analýzy. Tento pohled popisuje aktuální obsah souboru, ne to, zda je běžící server úspěšně načetl, takže čistý výpis není důkazem, že jsou nová pravidla aktivní.

Změny listeneru potřebují vlastní restart a obě operace se snadno zamění, když se zdá, že změna nemá účinek.

Testujte s čerstvými relacemi: schválený klient se zamýšleným účtem se připojí, stejný účet z neschválené cesty ne, a neautorizovaná identita databáze stále selhává zevnitř VPN. Tyto tři výsledky oddělují síťovou hranici od autorizace databáze, což je celý smysl držení rozhodnutí odděleně.

Související články