PostgreSQL oor 'n VPN: watter bronadres sal pg_hba sien

PostgreSQL kom nooit agter dat 'n kliënt op 'n VPN is nie. Dit ontvang 'n TCP-verbinding van 'n adres en 'n stel geloofsbriewe, en besluit wat om daarmee te doen. Om toegang van die tonnel afhanklik te maak, beteken dus om drie afsonderlike besluite so te reël dat hulle ooreenstem, en dan die een adres wat die bediener werklik sien na te gaan eerder as die een wat jy op die diagram geteken het.

Drie besluite wat nie mag saamsmelt nie

Waar die bediener luister, is een besluit. Watter verkeer daardie adres kan bereik, is 'n tweede, gemaak deur die gasheerfirewall en enige netwerkgrens daarvoor. Watter databasisidentiteit van watter bron mag verifieer, is 'n derde, gemaak in pg_hba.conf.

Elkeen word deur 'n ander komponent afgedwing, en elkeen misluk met 'n ander boodskap. Om hulle in 'n gesprek te vermeng, is hoe mense uiteindelik die HBA-lêer redigeer om 'n firewallprobleem op te los. Hou hulle in orde: 'n luisteraar wat nie gebind is nie, kan nie bereik word nie, 'n gefiltreerde poort kan nie gekonnekteer word nie, en 'n HBA-reël besluit net wat gebeur nadat 'n verbinding bestaan. Wanneer 'n verandering geen effek het nie, identifiseer watter van die drie lae jy werklik verander het.

Waar die bediener luister

Bind aan 'n adres wat werklik aan die masjien toegeken is, nie aan 'n koppelvlaknaam nie:

listen_addresses = '10.20.0.30'

Die databasis kan agter die VPN-gwey sit sonder 'n tonnelkoppelvlak van sy eie, en dit is juis waarom 'n adres die regte ding is om te noem. Om hierdie instelling te verander, vereis 'n volle herbegin; 'n herlaai is nie genoeg nie.

Filtreer dan die poort, gewoonlik 5432, op die gasheer en by elke grens daarvoor. Om aan 'n private adres te bind, is nie bewys van openbare weiering nie, want 'n poortaanstuur of 'n wolkeadrestoewysing kan steeds pakkette aan daardie private luisteraar lewer.

Die adres wat die HBA werklik sien

Met geroteerde toegang sien die bediener elke kliënt se binne-tonneladres. Met brontoewysing sien dit eerder die gwey se toegewysde adres, en elke kliënt val saam in daardie enkele waarde. Ondersoek die bron deur die bediener se eie verbindingsbewyse voordat jy 'n voorvoegsel kies om toe te laat.

Vir 'n ontplooiing wat reeds TLS en SCRAM gebruik, lyk 'n doelbewus smal voorbeeld van afstandtoegang so:

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

Dit laat een rol en een databasis oor TLS vanaf die genoemde poel toe, en weier dan ander afstand-TCP-toegang. Dit is nie 'n plaasvervanger vir 'n volledige HBA-lêer nie: hou plaaslike administrasie, replikasie en enige ander gemagtigde diens, en plaas die smal reëls voor breër toelatings.

Wanneer toewysing in die spel is, kan die HBA kliënte nie aan hul oorspronklike adresse onderskei nie. Hou netwerktoelating streng en vereis werklike databasisgeloofsbriewe, en vervang nooit trust-verifikasie met 'n werklike rekening nie.

Eerste passing wen, sonder terugval

PostgreSQL lees die lêer van bo na onder en gebruik die eerste rekord wat by die verbinding pas. Daar is geen tweede poging as daardie rekord se verifikasie misluk nie, so 'n vroeë breë toelating verslaan stilweg 'n latere weiering.

Daardie ordeningsreël is die mees algemene rede waarom 'n sorgvuldig geskrewe weiering nooit in werking tree nie. Sit die spesifieke reëls eerste en die breë laaste, en lees dan die lêer as 'n reeks eerder as as 'n stel. 'n Reël wat jy onderaan bygevoeg het, is nie 'n beleid nie, dit is 'n kommentaar. Skuif dit op en herlaai voordat jy tot die gevolgtrekking kom dat die lêer geïgnoreer word.

Die HBA-verwysing definieer beide die orde en die verskil tussen host- en hostssl-rekords, wat saak maak wanneer die punt van die reël is dat die verbinding geënkripteer moet wees.

Herlaai, herbegin en die geweierde geval

HBA-veranderinge word deur 'n herlaai toegepas, en die pg_hba_file_rules-aansig help jou om ontledingsfoute te vind. Daardie aansig beskryf die lêer se huidige inhoud, nie of die lopende bediener dit suksesvol gelaai het nie, so 'n skoon lys is nie bewys dat die nuwe reëls lewendig is nie.

Luisteraarveranderinge benodig hul eie herbegin, en die twee bewerkings is maklik om te verwar wanneer 'n verandering lyk of dit geen effek het nie.

Toets met vars sessies: 'n goedgekeurde kliënt met die beoogde rekening verbind, dieselfde rekening vanaf 'n nie-goedgekeurde pad nie, en 'n ongemagtigde databasisidentiteit misluk steeds van binne die VPN. Daardie drie resultate skei die netwerkgrens van databasisgemagtiging, wat die hele punt is om die besluite apart te hou.