PostgreSQL VPN:n yli: minkä lähdeosoitteen pg_hba näkee

PostgreSQL ei koskaan saa tietää, että asiakas on VPN:ssä. Se vastaanottaa TCP-yhteyden osoitteesta ja joukon tunnistetietoja ja päättää, mitä niille tehdä. Siksi pääsyn tekeminen tunnelista riippuvaiseksi tarkoittaa kolmen erillisen päätöksen järjestämistä niin, että ne sopivat yhteen, ja sitten sen yhden osoitteen tarkistamista, jonka palvelin todella näkee, eikä sen, jonka piirsit kaavioon.

Kolme päätöstä, joita ei saa yhdistää

Missä palvelin kuuntelee, on yksi päätös. Mikä liikenne voi päästä siihen osoitteeseen, on toinen, jonka tekevät isäntäkoneen palomuuri ja mikä tahansa verkkoraja sen edessä. Mikä tietokantaidentiteetti voi todentautua mistä lähteestä, on kolmas, joka tehdään tiedostossa pg_hba.conf.

Jokaisen toteuttaa eri komponentti, ja jokainen epäonnistuu eri viestillä. Niiden yhdistäminen keskustelussa johtaa siihen, että ihmiset päätyvät muokkaamaan HBA-tiedostoa palomuuriongelman korjaamiseksi. Pidä ne järjestyksessä: kuuntelija, jota ei ole sidottu, ei ole tavoitettavissa, suodatettuun porttiin ei voi muodostaa yhteyttä, ja HBA-sääntö päättää vain siitä, mitä tapahtuu sen jälkeen, kun yhteys on olemassa. Kun muutoksella ei ole vaikutusta, selvitä, mitä kolmesta kerroksesta todella muutit.

Missä palvelin kuuntelee

Sido osoitteeseen, joka on todella osoitettu koneelle, älä käyttöliittymän nimeen:

listen_addresses = '10.20.0.30'

Tietokanta voi sijaita VPN-portin takana ilman omaa tunnelikäyttöliittymää, ja juuri siksi osoite on oikea asia nimettäväksi. Tämän asetuksen muuttaminen vaatii täyden uudelleenkäynnistyksen; uudelleenlataus ei riitä.

Suodata sitten portti, yleensä 5432, isännässä ja jokaisella sen edessä olevalla rajalla. Yksityiseen osoitteeseen sitominen ei ole todiste julkisesta kiellosta, koska portin edelleenohjaus tai pilviosoitteen kartoitus voi silti toimittaa paketteja kyseiselle yksityiselle kuuntelijalle.

Osoite, jonka HBA todella näkee

Reititetyssä pääsyssä palvelin näkee jokaisen asiakkaan sisäisen tunneliosoitteen. Lähdeosoitteen käännöksessä se näkee sen sijaan portin käännetyn osoitteen, ja jokainen asiakas kutistuu yhdeksi arvoksi. Tutki lähdettä palvelimen omien yhteystodisteiden kautta ennen kuin valitset sallittavan etuliitteen.

Käyttöönotolle, joka käyttää jo TLS:ää ja SCRAM:ia, tarkoituksella kapea etäkäytön esimerkki näyttää tältä:

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

Se sallii yhden roolin ja yhden tietokannan TLS:n yli ilmoitetusta joukosta ja hylkää sitten muun etä-TCP-pääsyn. Se ei korvaa täydellistä HBA-tiedostoa: säilytä paikallinen ylläpito, replikointi ja mikä tahansa muu valtuutettu palvelu, ja sijoita kapeat säännöt laajempien sallimusten edelle.

Kun käännös on pelissä, HBA ei voi erottaa asiakkaita alkuperäisten osoitteidensa perusteella. Pidä verkkopääsy tiukkana ja vaadi todellisia tietokannan tunnistetietoja, äläkä koskaan korvaa trust-todennusta todellisella tilillä.

Ensimmäinen osuma voittaa, ilman varavaihtoehtoa

PostgreSQL lukee tiedoston ylhäältä alas ja käyttää ensimmäistä tietuetta, joka vastaa yhteyttä. Toista yritystä ei ole, jos kyseisen tietueen todennus epäonnistuu, joten aikaisempi laaja sallimus kukistaa hiljaisesti myöhemmän kiellon.

Tämä järjestyssääntö on yleisin syy siihen, miksi huolellisesti kirjoitettu kielto ei koskaan tule voimaan. Laita täsmälliset säännöt ensin ja laajat viimeiseksi ja lue tiedosto sitten sarjana eikä joukkona. Alareunaan lisäämäsi sääntö ei ole käytäntö, se on kommentti. Siirrä se ylös ja lataa uudelleen ennen kuin päättelet, että tiedosto jätetään huomiotta.

HBA-viite määrittelee sekä järjestyksen että eron host- ja hostssl-tietueiden välillä, millä on merkitystä, kun säännön tarkoitus on, että yhteyden on oltava salattu.

Uudelleenlataus, uudelleenkäynnistys ja hylätty tapaus

HBA-muutokset otetaan käyttöön uudelleenlatauksella, ja näkymä pg_hba_file_rules auttaa löytämään jäsennysvirheet. Tämä näkymä kuvaa tiedoston nykyistä sisältöä, ei sitä, latasiko käynnissä oleva palvelin ne onnistuneesti, joten puhdas luettelo ei ole todiste siitä, että uudet säännöt ovat voimassa.

Kuuntelijan muutokset vaativat oman uudelleenkäynnistyksensä, ja kaksi toimenpidettä on helppo sekoittaa, kun muutos näyttää olevan vailla vaikutusta.

Testaa tuoreilla istunnoilla: hyväksytty asiakas aiotulla tilillä yhdistää, sama tili hyväksymättömältä polulta ei, ja valtuuttamaton tietokantaidentiteetti epäonnistuu edelleen VPN:n sisältä. Nämä kolme tulosta erottavat verkkorajan tietokannan valtuutuksesta, ja juuri siinä on koko pointti pitää päätökset erillään.