PostgreSQL oer in VPN: hokker boarneadres sil pg_hba sjen

PostgreSQL komt nea efter dat in klant op in VPN sit. It ûntfangt in TCP-ferbining fan in adres en in set oanmeldgegevens, en beslút wat it dêrmei docht. Tagong fan de tunnel ôfhinklik meitsje betsjut dêrom trije aparte besluten sa regelje dat se oerienkomme, en dan it iene adres kontrolearje dat de tsjinner echt sjocht yn plak fan dat jo op it diagram tekene hawwe.

Trije besluten dy't net gearfoege wurde meie

Wêr't de tsjinner harket is ien beslút. Hokker ferkear dat adres berikke kin is in twadde, nommen troch de host-firewall en elke netwurkgrins dêrfoar. Hokker databankidentiteit fan hokker boarne autentisearje mei is in tredde, nommen yn pg_hba.conf.

Elk wurdt hanthavene troch in oare komponint, en elk mislearret mei in oare melding. Se yn in diskusje gearfoegje is hoe't minsken úteinliks it HBA-bestân bewurkje om in firewallprobleem op te lossen. Hâld se yn oarder: in harker dy't net bûn is kin net berikt wurde, in filtere poarte kin net mei ferbûn wurde, en in HBA-regel beslút allinnich wat der bart neidat in ferbining bestiet. As in wiziging gjin effekt hat, identifisearje hokker fan de trije lagen jo eins feroare hawwe.

Wêr't de tsjinner harket

Bin oan in adres dat echt oan de masine tawiisd is, net oan in ynterfacenamme:

listen_addresses = '10.20.0.30'

De databank kin efter de VPN-poarte sitte sûnder in eigen tunnelinterface, en dêrom is in adres krekt it goede ding om te neamen. It feroarjen fan dizze ynstelling fereasket in folsleine werstart; in werlade is net genôch.

Filterje dan de poarte, normaal 5432, op de host en by elke grins dêrfoar. Binen oan in privee-adres is gjin bewiis fan publike wegering, want in poartetrochferwizing of in wolkadrestawizing kin pakketten noch altyd by dy privee harker ôflosse.

It adres dat de HBA echt sjocht

By rûtearre tagong sjocht de tsjinner it ynterne tunneladres fan elke klant. By boarnetranslaasje sjocht er ynstee it oersetten adres fan 'e poarte, en elke klant falt gear yn dy iene wearde. Undersykje de boarne fia de eigen ferbiningsbewizen fan 'e tsjinner foardat jo in foarheaksel kieze om ta te litten.

Foar in útrulling dy't al TLS en SCRAM brûkt, sjocht in bewust smel foarbyld fan tagong op ôfstân der sa út:

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

Dat lit ien rol en ien databank oer TLS fan 'e neamde pool ta, en wegeret dan oare TCP-tagong op ôfstân. It is gjin ferfanging fan in folslein HBA-bestân: hâld pleatslike administraasje, replikaasje en elke oare autorisearre tsjinst, en pleatst de smelle regels foar bredere tastimmingen.

As translaasje yn it spul is, kin de HBA klanten net ûnderskiede op harren oarspronklike adressen. Hâld netwurktagong strak en easkje echte databank-oanmeldgegevens, en ferfange nea trust-autentikaasje troch in echte akkount.

De earste oerienkomst wint, sûnder reserveraasje

PostgreSQL lêst it bestân fan boppe nei ûnderen en brûkt it earste record dat by de ferbining past. Der is gjin twadde besykjen as de autentikaasje fan dat record mislearret, dus in eardere brede tastimming ferslaat stil in lettere wegering.

Dy oarderingsregel is de meast foarkommende reden wêrom't in soarchfâldich skreaune wegering nea fan krêft wurdt. Set de spesifike regels earst en de brede lêst, en lês it bestân dan as in searje yn plak fan as in set. In regel dy't jo ûnderoan tafoege hawwe is gjin belied, it is in kommentaar. Ferpleatse him omheech en werlade foardat jo konkludearje dat it bestân negearre wurdt.

De HBA-referinsje definiearret sawol de oarder as it ferskil tusken host- en hostssl-records, wat fan belang is as it punt fan 'e regel is dat de ferbining fersifere wêze moat.

Werlade, werstart en it wegere gefal

HBA-wizigings wurde tapast troch in werlade, en de werjefte pg_hba_file_rules helpt jo parseflaters te finen. Dy werjefte beskriuwt de hjoeddeiske ynhâld fan it bestân, net oft de rinnende tsjinner se suksesfol lade hat, dus in skjinne list is gjin bewiis dat de nije regels libje.

Wizigings oan 'e harker hawwe har eigen werstart nedich, en de twa operaasjes binne maklik te betiizjen as in wiziging gjin effekt liket te hawwen.

Test mei frisse sesjes: in goedkarde klant mei it bedoelde akkount ferbynt, itselde akkount fan in net-goedkard paad net, en in net-autorisearre databankidentiteit mislearret noch altyd fan binnen de VPN. Dy trije resultaten skiede de netwurkgrins fan databankautorisasje, dat is it hiele punt fan it apart hâlden fan de besluten.