PostgreSQL prin VPN: ce adresă sursă va vedea pg_hba

PostgreSQL nu află niciodată că un client este într-o VPN. Primește o conexiune TCP de la o adresă și un set de credențiale și decide ce să facă cu ele. A face accesul dependent de tunel înseamnă deci a aranja trei decizii separate astfel încât să fie de acord, apoi a verifica singura adresă pe care serverul o vede efectiv în loc de cea desenată pe diagramă.

Trei decizii care nu trebuie fuzionate

Unde ascultă serverul este o decizie. Ce trafic poate ajunge la acea adresă este a doua, luată de firewallul gazdei și de orice graniță de rețea din fața lui. Ce identitate de bază de date se poate autentifica din ce sursă este a treia, luată în pg_hba.conf.

Fiecare este impusă de o componentă diferită și fiecare eșuează cu un mesaj diferit. Fuzionarea lor într-o discuție este modul în care oamenii ajung să editeze fișierul HBA pentru a repara o problemă de firewall. Păstrați-le în ordine: un listener care nu este legat nu poate fi atins, la un port filtrat nu te poți conecta, iar o regulă HBA decide doar ce se întâmplă după ce există o conexiune. Când o modificare nu are efect, identificați care dintre cele trei straturi l-ați schimbat efectiv.

Unde ascultă serverul

Legați-vă de o adresă care este efectiv atribuită mașinii, nu de un nume de interfață:

listen_addresses = '10.20.0.30'

Baza de date poate sta în spatele gatewayului VPN fără o interfață de tunel proprie, și exact de aceea o adresă este lucrul potrivit de numit. Modificarea acestei setări necesită o repornire completă; o reîncărcare nu este suficientă.

Apoi filtrați portul, de obicei 5432, pe gazdă și la fiecare graniță din fața ei. Legarea de o adresă privată nu este dovadă a refuzului public, deoarece o redirecționare de port sau o mapare de adresă în cloud poate livra în continuare pachete acelui listener privat.

Adresa pe care HBA o vede efectiv

Cu acces rutat, serverul vede adresa internă a tunelului fiecărui client. Cu traducerea sursei vede în schimb adresa tradusă a gatewayului, iar fiecare client se prăbușește în acea singură valoare. Inspectați sursa prin dovezile de conexiune ale serverului însuși înainte de a alege un prefix de permis.

Pentru o implementare care folosește deja TLS și SCRAM, un exemplu deliberat îngust de acces la distanță arată astfel:

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

Aceasta permite un rol și o bază de date prin TLS din poolul indicat, apoi respinge alt acces TCP la distanță. Nu înlocuiește un fișier HBA complet: păstrați administrarea locală, replicarea și orice alt serviciu autorizat, și plasați regulile înguste înaintea permisiunilor mai largi.

Când traducerea este în joc, HBA nu poate distinge clienții după adresele lor originale. Păstrați admiterea în rețea strictă și cereți credențiale reale de bază de date, și nu înlocuiți niciodată autentificarea trust cu un cont real.

Câștigă prima potrivire, fără rezervă

PostgreSQL citește fișierul de sus în jos și folosește prima înregistrare care se potrivește conexiunii. Nu există o a doua încercare dacă autentificarea acelei înregistrări eșuează, așa că o permisiune largă anterioară învinge în tăcere o respingere ulterioară.

Acea regulă de ordine este cel mai frecvent motiv pentru care o respingere scrisă cu grijă nu intră niciodată în vigoare. Puneți regulile specifice primele și pe cele largi la final, apoi citiți fișierul ca o secvență, nu ca o mulțime. O regulă adăugată la final nu este o politică, este un comentariu. Mutați-o mai sus și reîncărcați înainte de a concluziona că fișierul este ignorat.

Referința HBA definește atât ordinea, cât și diferența dintre înregistrările host și hostssl, ceea ce contează când scopul regulii este ca conexiunea să fie criptată.

Reîncărcare, repornire și cazul respins

Modificările HBA sunt aplicate printr-o reîncărcare, iar vizualizarea pg_hba_file_rules vă ajută să găsiți erori de analiză. Acea vizualizare descrie conținutul actual al fișierului, nu dacă serverul în execuție le-a încărcat cu succes, așa că o listă curată nu este dovada că noile reguli sunt active.

Modificările listenerului necesită propria repornire, iar cele două operații se confundă ușor când o modificare pare să nu aibă efect.

Testați cu sesiuni noi: un client aprobat cu contul prevăzut se conectează, același cont dintr-o cale neaprobată nu, iar o identitate de bază de date neautorizată eșuează în continuare din interiorul VPN. Aceste trei rezultate separă granița de rețea de autorizarea bazei de date, care este întregul sens al păstrării deciziilor separate.