PostgreSQL cez VPN: akú zdrojovú adresu uvidí pg_hba
Listener, firewall a prvé zodpovedajúce pravidlo HBA sú tri rozhodnutia. Overte zdroj, ktorý PostgreSQL skutočne prijíma, predtým ako vyberiete prefix.
PostgreSQL sa nikdy nedozvie, že klient je vo VPN. Prijme TCP spojenie z adresy a sadu prihlasovacích údajov a rozhodne, čo s nimi urobí. Preto urobiť prístup závislým od tunela znamená zladiť tri samostatné rozhodnutia tak, aby súhlasili, a potom skontrolovať jedinú adresu, ktorú server skutočne vidí, namiesto tej, ktorú ste nakreslili do diagramu.
Tri rozhodnutia, ktoré sa nesmú zlievať
Kde server počúva, je jedno rozhodnutie. Ktorá prevádzka sa môže dostať na tú adresu, je druhé, prijíma ho hostiteľský firewall a každá sieťová hranica pred ním. Ktorá identita databázy sa môže overiť z ktorého zdroja, je tretie, prijíma sa v pg_hba.conf.
Každé presadzuje iný komponent a každé zlyhá s iným hlásením. Ich zlievanie v diskusii je spôsob, akým ľudia skončia pri úprave súboru HBA, aby opravili problém s firewallom. Držte ich v poradí: listener, ktorý nie je naviazaný, sa nedá dosiahnuť, na filtrovaný port sa nedá pripojiť a pravidlo HBA rozhoduje len o tom, čo sa stane po vzniku spojenia. Keď zmena nemá účinok, určite, ktorú z troch vrstiev ste skutočne zmenili.
Kde server počúva
Naviazte sa na adresu, ktorá je stroju skutočne pridelená, nie na názov rozhrania:
listen_addresses = '10.20.0.30'Databáza môže sedieť za bránou VPN bez vlastného tunelového rozhrania, a práve preto je adresa tou správnou vecou, ktorú treba pomenovať. Zmena tohto nastavenia si vyžaduje úplný reštart; opätovné načítanie nestačí.
Potom filtrujte port, zvyčajne 5432, na hostiteľovi a na každej hranici pred ním. Naviazanie na privátnu adresu nie je dôkazom verejného odmietnutia, pretože presmerovanie portu alebo mapovanie cloudovej adresy môže pakety stále doručiť tomu privátnemu listeneru.
Adresa, ktorú HBA skutočne vidí
Pri smerovanom prístupe server vidí vnútornú tunelovú adresu každého klienta. Pri preklade zdroja namiesto toho vidí preloženú adresu brány a každý klient sa zlieva do tej jedinej hodnoty. Preskúmajte zdroj prostredníctvom vlastných dôkazov o spojeniach servera, než zvolíte prefix, ktorý povolíte.
Pre nasadenie, ktoré už používa TLS a SCRAM, vyzerá úmyselne úzky príklad vzdialeného prí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 rejectTo povoľuje jednu rolu a jednu databázu cez TLS z uvedeného fondu a potom odmieta iný vzdialený TCP prístup. Nie je to náhrada za úplný súbor HBA: zachovajte miestnu správu, replikáciu a akúkoľvek inú autorizovanú službu a úzke pravidlá umiestnite pred širšie povolenia.
Keď je preklad v hre, HBA nedokáže rozlíšiť klientov podľa ich pôvodných adries. Držte sieťový vstup tesný a vyžadujte skutočné prihlasovacie údaje k databáze a nikdy nenahrádzajte trust autentifikáciu skutočným účtom.
Vyhráva prvá zhoda, bez náhrady
PostgreSQL číta súbor zhora nadol a použije prvý záznam, ktorý zodpovedá spojeniu. Ak overenie toho záznamu zlyhá, druhý pokus neexistuje, takže skoršie široké povolenie potichu porazí neskoršie odmietnutie.
Toto pravidlo poradia je najčastejším dôvodom, prečo starostlivo napísané odmietnutie nikdy nezačne platiť. Dajte konkrétne pravidlá prvé a široké posledné, potom čítajte súbor ako postupnosť, nie ako množinu. Pravidlo pridané na koniec nie je politika, je to komentár. Presuňte ho nahor a znova načítajte, než usúdite, že súbor sa ignoruje.
Referencia HBA definuje poradie aj rozdiel medzi záznamami host a hostssl, čo je dôležité, keď je zmyslom pravidla to, že spojenie musí byť šifrované.
Opätovné načítanie, reštart a odmietnutý prípad
Zmeny HBA sa aplikujú opätovným načítaním a zobrazenie pg_hba_file_rules vám pomôže nájsť chyby analýzy. Toto zobrazenie opisuje aktuálny obsah súboru, nie to, či ich bežiaci server úspešne načítal, takže čistý zoznam nie je dôkazom, že nové pravidlá sú aktívne.
Zmeny listenera potrebujú vlastný reštart a obe operácie sa ľahko zamieňajú, keď sa zdá, že zmena nemá účinok.
Testujte s čerstvými reláciami: schválený klient s plánovaným účtom sa pripojí, ten istý účet z neschválenej cesty nie, a neautorizovaná identita databázy stále zlyháva zvnútra VPN. Tieto tri výsledky oddeľujú sieťovú hranicu od autorizácie databázy, čo je celý zmysel držania rozhodnutí oddelene.