PostgreSQL tra VPN: kiun fontan adreson vidos pg_hba

PostgreSQL neniam ekscias, ke kliento estas en VPN. Ĝi ricevas TCP-konekton de adreso kaj aron de akreditaĵoj, kaj decidas, kion fari kun ili. Do igi aliron dependa de la tunelo signifas aranĝi tri apartajn decidojn tiel, ke ili kongruu, kaj poste kontroli la solan adreson, kiun la servilo efektive vidas anstataŭ tiun, kiun vi desegnis en la diagramo.

Tri decidoj, kiuj ne devas kunfandiĝi

Kie la servilo aŭskultas estas unu decido. Kiun trafikon povas atingi tiun adreson estas dua, farata de la gastiga fajroŝirmilo kaj ajna retlimo antaŭ ĝi. Kiu datumbaza identeco rajtas aŭtentigi de kiu fonto estas tria, farata en pg_hba.conf.

Ĉiun el ili plenumas malsama komponanto, kaj ĉiu malsukcesas per malsama mesaĝo. Kunfandi ilin en diskuto estas kiel homoj finas redaktante la HBA-dosieron por ripari fajroŝirmilan problemon. Tenu ilin en ordo: aŭskultanto, kiu ne estas ligita, ne estas atingebla, al filtrita pordo oni ne povas konektiĝi, kaj HBA-regulo decidas nur, kio okazas post kiam konekto ekzistas. Kiam ŝanĝo havas neniun efikon, identigu, kiun el la tri tavoloj vi efektive ŝanĝis.

Kie la servilo aŭskultas

Ligu al adreso, kiu efektive estas atribuita al la maŝino, ne al interfaca nomo:

listen_addresses = '10.20.0.30'

La datumbazo povas stari malantaŭ la VPN-pordego sen propra tunela interfaco, kaj ĝuste tial adreso estas la ĝusta afero nomenda. Ŝanĝi ĉi tiun agordon postulas plenan restartigon; reŝargo ne sufiĉas.

Poste filtru la pordon, kutime 5432, sur la gastigo kaj ĉe ĉiu limo antaŭ ĝi. Ligi al privata adreso ne estas pruvo de publika rifuzo, ĉar pordan plusendadon aŭ nuban adresmapigon povas ankoraŭ liveri pakojn al tiu privata aŭskultanto.

La adreso, kiun HBA efektive vidas

Ĉe vojmigita aliro la servilo vidas la internan tunelan adreson de ĉiu kliento. Ĉe fonta traduko ĝi vidas anstataŭe la tradukitan adreson de la pordego, kaj ĉiu kliento kolapsas en tiun solan valoron. Ekzamenu la fonton per la propraj konektaj pruvoj de la servilo antaŭ ol elekti prefikson por permesi.

Por disfaldiĝo, kiu jam uzas TLS kaj SCRAM, intence mallarĝa ekzemplo de fora aliro aspektas tiel:

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

Tio permesas unu rolon kaj unu datumbazon super TLS el la indikita naĝejo, poste rifuzas alian foran TCP-aliron. Ĝi ne anstataŭas kompletan HBA-dosieron: konservu lokan administradon, reproduktadon kaj ajnan alian rajtigitan servon, kaj metu la mallarĝajn regulojn antaŭ pli larĝaj permesoj.

Kiam traduko estas en la ludo, HBA ne povas distingi klientojn per iliaj originaj adresoj. Tenu retan eniron streĉa kaj postulu verajn datumbazajn akreditaĵojn, kaj neniam anstataŭigu trust-aŭtentigadon per fakta konto.

La unua kongruo gajnas, sen rezervo

PostgreSQL legas la dosieron de supre malsupren kaj uzas la unuan rikordon, kiu kongruas kun la konekto. Ne ekzistas dua provo, se la aŭtentigado de tiu rikordo malsukcesas, do pli frua larĝa permeso silente venkas pli postan rifuzon.

Tiu ordoregulo estas la plej ofta kialo, ke zorgeme verkita rifuzo neniam ekvalidas. Metu la specifajn regulojn unue kaj la larĝajn laste, poste legu la dosieron kiel sinsekvon anstataŭ kiel aron. Regulo, kiun vi aldonis ĉe la fundo, ne estas politiko, ĝi estas komento. Movu ĝin supren kaj reŝargu antaŭ ol konkludi, ke la dosiero estas ignorata.

La HBA-referenco difinas kaj la ordon kaj la diferencon inter rikordoj host kaj hostssl, kio gravas kiam la senco de la regulo estas, ke la konekto devas esti ĉifrita.

Reŝargo, restartigo kaj la rifuzita kazo

HBA-ŝanĝoj aplikiĝas per reŝargo, kaj la vido pg_hba_file_rules helpas vin trovi analizajn erarojn. Tiu vido priskribas la nunan enhavon de la dosiero, ne ĉu la funkcianta servilo sukcese ŝargis ilin, do pura listo ne estas pruvo, ke la novaj reguloj estas aktivaj.

Ŝanĝoj al la aŭskultanto bezonas sian propran restartigon, kaj la du operaciojn facilas konfuzi kiam ŝanĝo ŝajnas havi neniun efikon.

Testu per freŝaj sesioj: aprobita kliento kun la celita konto konektiĝas, la sama konto el neaprobita vojo ne, kaj neaŭtorizita datumbaza identeco ankoraŭ malsukcesas de interne de la VPN. Tiuj tri rezultoj apartigas la retlimon de la datumbaza rajtigo, kio estas la tuta senco de teni la decidojn aparte.