PostgreSQL VPN-en keresztül: melyik forráscímet látja a pg_hba

A PostgreSQL soha nem tudja meg, hogy egy ügyfél VPN-en van. Fogad egy TCP-kapcsolatot egy címről és egy hitelesítőadat-készletet, és eldönti, mit tegyen velük. Ezért a hozzáférést az alagúttól függővé tenni annyit jelent, hogy három külön döntést úgy kell elrendezni, hogy összhangban legyenek, majd ellenőrizni kell azt az egy címet, amelyet a kiszolgáló valóban lát, nem pedig azt, amelyet a diagramra rajzolt.

Három döntés, amelyeket nem szabad összevonni

Az, hogy hol figyel a kiszolgáló, egy döntés. Az, hogy mely forgalom érheti el azt a címet, egy második, amelyet a gazdagép tűzfala és bármely előtte lévő hálózati határ hoz. Az, hogy mely adatbázis-identitás melyik forrásból hitelesíthet, egy harmadik, amelyet a pg_hba.conf fájlban hoznak.

Mindegyiket más összetevő kényszeríti ki, és mindegyik más üzenettel hiúsul meg. Ezeket egy vitában összevonni vezet oda, hogy az emberek a HBA-fájl szerkesztésével próbálnak megoldani egy tűzfalproblémát. Tartsa őket sorrendben: egy nem kötött figyelő nem érhető el, egy szűrt porthoz nem lehet csatlakozni, és a HBA-szabály csak arról dönt, mi történik a kapcsolat létrejötte után. Ha egy módosításnak nincs hatása, állapítsa meg, melyik réteget módosította valójában a három közül.

Hol figyel a kiszolgáló

Olyan címhez kössön, amelyet valóban a géphez rendeltek, ne egy interfész nevéhez:

listen_addresses = '10.20.0.30'

Az adatbázis állhat a VPN-átjáró mögött saját alagút-interfész nélkül, és éppen ezért a cím az a helyes dolog, amit meg kell nevezni. Ennek a beállításnak a megváltoztatása teljes újraindítást igényel; az újratöltés nem elég.

Ezután szűrje a portot, általában az 5432-t, a gazdagépen és minden előtte lévő határon. A privát címhez kötés nem bizonyíték a nyilvános megtagadásra, mert egy porttovábbítás vagy felhőcím-hozzárendelés még mindig eljuttathat csomagokat ahhoz a privát figyelőhöz.

A cím, amelyet a HBA valóban lát

Irányított hozzáférésnél a kiszolgáló minden ügyfél belső alagút-címét látja. Forrásfordításnál helyette az átjáró lefordított címét látja, és minden ügyfél összeomlik ebbe az egyetlen értékbe. Vizsgálja meg a forrást a kiszolgáló saját kapcsolati bizonyítékain keresztül, mielőtt engedélyezendő előtagot választ.

Egy már TLS-t és SCRAM-ot használó telepítéshez egy szándékosan szűk távoli hozzáférési példa így néz ki:

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

Ez egy szerepkört és egy adatbázist engedélyez TLS-en keresztül a megadott készletből, majd elutasít minden más távoli TCP-hozzáférést. Ez nem helyettesíti a teljes HBA-fájlt: tartsa meg a helyi adminisztrációt, a replikációt és minden más engedélyezett szolgáltatást, és a szűk szabályokat helyezze a szélesebb engedélyek elé.

Amikor a fordítás szerepet játszik, a HBA nem tudja megkülönböztetni az ügyfeleket az eredeti címük alapján. Tartsa szigorún a hálózati beengedést, és követeljen valódi adatbázis-hitelesítő adatokat, és soha ne helyettesítse a trust-hitelesítést egy tényleges fiókkal.

Az első egyezés nyer, tartalék nélkül

A PostgreSQL felülről lefelé olvassa a fájlt, és az első olyan rekordot használja, amely illeszkedik a kapcsolathoz. Nincs második próbálkozás, ha annak a rekordnak a hitelesítése meghiúsul, így egy korábbi széles engedély csendben legyőzi egy későbbi elutasítást.

Ez a sorrendi szabály a leggyakoribb oka annak, hogy egy gondosan megírt elutasítás soha nem lép hatályba. Tegye a konkrét szabályokat előre és a széleseket a végére, majd olvassa a fájlt sorozatként, ne halmazként. Az aljára felvett szabály nem szabályzat, hanem megjegyzés. Mozgassa feljebb, és töltse újra, mielőtt arra a következtetésre jutna, hogy a fájlt figyelmen kívül hagyják.

A HBA-referencia meghatározza a sorrendet és a host és hostssl rekordok közötti különbséget is, ami akkor számít, amikor a szabály lényege az, hogy a kapcsolatnak titkosítottnak kell lennie.

Újratöltés, újraindítás és az elutasított eset

A HBA-módosításokat újratöltés alkalmazza, és a pg_hba_file_rules nézet segít megtalálni az elemzési hibákat. Ez a nézet a fájl jelenlegi tartalmát írja le, nem azt, hogy a futó kiszolgáló sikeresen betöltötte-e őket, ezért egy tiszta lista nem bizonyíték arra, hogy az új szabályok élnek.

A figyelő módosításai saját újraindítást igényelnek, és a két művelet könnyen összekeverhető, amikor egy módosításnak úgy tűnik, nincs hatása.

Teszteljen friss munkamenetekkel: egy jóváhagyott ügyfél a szándékolt fiókkal csatlakozik, ugyanaz a fiók egy nem jóváhagyott útvonalról nem, és egy jogosulatlan adatbázis-identitás továbbra is meghiúsul a VPN belsejéből. Ez a három eredmény elválasztja a hálózati határt az adatbázis-engedélyezéstől, ami az egész értelme annak, hogy a döntéseket külön tartsuk.