PostgreSQL över ett VPN: vilken källadress pg_hba ser

PostgreSQL får aldrig veta att en klient är på ett VPN. Den tar emot en TCP-anslutning från en adress och en uppsättning autentiseringsuppgifter och avgör vad den ska göra med dem. Att göra åtkomsten beroende av tunneln innebär därför att ordna tre separata beslut så att de stämmer överens och sedan kontrollera den enda adress som servern faktiskt ser i stället för den du ritade på diagrammet.

Tre beslut som inte får smälta samman

Var servern lyssnar är ett beslut. Vilken trafik som kan nå den adressen är ett andra, fattat av värdens brandvägg och varje nätverksgräns framför den. Vilken databasidentitet som får autentisera från vilken källa är ett tredje, fattat i pg_hba.conf.

Varje upprätthålls av en annan komponent, och varje misslyckas med ett annat meddelande. Att smälta samman dem i en diskussion är hur folk till slut redigerar HBA-filen för att lösa ett brandväggsproblem. Håll dem i ordning: en lyssnare som inte är bunden kan inte nås, till en filtrerad port kan ingen ansluta, och en HBA-regel avgör bara vad som händer efter att en anslutning finns. När en ändring inte har någon effekt, identifiera vilket av de tre lagren du faktiskt ändrade.

Var servern lyssnar

Bind till en adress som faktiskt är tilldelad maskinen, inte till ett gränssnittsnamn:

listen_addresses = '10.20.0.30'

Databasen kan stå bakom VPN-gatewayen utan eget tunnelgränssnitt, och det är just därför en adress är rätt sak att namnge. Ändring av denna inställning kräver en fullständig omstart; en omladdning räcker inte.

Filtrera sedan porten, vanligtvis 5432, på värden och vid varje gräns framför den. Att binda till en privat adress är inte bevis på offentlig avvisning, eftersom en portvidarebefordran eller en molnadresstilldelning fortfarande kan leverera paket till den privata lyssnaren.

Adressen som HBA faktiskt ser

Med routad åtkomst ser servern varje klients inre tunneladress. Med källöversättning ser den i stället gatewayens översatta adress, och varje klient kollapsar till det enda värdet. Granska källan genom serverns egna anslutningsbevis innan du väljer ett prefix att tillåta.

För en distribution som redan använder TLS och SCRAM ser ett medvetet smalt exempel på fjärråtkomst ut så här:

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åter en roll och en databas över TLS från den angivna poolen och avvisar sedan annan extern TCP-åtkomst. Det ersätter inte en fullständig HBA-fil: behåll lokal administration, replikering och alla andra auktoriserade tjänster, och placera de smala reglerna före bredare tillstånd.

När översättning är i spel kan HBA inte skilja klienter åt efter deras ursprungliga adresser. Håll nätverksintaget strikt och kräv riktiga databasuppgifter, och ersätt aldrig trust-autentisering med ett faktiskt konto.

Första träffen vinner, utan reserv

PostgreSQL läser filen uppifrån och ned och använder den första posten som matchar anslutningen. Det finns inget andra försök om autentiseringen av den posten misslyckas, så ett tidigare brett tillstånd besegrar tyst ett senare avslag.

Den ordningsregeln är den vanligaste orsaken till att ett noggrant skrivet avslag aldrig träder i kraft. Sätt de specifika reglerna först och de breda sist, och läs sedan filen som en sekvens i stället för som en mängd. En regel du lade till längst ned är inte en policy, det är en kommentar. Flytta upp den och ladda om innan du drar slutsatsen att filen ignoreras.

HBA-referensen definierar både ordningen och skillnaden mellan host- och hostssl-poster, vilket spelar roll när poängen med regeln är att anslutningen måste vara krypterad.

Omladdning, omstart och det avvisade fallet

HBA-ändringar tillämpas genom en omladdning, och vyn pg_hba_file_rules hjälper dig att hitta tolkningsfel. Den vyn beskriver filens nuvarande innehåll, inte om den körande servern har laddat dem framgångsrikt, så en ren lista är inte bevis på att de nya reglerna är aktiva.

Ändringar av lyssnaren kräver sin egen omstart, och de två operationerna är lätta att förväxla när en ändring verkar sakna effekt.

Testa med färska sessioner: en godkänd klient med det avsedda kontot ansluter, samma konto från en icke godkänd väg gör det inte, och en obehörig databasidentitet misslyckas fortfarande inifrån VPN:et. Dessa tre resultat skiljer nätverksgränsen från databasauktorisering, vilket är hela poängen med att hålla besluten åtskilda.