PostgreSQL VPN-i kaudu: millist lähteaadressi pg_hba näeb

Kuulaja, tulemüür ja esimene sobiv HBA-reegel on kolm otsust. Kontrollige allikat, mille PostgreSQL tegelikult saab, enne kui valite prefiksi.

PostgreSQL ei saa kunagi teada, et klient on VPN-is. See võtab vastu TCP-ühenduse aadressilt ja hulga volitusi ning otsustab, mida nendega teha. Seega tähendab juurdepääsu tunnelist sõltuvaks tegemine kolme eraldi otsuse sellist korraldamist, et need kokku sobiksid, ja seejärel selle ühe aadressi kontrollimist, mida server tegelikult näeb, mitte selle, mille te diagrammile joonistasite.

Kolm otsust, mida ei tohi ühendada

See, kus server kuulab, on üks otsus. See, milline liiklus võib sellele aadressile jõuda, on teine, mille teeb hosti tulemüür ja iga võrgupiir selle ees. See, milline andmebaasi identiteet võib millisest allikast autentida, on kolmas, mis tehakse failis pg_hba.conf.

Igaüht neist rakendab erinev komponent ja igaüks ebaõnnestub erineva sõnumiga. Nende ühendamine arutelus on viis, kuidas inimesed hakkavad HBA-faili muutma, et tulemüüriprobleemi parandada. Hoidke need järjekorras: kuulajat, mis ei ole seotud, ei saa kätte, filtreeritud pordile ei saa ühendust, ja HBA-reegel otsustab ainult seda, mis juhtub pärast ühenduse olemasolu. Kui muudatusel pole mõju, tehke kindlaks, millist kolmest kihist te tegelikult muutsite.

Kus server kuulab

Seo aadressiga, mis on masinale tegelikult määratud, mitte liidese nimega:

listen_addresses = '10.20.0.30'

Andmebaas võib asuda VPN-i lüüsi taga ilma oma tunneliliideseta, ja just seetõttu on aadress õige asi, mida nimetada. Selle sätte muutmine nõuab täielikku taaskäivitust; uuesti laadimisest ei piisa.

Seejärel filtreerige port, tavaliselt 5432, hostis ja igal selle ees oleval piiril. Privaatsele aadressile sidumine ei ole tõestus avalikust keelamisest, sest pordi edasisaatmine või pilveaadressi vastendamine võib ikkagi paketid sellele privaatsele kuulajale kohale toimetada.

Aadress, mida HBA tegelikult näeb

Marsruuditud juurdepääsu korral näeb server iga kliendi sisemist tunneli aadressi. Lähteallika tõlkimisel näeb see selle asemel lüüsi tõlgitud aadressi ja iga klient koondub selleks üheks väärtuseks. Uurige allikat serveri enda ühenduste tõendite kaudu, enne kui valite lubatava prefiksi.

Juurutuse jaoks, mis juba kasutab TLS-i ja SCRAM-i, näeb meelega kitsas kaugjuurdepääsu näide välja selline:

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

See lubab ühte rolli ja ühte andmebaasi üle TLS-i näidatud poolist ning keelab seejärel muu kaug-TCP-juurdepääsu. See ei asenda täielikku HBA-faili: hoidke kohalik haldus, replikatsioon ja mis tahes muu volitatud teenus, ning asetage kitsad reeglid laiemate lubade ette.

Kui tõlkimine on mängus, ei suuda HBA kliente nende algsete aadresside järgi eristada. Hoidke võrgu vastuvõtt rangena ja nõudke tõelisi andmebaasi volitusi ning ärge kunagi asendage trust-autentimist tegeliku kontoga.

Võidab esimene vaste, ilma varuvariandita

PostgreSQL loeb faili ülalt alla ja kasutab esimest kirjet, mis ühendusega sobib. Teist katset ei ole, kui selle kirje autentimine ebaõnnestub, seega varasem lai luba võidab vaikselt hilisema keelu.

See järjekorrareegel on kõige levinum põhjus, miks hoolikalt kirjutatud keeld kunagi ei jõustu. Pange konkreetsed reeglid esimeseks ja laiad viimaseks, seejärel lugege faili järjestusena, mitte hulgana. Reegel, mille lisasite lõppu, ei ole poliitika, vaid kommentaar. Liigutage see üles ja laadige uuesti, enne kui järeldate, et faili ignoreeritakse.

HBA viide määratleb nii järjekorra kui ka erinevuse host- ja hostssl-kirjete vahel, mis on oluline siis, kui reegli mõte on see, et ühendus peab olema krüptitud.

Uuesti laadimine, taaskäivitamine ja keelatud juhtum

HBA muudatused rakendatakse uuesti laadimisega ja vaade pg_hba_file_rules aitab teil leida parsimisvigu. See vaade kirjeldab faili praegust sisu, mitte seda, kas töötav server need edukalt laadis, seega puhas loend ei ole tõestus, et uued reeglid on aktiivsed.

Kuulaja muudatused vajavad oma taaskäivitust ja kahte toimingut on lihtne segi ajada, kui muudatus näib mõju puuduvat.

Testige värskete sessioonidega: kinnitatud klient kavandatud kontoga ühendub, sama konto mittekinnitatud teelt mitte, ja volitamata andmebaasi identiteet ebaõnnestub endiselt VPN-i seest. Need kolm tulemust eraldavad võrgupiiri andmebaasi autoriseerimisest, mis ongi kogu mõte hoida otsuseid lahus.

Seotud artiklid