PostgreSQL caur VPN: kādu avota adresi redzēs pg_hba

Klausītājs, ugunsmūris un pirmais atbilstošais HBA noteikums ir trīs lēmumi. Pārbaudiet avotu, ko PostgreSQL patiešām saņem, pirms izvēlaties prefiksu.

PostgreSQL nekad neuzzina, ka klients ir VPN. Tas saņem TCP savienojumu no adreses un akreditācijas datu kopu un izlemj, ko ar tiem darīt. Tāpēc piekļuves atkarību no tuneļa nodrošināt nozīmē sakārtot trīs atsevišķus lēmumus tā, lai tie saskanētu, un pēc tam pārbaudīt vienīgo adresi, ko serveris patiešām redz, nevis to, ko jūs uzzīmējāt diagrammā.

Trīs lēmumi, kurus nedrīkst sapludināt

Kur serveris klausās, ir viens lēmums. Kurš trafiks var sasniegt šo adresi, ir otrais, ko pieņem resursdatora ugunsmūris un jebkura tīkla robeža tā priekšā. Kura datubāzes identitāte var autentificēties no kura avota, ir trešais, kas pieņemts pg_hba.conf failā.

Katru no tiem īsteno cita komponente, un katrs neizdodas ar citu ziņojumu. To sapludināšana diskusijā ir iemesls, kāpēc cilvēki sāk rediģēt HBA failu, lai novērstu ugunsmūra problēmu. Turiet tos kārtībā: klausītāju, kas nav piesaistīts, nevar sasniegt, filtram pakļautam portam nevar pievienoties, un HBA noteikums izlemj tikai to, kas notiek pēc tam, kad savienojums pastāv. Kad izmaiņām nav efekta, nosakiet, kuru no trim slāņiem jūs faktiski mainījāt.

Kur serveris klausās

Piesaistiet adresei, kas faktiski piešķirta mašīnai, nevis interfeisa nosaukumam:

listen_addresses = '10.20.0.30'

Datubāze var atrasties aiz VPN vārtejas bez savas tuneļa saskarnes, un tieši tāpēc adrese ir tas pareizais, kas jānosauc. Šī iestatījuma maiņa prasa pilnīgu restartu; pārlades nepietiek.

Pēc tam filtrējiet portu, parasti 5432, resursdatorā un pie katras robežas tā priekšā. Piesaiste privātai adresei nav publiska atteikuma pierādījums, jo porta pāradresācija vai mākoņadreses kartēšana joprojām var nogādāt paketes šim privātajam klausītājam.

Adrese, ko HBA faktiski redz

Maršrutētas piekļuves gadījumā serveris redz katra klienta iekšējo tuneļa adresi. Avota tulkošanas gadījumā tas redz vārtejas tulkoto adresi, un katrs klients saplūst šajā vienā vērtībā. Pārbaudiet avotu, izmantojot paša servera savienojumu pierādījumus, pirms izvēlaties atļaujamo prefiksu.

Izvietojumam, kas jau izmanto TLS un SCRAM, apzināti šaurs attālinātās piekļuves piemērs izskatās šādi:

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

Tas atļauj vienu lomu un vienu datubāzi TLS ietvaros no norādītā kopuma, pēc tam noraida citas attālinātās TCP piekļuves. Tas neaizstāj pilnu HBA failu: saglabājiet vietējo administrēšanu, replikāciju un citus pilnvarotos pakalpojumus, un šauros noteikumus ievietojiet pirms plašākām atļaujām.

Kad tulkošana darbojas, HBA nevar atšķirt klientus pēc to sākotnējām adresēm. Turiet tīkla pieņemšanu stingru un pieprasiet īstus datubāzes akreditācijas datus, un nekad neaizstājiet trust autentifikāciju ar reālu kontu.

Uzvar pirmā atbilstība, bez rezerves

PostgreSQL lasa failu no augšas uz leju un izmanto pirmo ierakstu, kas atbilst savienojumam. Nav otrā mēģinājuma, ja šī ieraksta autentifikācija neizdodas, tāpēc agrāka plaša atļauja klusi uzvar vēlāku atteikumu.

Šis secības noteikums ir visbiežākais iemesls, kāpēc rūpīgi uzrakstīts atteikums nekad nestājas spēkā. Ievietojiet konkrētos noteikumus pirmos un plašos pēdējos, pēc tam lasiet failu kā secību, nevis kā kopu. Noteikums, ko pievienojāt apakšā, nav politika, tas ir komentārs. Pārvietojiet to uz augšu un pārlādējiet, pirms secināt, ka fails tiek ignorēts.

HBA atsauce definē gan secību, gan atšķirību starp host un hostssl ierakstiem, kas ir svarīgi, ja noteikuma būtība ir tāda, ka savienojumam jābūt šifrētam.

Pārlāde, restarts un noraidītais gadījums

HBA izmaiņas tiek piemērotas ar pārlādi, un skats pg_hba_file_rules palīdz atrast parsēšanas kļūdas. Šis skats apraksta pašreizējo faila saturu, nevis to, vai darbojošais serveris tos veiksmīgi ielādēja, tāpēc tīrs saraksts nav pierādījums, ka jaunie noteikumi darbojas.

Klausītāja izmaiņām nepieciešams savs restarts, un abas darbības ir viegli sajaukt, kad izmaiņām it kā nav efekta.

Pārbaudiet ar svaigām sesijām: apstiprināts klients ar paredzēto kontu savienojas, tas pats konts no neapstiprināta ceļa nesavienojas, un neatļauta datubāzes identitāte joprojām neizdodas no VPN iekšpuses. Šie trīs rezultāti atdala tīkla robežu no datubāzes autorizācijas, un tā ir visa lēmumu atdalīšanas jēga.

Saistītie raksti