PostgreSQL via een VPN: welk bronadres ziet pg_hba

Listener, firewall en de eerste passende HBA-regel zijn drie beslissingen. Controleer de bron die PostgreSQL werkelijk ontvangt voordat u een prefix kiest.

PostgreSQL komt er nooit achter dat een client op een VPN zit. Het ontvangt een TCP-verbinding van een adres en een set inloggegevens, en beslist wat het daarmee doet. Toegang van de tunnel afhankelijk maken betekent dus drie afzonderlijke beslissingen zo rangschikken dat ze overeenkomen, en dan het ene adres controleren dat de server werkelijk ziet in plaats van het adres dat u op het diagram hebt getekend.

Drie beslissingen die niet mogen samensmelten

Waar de server luistert is één beslissing. Welk verkeer dat adres kan bereiken is een tweede, genomen door de firewall van de host en elke netwerkgrens ervoor. Welke database-identiteit van welke bron mag authenticeren is een derde, genomen in pg_hba.conf.

Elk wordt afgedwongen door een andere component, en elk faalt met een andere melding. Ze in een discussie samenvoegen is hoe mensen uiteindelijk het HBA-bestand bewerken om een firewallprobleem op te lossen. Houd ze in volgorde: een listener die niet is gebonden is niet bereikbaar, op een gefilterde poort kan geen verbinding worden gemaakt, en een HBA-regel bepaalt alleen wat er gebeurt nadat een verbinding bestaat. Als een wijziging geen effect heeft, stel dan vast welke van de drie lagen u werkelijk hebt gewijzigd.

Waar de server luistert

Bind aan een adres dat werkelijk aan de machine is toegewezen, niet aan een interfacenaam:

listen_addresses = '10.20.0.30'

De database kan achter de VPN-gateway staan zonder eigen tunnelinterface, en dat is precies waarom een adres het juiste is om te benoemen. Deze instelling wijzigen vereist een volledige herstart; een herlaad is niet genoeg.

Filter vervolgens de poort, normaal 5432, op de host en bij elke grens ervoor. Binden aan een privéadres is geen bewijs van publieke weigering, omdat port forwarding of cloudadrestoewijzing nog steeds pakketten naar die privélistener kan afleveren.

Het adres dat de HBA werkelijk ziet

Bij gerouteerde toegang ziet de server het interne tunneladres van elke client. Bij brontranslatie ziet hij in plaats daarvan het vertaalde adres van de gateway, en elke client valt samen in die ene waarde. Onderzoek de bron via de eigen verbindingsbewijzen van de server voordat u een prefix kiest om toe te staan.

Voor een implementatie die al TLS en SCRAM gebruikt, ziet een bewust smal voorbeeld van toegang op afstand er zo uit:

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

Dat staat één rol en één database over TLS uit de genoemde pool toe, en weigert daarna andere externe TCP-toegang. Het is geen vervanging voor een volledig HBA-bestand: behoud lokaal beheer, replicatie en elke andere geautoriseerde dienst, en plaats de smalle regels vóór bredere toestemmingen.

Wanneer translatie in het spel is, kan de HBA clients niet onderscheiden op hun oorspronkelijke adressen. Houd netwerktoegang strikt en eis echte databasereferenties, en vervang nooit trust-authenticatie door een echt account.

De eerste overeenkomst wint, zonder terugval

PostgreSQL leest het bestand van boven naar beneden en gebruikt het eerste record dat bij de verbinding past. Er is geen tweede poging als de authenticatie van dat record mislukt, dus een eerdere brede toestemming verslaat stilzwijgend een latere weigering.

Die volgorderegel is de meest voorkomende reden waarom een zorgvuldig geschreven weigering nooit ingaat. Zet de specifieke regels eerst en de brede laatst, en lees het bestand dan als een reeks in plaats van als een verzameling. Een regel die u onderaan toevoegt is geen beleid, het is een opmerking. Verplaats hem naar boven en herlaad voordat u concludeert dat het bestand wordt genegeerd.

De HBA-referentie definieert zowel de volgorde als het verschil tussen host- en hostssl-records, wat belangrijk is wanneer het punt van de regel is dat de verbinding versleuteld moet zijn.

Herladen, herstarten en het geweigerde geval

HBA-wijzigingen worden toegepast met een herlaad, en de weergave pg_hba_file_rules helpt u parseerfouten te vinden. Die weergave beschrijft de huidige inhoud van het bestand, niet of de draaiende server ze succesvol heeft geladen, dus een schone lijst is geen bewijs dat de nieuwe regels actief zijn.

Wijzigingen aan de listener vereisen hun eigen herstart, en de twee bewerkingen zijn gemakkelijk te verwarren wanneer een wijziging geen effect lijkt te hebben.

Test met verse sessies: een goedgekeurde client met het beoogde account maakt verbinding, hetzelfde account vanaf een niet-goedgekeurd pad niet, en een ongeautoriseerde database-identiteit faalt nog steeds van binnen de VPN. Die drie resultaten scheiden de netwerkgrens van databaseautorisatie, wat het hele punt is van het gescheiden houden van de beslissingen.

Gerelateerde artikelen