PostgreSQL per VPN: kokį šaltinio adresą matys pg_hba

Klausytojas, užkarda ir pirmoji atitinkanti HBA taisyklė yra trys sprendimai. Patikrinkite šaltinį, kurį PostgreSQL iš tikrųjų gauna, prieš pasirinkdami priešdėlį.

PostgreSQL niekada nesužino, kad klientas yra VPN. Jis gauna TCP ryšį iš adreso ir prisijungimo duomenų rinkinį bei nusprendžia, ką su jais daryti. Todėl padaryti prieigą priklausomą nuo tunelio reiškia suderinti tris atskirus sprendimus, o tada patikrinti vienintelį adresą, kurį serveris iš tikrųjų mato, o ne tą, kurį nubraižėte diagramoje.

Trys sprendimai, kurių negalima sujungti

Kur serveris klausosi, yra vienas sprendimas. Kuris srautas gali pasiekti tą adresą, yra antras, kurį priima pagrindinio kompiuterio užkarda ir bet kokia tinklo riba prieš ją. Kuri duomenų bazės tapatybė gali autentifikuotis iš kurio šaltinio, yra trečias, priimamas pg_hba.conf faile.

Kiekvieną įgyvendina skirtingas komponentas, ir kiekvienas nepavyksta su skirtinga žinute. Jų sujungimas diskusijoje yra priežastis, dėl kurios žmonės pradeda redaguoti HBA failą, kad išspręstų užkardos problemą. Laikykite juos tvarkingai: nepririšto klausytojo pasiekti negalima, prie filtruoto prievado prisijungti negalima, o HBA taisyklė nusprendžia tik tai, kas vyksta po to, kai ryšys egzistuoja. Kai pakeitimas neturi poveikio, nustatykite, kurį iš trijų sluoksnių iš tikrųjų pakeitėte.

Kur serveris klausosi

Prisiriškite prie adreso, kuris iš tikrųjų priskirtas mašinai, o ne prie sąsajos pavadinimo:

listen_addresses = '10.20.0.30'

Duomenų bazė gali būti už VPN šliuzo be savo tunelio sąsajos, ir būtent todėl adresas yra tinkamas dalykas, kurį reikia pavadinti. Šio nustatymo pakeitimas reikalauja visiško paleidimo iš naujo; perkrovimo nepakanka.

Tada filtruokite prievadą, paprastai 5432, pagrindiniame kompiuteryje ir prie kiekvienos ribos prieš jį. Prisirišimas prie privataus adreso nėra viešo uždraudimo įrodymas, nes prievado persiuntimas ar debesies adreso susiejimas vis dar gali pristatyti paketus tam privačiam klausytojui.

Adresas, kurį HBA iš tikrųjų mato

Nukreiptos prieigos atveju serveris mato kiekvieno kliento vidinį tunelio adresą. Šaltinio vertimo atveju jis mato verčiamą šliuzo adresą, ir kiekvienas klientas susitraukia į tą vieną reikšmę. Išnagrinėkite šaltinį per paties serverio ryšio įrodymus prieš pasirinkdami leidžiamą priešdėlį.

Diegimui, kuriame jau naudojamas TLS ir SCRAM, sąmoningai siauras nuotolinės prieigos pavyzdys atrodo taip:

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

Tai leidžia vieną vaidmenį ir vieną duomenų bazę per TLS iš nurodyto telkinio, o tada atmeta kitą nuotolinę TCP prieigą. Tai nepakeičia viso HBA failo: palikite vietinę administraciją, replikaciją ir bet kurią kitą leistiną paslaugą, o siauras taisykles dėkite prieš platesnius leidimus.

Kai vyksta vertimas, HBA negali atskirti klientų pagal jų pradinius adresus. Laikykite tinklo priėmimą griežtą ir reikalaukite tikrų duomenų bazės prisijungimo duomenų, ir niekada nepakeiskite trust autentifikacijos tikra paskyra.

Laimi pirmasis atitikimas, be atsarginio varianto

PostgreSQL skaito failą iš viršaus į apačią ir naudoja pirmąjį įrašą, kuris atitinka ryšį. Nėra antro bandymo, jei to įrašo autentifikacija nepavyksta, todėl ankstesnis platus leidimas tyliai nugali vėlesnį uždraudimą.

Ši eiliškumo taisyklė yra dažniausia priežastis, kodėl kruopščiai parašytas uždraudimas niekada neįsigalioja. Dėkite konkrečias taisykles pirmiausia, o plačias paskiausiai, tada skaitykite failą kaip seką, o ne kaip rinkinį. Taisyklė, kurią pridėjote apačioje, nėra politika, tai komentaras. Perkelkite ją aukščiau ir įkelkite iš naujo, prieš darydami išvadą, kad failas ignoruojamas.

HBA nuoroda apibrėžia ir tvarką, ir skirtumą tarp host ir hostssl įrašų, o tai svarbu, kai taisyklės esmė yra ta, kad ryšys turi būti šifruotas.

Perkrovimas, paleidimas iš naujo ir atmestas atvejis

HBA pakeitimai taikomi perkraunant, o rodinys pg_hba_file_rules padeda rasti analizės klaidas. Tas rodinys aprašo dabartinį failo turinį, o ne tai, ar veikiantis serveris juos sėkmingai įkėlė, todėl švarus sąrašas nėra įrodymas, kad naujos taisyklės galioja.

Klausytojo pakeitimams reikia atskiro paleidimo iš naujo, ir abi operacijos lengvai supainiojamos, kai pakeitimas atrodo neturintis poveikio.

Išbandykite su naujomis sesijomis: patvirtintas klientas su numatyta paskyra prisijungia, ta pati paskyra iš nepatvirtinto kelio ne, o neleistina duomenų bazės tapatybė vis tiek nepavyksta iš VPN vidaus. Šie trys rezultatai atskiria tinklo ribą nuo duomenų bazės autorizacijos, o tai ir yra visas sprendimų atskyrimo tikslas.

Susiję straipsniai