PostgreSQL sa pamamagitan ng VPN: anong source address ang makikita ng pg_hba

Hindi kailanman nalalaman ng PostgreSQL na ang isang client ay nasa VPN. Tumanggap ito ng TCP connection mula sa isang address at isang set ng mga kredensyal, at nagpasya kung ano ang gagawin sa mga ito. Kaya ang paggawang nakadepende sa tunnel ang access ay nangangahulugang pagsasaayos ng tatlong hiwalay na desisyon upang magkasundo, at pagkatapos ay suriin ang nag-iisang address na talagang nakikita ng server sa halip na ang iginuhit mo sa diagram.

Tatlong desisyon na hindi dapat pagsamahin

Kung saan nakikinig ang server ay isang desisyon. Aling trapiko ang makakaabot sa address na iyon ay pangalawa, na ginagawa ng firewall ng host at anumang hangganan ng network sa harap nito. Aling identidad ng database ang maaaring magpatunay mula sa aling source ay pangatlo, na ginagawa sa pg_hba.conf.

Ang bawat isa ay ipinatutupad ng ibang bahagi, at ang bawat isa ay nabibigo sa ibang mensahe. Ang pagsasama-sama ng mga ito sa isang talakayan ang dahilan kung bakit nagwawakas ang mga tao sa pag-edit ng HBA file upang ayusin ang problema sa firewall. Panatilihin sila sa pagkakasunod-sunod: ang listener na hindi nakatali ay hindi maabot, ang na-filter na port ay hindi makakonekta, at ang HBA rule ay nagpapasya lamang kung ano ang mangyayari pagkatapos na may koneksyon. Kapag walang epekto ang isang pagbabago, tukuyin kung alin sa tatlong layer ang talagang binago mo.

Kung saan nakikinig ang server

Itali sa isang address na talagang itinalaga sa makina, hindi sa pangalan ng interface:

listen_addresses = '10.20.0.30'

Maaaring nasa likod ng VPN gateway ang database na walang sariling tunnel interface, at iyon mismo ang dahilan kung bakit address ang tamang bagay na pangalanan. Ang pagbabago ng setting na ito ay nangangailangan ng buong restart; hindi sapat ang reload.

Pagkatapos ay i-filter ang port, karaniwang 5432, sa host at sa bawat hangganan sa harap nito. Ang pagtali sa isang pribadong address ay hindi patunay ng pampublikong pagtanggi, dahil ang port forwarding o cloud address mapping ay maaari pa ring maghatid ng mga packet sa pribadong listener na iyon.

Ang address na talagang nakikita ng HBA

Sa naka-rutang access, nakikita ng server ang panloob na tunnel address ng bawat client. Sa pagsasalin ng source, nakikita nito ang isinaling address ng gateway sa halip, at ang bawat client ay bumagsak sa nag-iisang halagang iyon. Suriin ang source sa pamamagitan ng sariling ebidensya ng koneksyon ng server bago pumili ng prefix na papayagan.

Para sa deployment na gumagamit na ng TLS at SCRAM, ang sadyang makitid na halimbawa ng remote access ay ganito ang hitsura:

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

Pinapayagan nito ang isang role at isang database sa TLS mula sa nakasaad na pool, pagkatapos ay tinatanggihan ang iba pang remote TCP access. Hindi ito kapalit ng kumpletong HBA file: panatilihin ang lokal na administrasyon, replikasyon at anumang iba pang awtorisadong serbisyo, at ilagay ang makitid na mga rule bago ang mas malawak na pahintulot.

Kapag may pagsasalin, hindi matukoy ng HBA ang mga client sa pamamagitan ng kanilang orihinal na address. Panatilihing mahigpit ang pagtanggap sa network at humingi ng tunay na kredensyal ng database, at huwag kailanman palitan ang trust authentication ng isang tunay na account.

Ang unang tugma ang nananalo, walang reserba

Binabasa ng PostgreSQL ang file mula itaas pababa at ginagamit ang unang record na tugma sa koneksyon. Walang ikalawang pagtatangka kung nabigo ang pagpapatunay ng record na iyon, kaya ang naunang malawak na pahintulot ay tahimik na tinatalo ang mas huling pagtanggi.

Ang rule ng pagkakasunod-sunod na iyon ang pinakakaraniwang dahilan kung bakit ang maingat na isinulat na pagtanggi ay hindi kailanman nagkakabisa. Ilagay ang partikular na mga rule muna at ang malalawak sa huli, pagkatapos ay basahin ang file bilang isang sequence at hindi bilang isang set. Ang rule na idinagdag mo sa ibaba ay hindi patakaran, ito ay komento. Ilipat ito pataas at i-reload bago ka magpasyang binabalewala ang file.

HBA reference ang tumutukoy sa pagkakasunod-sunod at sa pagkakaiba sa pagitan ng host at hostssl records, na mahalaga kapag ang punto ng rule ay ang koneksyon ay dapat naka-encrypt.

Reload, restart at ang tinanggihang kaso

Ang mga pagbabago sa HBA ay inilalapat sa pamamagitan ng reload, at ang pg_hba_file_rules view ay tumutulong sa iyong mahanap ang mga parse error. Inilalarawan ng view na iyon ang kasalukuyang nilalaman ng file, hindi kung matagumpay na na-load ng tumatakbong server ang mga ito, kaya ang malinis na listahan ay hindi patunay na aktibo ang mga bagong rule.

Ang mga pagbabago sa listener ay nangangailangan ng sarili nitong restart, at ang dalawang operasyon ay madaling mapagkamalan kapag ang isang pagbabago ay tila walang epekto.

Subukan gamit ang mga bagong session: ang inaprubahang client na may nilalayong account ay kumokonekta, ang parehong account mula sa hindi aprubahadong landas ay hindi, at ang hindi awtorisadong identidad ng database ay nabibigo pa rin mula sa loob ng VPN. Ang tatlong resultang iyon ay naghihiwalay sa hangganan ng network mula sa awtorisasyon ng database, na siyang buong punto ng paghihiwalay ng mga desisyon.