PostgreSQL përmes një VPN: cila adresë burimore do të shohë pg_hba

PostgreSQL nuk mëson kurrë se një klient është në një VPN. Ai merr një lidhje TCP nga një adresë dhe një grup kredencialesh, dhe vendos çfarë të bëjë me to. Prandaj, ta bësh aksesin të varur nga tuneli do të thotë të rregullosh tre vendime të ndara që të përputhen, dhe më pas të kontrollosh adresën e vetme që serveri sheh vërtet në vend të asaj që vizatuat në diagram.

Tre vendime që nuk duhet të bashkohen

Ku dëgjon serveri është një vendim. Cili trafik mund të arrijë në atë adresë është i dyti, i marrë nga firewalls i hostit dhe çdo kufi rrjeti përpara tij. Cila identitet i bazës së të dhënave mund të vërtetohet nga cili burim është i treti, i marrë në pg_hba.conf.

Secili zbatohet nga një komponent i ndryshëm, dhe secili dështon me një mesazh të ndryshëm. Bashkimi i tyre në një diskutim është mënyra se si njerëzit përfundojnë duke redaktuar skedarin HBA për të rregulluar një problem firewalls. Mbajini në radhë: një dëgjues që nuk është i lidhur nuk arrihet, në një port të filtruar nuk mund të lidhesh, dhe një rregull HBA vendos vetëm çfarë ndodh pasi ekziston një lidhje. Kur një ndryshim nuk ka efekt, identifikoni cilën nga tre shtresat keni ndryshuar vërtet.

Ku dëgjon serveri

Lidhu me një adresë që i është caktuar vërtet makinës, jo me një emër ndërfaqeje:

listen_addresses = '10.20.0.30'

Baza e të dhënave mund të qëndrojë pas portës VPN pa një ndërfaqe tuneli të vetën, dhe pikërisht për këtë një adresë është gjëja e duhur për t'u emërtuar. Ndryshimi i këtij parametri kërkon një rinisje të plotë; një ringarkim nuk mjafton.

Pastaj filtro portin, zakonisht 5432, në host dhe në çdo kufi përpara tij. Lidhja me një adresë private nuk është provë e mohimit publik, sepse një përcjellje porti ose një hartëzim adrese në re mund të dërgojë ende paketa te ai dëgjues privat.

Adresa që HBA sheh vërtet

Me akses të rrugëzuar serveri sheh adresën e brendshme të tunelit të çdo klienti. Me përkthim burimi sheh në vend të saj adresën e përkthyer të portës, dhe çdo klient rrëzohet në atë vlerë të vetme. Inspektoni burimin përmes provave të lidhjeve të vetë serverit përpara se të zgjidhni një parashtesë për të lejuar.

Për një vendosje që tashmë përdor TLS dhe SCRAM, një shembull qëllimisht i ngushtë i aksesit në distancë duket kështu:

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

Kjo lejon një rol dhe një bazë të dhënash përmes TLS nga grupi i caktuar, pastaj refuzon akses tjetër TCP në distancë. Nuk është zëvendësim për një skedar të plotë HBA: mbani administrimin lokal, replikimin dhe çdo shërbim tjetër të autorizuar, dhe vendosni rregullat e ngushta përpara lejeve më të gjera.

Kur përkthimi është në lojë, HBA nuk mund t'i dallojë klientët sipas adresave të tyre origjinale. Mbani pranimin e rrjetit të rreptë dhe kërkoni kredenciale të vërteta baze të dhënash, dhe kurrë mos zëvendësoni vërtetimin trust me një llogari reale.

Fituesi është përputhja e parë, pa alternativë

PostgreSQL lexon skedarin nga lart poshtë dhe përdor regjistrin e parë që përputhet me lidhjen. Nuk ka një provë të dytë nëse vërtetimi i atij regjistri dështon, kështu që një leje e gjerë e mëparshme mposht në heshtje një refuzim të mëvonshëm.

Ky rregull radhe është arsyeja më e zakonshme pse një refuzim i shkruar me kujdes nuk hyn kurrë në fuqi. Vendosni rregullat specifike të parat dhe ato të gjera të fundit, pastaj lexoni skedarin si një sekuencë dhe jo si një grup. Një rregull i shtuar në fund nuk është politikë, është koment. Zhvendoseni lart dhe ringarkojeni përpara se të përfundoni se skedari po injorohet.

Referenca HBA përcakton si radhën ashtu edhe ndryshimin midis regjistrave host dhe hostssl, gjë që ka rëndësi kur qëllimi i rregullit është që lidhja duhet të jetë e enkriptuar.

Ringarkim, rinisje dhe rasti i refuzuar

Ndryshimet HBA aplikohen me një ringarkim, dhe pamja pg_hba_file_rules ju ndihmon të gjeni gabime analize. Ajo pamje përshkruan përmbajtjen aktuale të skedarit, jo nëse serveri që punon i ka ngarkuar me sukses, kështu që një listë e pastër nuk është provë se rregullat e reja janë aktive.

Ndryshimet e dëgjuesit kërkojnë rinisjen e tyre, dhe dy veprimet ngatërrohen lehtë kur një ndryshim duket se nuk ka efekt.

Testoni me sesione të freskëta: një klient i miratuar me llogarinë e synuar lidhet, e njëjta llogari nga një rrugë e pamiratuar nuk lidhet, dhe një identitet i paautorizuar baze të dhënash vazhdon të dështojë nga brenda VPN. Këto tre rezultate ndajnë kufirin e rrjetit nga autorizimi i bazës së të dhënave, që është i gjithë qëllimi i mbajtjes së vendimeve të ndara.