PostgreSQL over en VPN: hvilken kildeadresse pg_hba ser

PostgreSQL får aldri vite at en klient er på en VPN. Den mottar en TCP-tilkobling fra en adresse og et sett med påloggingsinformasjon, og avgjør hva den skal gjøre med dem. Å gjøre tilgangen avhengig av tunnelen betyr derfor å ordne tre separate beslutninger slik at de stemmer overens, og deretter kontrollere den ene adressen som serveren faktisk ser i stedet for den du tegnet på diagrammet.

Tre beslutninger som ikke må smelte sammen

Hvor serveren lytter, er én beslutning. Hvilken trafikk som kan nå den adressen, er en andre, tatt av vertens brannmur og enhver nettverksgrense foran den. Hvilken databaseidentitet som kan autentisere fra hvilken kilde, er en tredje, tatt i pg_hba.conf.

Hver av dem håndheves av en forskjellig komponent, og hver av dem feiler med en forskjellig melding. Å smelte dem sammen i en diskusjon er måten folk ender opp med å redigere HBA-filen for å fikse et brannmurproblem. Hold dem i rekkefølge: en lytter som ikke er bundet, kan ikke nås, en filtrert port kan det ikke kobles til, og en HBA-regel avgjør bare hva som skjer etter at en tilkobling finnes. Når en endring ikke har noen effekt, identifiser hvilket av de tre lagene du faktisk endret.

Hvor serveren lytter

Bind til en adresse som faktisk er tildelt maskinen, ikke til et grensesnittnavn:

listen_addresses = '10.20.0.30'

Databasen kan ligge bak VPN-gatewayen uten eget tunnelgrensesnitt, og det er nettopp derfor en adresse er det riktige å navngi. Endring av denne innstillingen krever en full omstart; en omlasting er ikke nok.

Filtrer deretter porten, vanligvis 5432, på verten og ved hver grense foran den. Å binde til en privat adresse er ikke bevis på offentlig avvisning, fordi en portvideresending eller en skyadressetilordning fortsatt kan levere pakker til den private lytteren.

Adressen HBA faktisk ser

Med rutet tilgang ser serveren den indre tunneladressen til hver klient. Med kildeoversettelse ser den i stedet gatewayens oversatte adresse, og hver klient faller sammen til den ene verdien. Undersøk kilden gjennom serverens egne tilkoblingsbevis før du velger et prefiks som skal tillates.

For en utrulling som allerede bruker TLS og SCRAM, ser et bevisst smalt eksempel på fjernadgang 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 tillater én rolle og én database over TLS fra den angitte poolen, og avviser deretter annen ekstern TCP-tilgang. Det er ikke en erstatning for en fullstendig HBA-fil: behold lokal administrasjon, replikering og enhver annen autorisert tjeneste, og plasser de smale reglene før bredere tillatelser.

Når oversettelse er i spill, kan ikke HBA skille klienter fra deres opprinnelige adresser. Hold nettverkstilgangen stram og krev ekte databasepåloggingsinformasjon, og bytt aldri ut trust-autentisering med en faktisk konto.

Første treff vinner, uten reserveløsning

PostgreSQL leser filen ovenfra og ned og bruker den første posten som samsvarer med tilkoblingen. Det er ingen nytt forsøk hvis autentiseringen av den posten mislykkes, så en tidligere bred tillatelse beseirer stille en senere avvisning.

Den rekkefølgeregelen er den vanligste grunnen til at en nøye skrevet avvisning aldri trer i kraft. Sett de spesifikke reglene først og de brede sist, og les deretter filen som en sekvens i stedet for som et sett. En regel du la til nederst, er ikke en policy, det er en kommentar. Flytt den opp og last på nytt før du konkluderer med at filen ignoreres.

HBA-referansen definerer både rekkefølgen og forskjellen mellom host- og hostssl-poster, noe som betyr noe når poenget med regelen er at tilkoblingen må være kryptert.

Omlasting, omstart og den avviste saken

HBA-endringer brukes ved en omlasting, og visningen pg_hba_file_rules hjelper deg med å finne parsefeil. Den visningen beskriver filens nåværende innhold, ikke om den kjørende serveren lastet dem inn vellykket, så en ren liste er ikke bevis på at de nye reglene er aktive.

Endringer på lytteren trenger sin egen omstart, og de to operasjonene er lette å forveksle når en endring ser ut til å ikke ha noen effekt.

Test med ferske økter: en godkjent klient med den tiltenkte kontoen kobles til, den samme kontoen fra en ikke-godkjent vei gjør det ikke, og en uautorisert databaseidentitet feiler fortsatt fra innsiden av VPN-en. Disse tre resultatene skiller nettverksgrensen fra databaseautorisasjon, som er hele poenget med å holde beslutningene adskilt.