PostgreSQL over ein VPN: kva kjeldeadresse pg_hba ser

PostgreSQL får aldri vite at ein klient er på eit VPN. Det mottek ei TCP-tilkopling frå ei adresse og eit sett med påloggingsinformasjon, og avgjer kva det skal gjere med dei. Å gjere tilgangen avhengig av tunnelen tyder derfor å ordne tre separate avgjerder slik at dei stemmer overeins, og deretter kontrollere den eine adressa som tenaren faktisk ser i staden for den du teikna på diagrammet.

Tre avgjerder som ikkje må smelte saman

Kvar tenaren lyttar, er éi avgjerd. Kva trafikk som kan nå den adressa, er ei andre, teken av brannmuren på verten og kvar nettverksgrense framom han. Kva databaseidentitet som kan autentisere seg frå kva kjelde, er ei tredje, teken i pg_hba.conf.

Kvar av dei blir handheva av ein annan komponent, og kvar av dei feilar med ei anna melding. Å smelte dei saman i ein diskusjon er måten folk endar opp med å redigere HBA-fila for å fikse eit brannmurproblem. Hald dei i rekkjefølgje: ein lyttar som ikkje er bunden, kan ikkje nåast, ein filtrert port kan det ikkje koplast til, og ein HBA-regel avgjer berre kva som skjer etter at ei tilkopling finst. Når ei endring ikkje har nokon effekt, identifiser kva av dei tre laga du faktisk endra.

Kvar tenaren lyttar

Bind til ei adresse som faktisk er tildelt maskinen, ikkje til eit grensesnittnamn:

listen_addresses = '10.20.0.30'

Databasen kan liggje bak VPN-gatewayen utan eige tunnelgrensesnitt, og det er nettopp derfor ei adresse er det rette å namngje. Endring av denne innstillinga krev ein full omstart; ei omlasting er ikkje nok.

Filtrer deretter porten, vanlegvis 5432, på verten og ved kvar grense framom han. Å binde til ei privat adresse er ikkje prov på offentleg avvising, fordi ei portvideresending eller ei skyadressetildeling framleis kan levere pakkar til den private lyttaren.

Adressa HBA faktisk ser

Med ruta tilgang ser tenaren den indre tunneladressa til kvar klient. Med kjeldeomsetjing ser han i staden den omsette adressa til gatewayen, og kvar klient fell saman til den eine verdien. Undersøk kjelda gjennom tenaren sine eigne tilkopling prov før du vel eit prefiks som skal tillatast.

For ein utrulling som allereie brukar TLS og SCRAM, ser eit medvite smalt døme på fjern tilgang slik ut:

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

Det tillèt éin rolle og éin database over TLS frå den oppgjevne poolen, og avviser deretter annan ekstern TCP-tilgang. Det er ikkje ei erstatning for ei fullstendig HBA-fil: hald lokal administrasjon, replikering og kvar annan autorisert teneste, og plasser dei smale reglane før breiare tillatingar.

Når omsetjing er i spel, kan ikkje HBA skilje klientar frå dei opphavlege adressene deira. Hald nettverkstilgangen stram og krev ekte databasepåloggingsinformasjon, og byt aldri ut trust-autentisering med ein faktisk konto.

Første treff vinn, utan reserveløysing

PostgreSQL les fila ovanfrå og ned og brukar den første posten som svarar til tilkoplinga. Det er ingen nytt forsøk om autentiseringa av den posten mislykkast, så ei tidlegare brei tillating slår stille ei seinare avvising.

Den rekkjefølgjeregelen er den vanlegaste grunnen til at ei nøye skriven avvising aldri trer i kraft. Set dei spesifikke reglane først og dei breie sist, og les deretter fila som ein sekvens i staden for som eit sett. Ein regel du la til nedst, er ikkje ein policy, det er ein kommentar. Flytt han opp og last på nytt før du konkluderer med at fila blir ignorert.

HBA-referansen definerer både rekkjefølgja og skilnaden mellom host- og hostssl-postar, noko som har noko å seie når poenget med regelen er at tilkoplinga må vere kryptert.

Omlasting, omstart og den avviste saka

HBA-endringar blir brukte ved ei omlasting, og visinga pg_hba_file_rules hjelper deg å finne parsefeil. Den visinga skildrar den noverande innhaldet i fila, ikkje om den køyrande tenaren lasta dei inn vellukka, så ei rein liste er ikkje prov på at dei nye reglane er aktive.

Endringar på lyttaren treng si eiga omstart, og dei to operasjonane er lette å forveksle når ei endring ser ut til ikkje å ha nokon effekt.

Test med ferske økter: ein godkjend klient med den tiltenkte kontoen koplar til, den same kontoen frå ein ikkje-godkjend veg gjer det ikkje, og ein uautorisert databaseidentitet feilar framleis frå innsida av VPN-en. Desse tre resultata skil nettverksgrensa frå databaseautorisasjon, som er heile poenget med å halde avgjerdene åtskilde.