PostgreSQL prek VPN: kateri naslov vira bo videl pg_hba

PostgreSQL nikoli ne izve, da je odjemalec v VPN. Prejme TCP povezavo z naslova in nabor poverilnic ter se odloči, kaj bo z njimi. Zato narediti dostop odvisen od tunela pomeni uskladiti tri ločene odločitve, nato pa preveriti edini naslov, ki ga strežnik dejansko vidi, namesto tistega, ki ste ga narisali na diagramu.

Tri odločitve, ki se ne smejo združiti

Kje strežnik posluša, je ena odločitev. Kateri promet lahko doseže ta naslov, je druga, sprejme jo požarni zid gostitelja in vsaka omrežna meja pred njim. Katera identiteta baze podatkov se lahko preveri iz katerega vira, je tretja, sprejeta v pg_hba.conf.

Vsako uveljavlja druga komponenta in vsako spodleti z drugim sporočilom. Njihovo združevanje v razpravi je način, kako ljudje končajo z urejanjem datoteke HBA, da bi odpravili težavo požarnega zidu. Držite jih v redu: poslušalec, ki ni vezan, ni dosegljiv, na filtrirana vrata se ni mogoče povezati, pravilo HBA pa odloča le o tem, kaj se zgodi po tem, ko povezava obstaja. Ko sprememba nima učinka, ugotovite, katero od treh plasti ste dejansko spremenili.

Kje strežnik posluša

Vežite se na naslov, ki je stroju dejansko dodeljen, ne na ime vmesnika:

listen_addresses = '10.20.0.30'

Baza podatkov je lahko za prehodom VPN brez lastnega tunelskega vmesnika, in prav zato je naslov tista prava stvar, ki jo je treba poimenovati. Sprememba te nastavitve zahteva popoln ponovni zagon; ponovno nalaganje ni dovolj.

Nato filtrirajte vrata, običajno 5432, na gostitelju in na vsaki meji pred njim. Vezava na zasebni naslov ni dokaz javne zavrnitve, ker lahko posredovanje vrat ali preslikava naslova v oblaku še vedno dostavi pakete temu zasebnemu poslušalcu.

Naslov, ki ga HBA dejansko vidi

Pri usmerjenem dostopu strežnik vidi notranji tunelski naslov vsakega odjemalca. Pri prevajanju vira namesto tega vidi prevedeni naslov prehoda in vsak odjemalec se zruši v to eno vrednost. Preverite vir z lastnimi dokazi o povezavah strežnika, preden izberete predpono, ki jo boste dovolili.

Za namestitev, ki že uporablja TLS in SCRAM, je namerno ozek primer oddaljenega dostopa videti takole:

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 dovoli eno vlogo in eno bazo podatkov prek TLS iz navedenega nabora, nato pa zavrne drug oddaljeni dostop TCP. To ni nadomestilo za celotno datoteko HBA: ohranite lokalno upravljanje, replikacijo in katero koli drugo pooblaščeno storitev, ozka pravila pa postavite pred širša dovoljenja.

Ko je prevajanje v igri, HBA ne more ločiti odjemalcev po njihovih izvirnih naslovih. Vzdržujte tesno omrežno sprejemanje in zahtevajte prave poverilnice baze podatkov, in nikoli ne nadomestite preverjanja trust z dejanskim računom.

Zmagata prvo ujemanje, brez nadomestne možnosti

PostgreSQL bere datoteko od zgoraj navzdol in uporabi prvi zapis, ki se ujema s povezavo. Če preverjanje tega zapisa spodleti, drugega poskusa ni, zato prejšnje široko dovoljenje tiho premaga poznejšo zavrnitev.

To pravilo vrstnega reda je najpogostejši razlog, da skrbno napisana zavrnitev nikoli ne začne veljati. Postavite posebna pravila prva in široka zadnja, nato pa berite datoteko kot zaporedje in ne kot množico. Pravilo, ki ste ga dodali na dno, ni politika, je komentar. Premaknite ga navzgor in znova naložite, preden sklenete, da se datoteka ignorira.

Referenca HBA določa tako vrstni red kot razliko med zapisi host in hostssl, kar je pomembno, ko je smisel pravila v tem, da mora biti povezava šifrirana.

Ponovno nalaganje, ponovni zagon in zavrnjeni primer

Spremembe HBA se uporabijo s ponovnim nalaganjem, pogled pg_hba_file_rules pa vam pomaga najti napake pri razčlenjevanju. Ta pogled opisuje trenutno vsebino datoteke, ne pa, ali jih je delujoči strežnik uspešno naložil, zato čist seznam ni dokaz, da nova pravila veljajo.

Spremembe poslušalca potrebujejo svoj ponovni zagon, in obe operaciji se zlahka zamenjata, ko se zdi, da sprememba nima učinka.

Preizkusite s svežimi sejami: odobren odjemalec s predvidenim računom se poveže, isti račun z neodobrene poti ne, in nepooblaščena identiteta baze podatkov še vedno spodleti znotraj VPN. Ti trije rezultati ločijo omrežno mejo od avtorizacije baze podatkov, kar je ves smisel ločenega ohranjanja odločitev.