PostgreSQL over en VPN: hvilken kildeadresse pg_hba ser

PostgreSQL finder aldrig ud af, at en klient er på en VPN. Den modtager en TCP-forbindelse fra en adresse og et sæt legitimationsoplysninger og beslutter, hvad den vil gøre med dem. At gøre adgang afhængig af tunnelen betyder derfor at arrangere tre separate beslutninger, så de stemmer overens, og derefter kontrollere den ene adresse, som serveren faktisk ser i stedet for den, du tegnede på diagrammet.

Tre beslutninger, der ikke må smelte sammen

Hvor serveren lytter, er én beslutning. Hvilken trafik der kan nå den adresse, er en anden, truffet af værtens firewall og enhver netværksgrænse foran den. Hvilken databaseidentitet der må godkende fra hvilken kilde, er en tredje, truffet i pg_hba.conf.

Hver af dem håndhæves af en forskellig komponent, og hver af dem fejler med en forskellig meddelelse. At smelte dem sammen i en diskussion er måden, hvorpå folk ender med at redigere HBA-filen for at løse et firewallproblem. Hold dem i rækkefølge: en lytter, der ikke er bundet, kan ikke nås, en filtreret port kan der ikke oprettes forbindelse til, og en HBA-regel afgør kun, hvad der sker, efter at en forbindelse findes. Når en ændring ikke har nogen effekt, skal du identificere, hvilket af de tre lag du faktisk ændrede.

Hvor serveren lytter

Bind til en adresse, der faktisk er tildelt maskinen, ikke til et interfacenavn:

listen_addresses = '10.20.0.30'

Databasen kan ligge bag VPN-gatewayen uden sin egen tunnelinterface, og det er netop derfor, en adresse er det rigtige at navngive. Ændring af denne indstilling kræver en fuld genstart; en genindlæsning er ikke nok.

Filtrér derefter porten, normalt 5432, på værten og ved hver grænse foran den. Binding til en privat adresse er ikke bevis på offentlig afvisning, fordi en portvideresendelse eller en cloud-adresstilknytning stadig kan levere pakker til den private lytter.

Den adresse, HBA faktisk ser

Med routet adgang ser serveren hver klients indre tunneladresse. Med kildetranslation ser den i stedet gatewayens oversatte adresse, og hver klient falder sammen til den ene værdi. Undersøg kilden gennem serverens egne forbindelsesbeviser, før du vælger et præfiks, der skal tillades.

For en udrulning, der allerede bruger TLS og SCRAM, ser et bevidst snævert eksempel på fjernadgang sådan ud:

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 tillader én rolle og én database over TLS fra den angivne pulje og afviser derefter anden ekstern TCP-adgang. Det er ikke en erstatning for en komplet HBA-fil: behold lokal administration, replikering og enhver anden autoriseret tjeneste, og anbring de snævre regler før bredere tilladelser.

Når translation er i spil, kan HBA ikke skelne klienter ud fra deres oprindelige adresser. Hold netværksadgangen stram, og kræv rigtige databaselegitimationsoplysninger, og erstat aldrig trust-godkendelse med en faktisk konto.

Første match vinder, uden reserve

PostgreSQL læser filen fra top til bund og bruger den første post, der matcher forbindelsen. Der er ingen anden forsøg, hvis den posts godkendelse mislykkes, så en tidligere bred tilladelse besejrer stille en senere afvisning.

Den rækkefølgeregel er den mest almindelige grund til, at en omhyggeligt skrevet afvisning aldrig træder i kraft. Sæt de specifikke regler først og de brede sidst, og læs derefter filen som en sekvens i stedet for som et sæt. En regel, du tilføjede i bunden, er ikke en politik, den er en kommentar. Flyt den op, og genindlæs, før du konkluderer, at filen ignoreres.

HBA-reference definerer både rækkefølgen og forskellen mellem host- og hostssl-poster, hvilket betyder noget, når reglens pointe er, at forbindelsen skal være krypteret.

Genindlæsning, genstart og den afviste sag

HBA-ændringer anvendes ved en genindlæsning, og visningen pg_hba_file_rules hjælper dig med at finde parsefejl. Den visning beskriver filens aktuelle indhold, ikke om den kørende server har indlæst dem korrekt, så en ren liste er ikke bevis på, at de nye regler er aktive.

Ændringer i lytteren kræver deres egen genstart, og de to operationer er lette at forveksle, når en ændring ser ud til ikke at have nogen effekt.

Test med friske sessioner: en godkendt klient med den tilsigtede konto opretter forbindelse, den samme konto fra en ikke-godkendt vej gør ikke, og en uautoriseret databaseidentitet fejler stadig indefra VPN'en. De tre resultater adskiller netværksgrænsen fra databaseautorisation, hvilket er hele pointen med at holde beslutningerne adskilt.