PostgreSQL преко VPN-а: коју изворну адресу ће видети pg_hba
Слушалац, заштитни зид и прво правило HBA које се поклапа су три одлуке. Проверите извор који PostgreSQL заиста прима пре него што изаберете префикс.
PostgreSQL никада не сазна да је клијент на VPN-у. Прима TCP везу са неке адресе и скуп акредитива и одлучује шта ће с њима. Зато учинити приступ зависним од тунела значи ускладити три одвојене одлуке, а затим проверити једину адресу коју сервер заиста види, уместо оне коју сте нацртали на дијаграму.
Три одлуке које се не смеју спојити
Где сервер слуша једна је одлука. Који саобраћај може доћи до те адресе друга је, коју доноси заштитни зид на хосту и свака мрежна граница испред њега. Који се идентитет базе података може аутентификовати са ког извора трећа је, донета у pg_hba.conf.
Сваку од њих спроводи друга компонента и свака пада са другом поруком. Њихово спајање у расправи начин је на који људи заврше с уређивањем HBA датотеке да би поправили проблем заштитног зида. Држите их у реду: слушалац који није везан не може се достићи, на филтрирани порт не може се повезати, а HBA правило одлучује само о томе шта се дешава након што веза постоји. Када промена нема учинка, утврдите који сте од три слоја заиста променили.
Где сервер слуша
Вежите се на адресу која је заиста додељена машини, а не на назив интерфејса:
listen_addresses = '10.20.0.30'База података може стајати иза VPN пролаза без сопственог тунелског интерфејса, и управо је зато адреса права ствар коју треба именовати. Промена овог подешавања захтева потпуно поновно покретање; поновно учитавање није довољно.
Затим филтрирајте порт, обично 5432, на хосту и на свакој граници испред њега. Везивање на приватну адресу није доказ јавног одбијања, јер прослеђивање порта или мапирање облачне адресе и даље може доставити пакете том приватном слушаоцу.
Адреса коју HBA заиста види
Са рутираним приступом сервер види унутрашњу тунелску адресу сваког клијента. Са транслацијом извора уместо тога види преведену адресу пролаза и сваки клијент се сажима у ту једну вредност. Испитајте извор кроз сопствене доказе о везама сервера пре него што изаберете префикс који ћете дозволити.
За распоређивање које већ користи TLS и SCRAM, намерно узан пример удаљеног приступа изгледа овако:
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То дозвољава једну улогу и једну базу података преко TLS-а из наведеног пула, а затим одбија остали удаљени TCP приступ. То није замена за потпуну HBA датотеку: задржите локалну администрацију, репликацију и било коју другу овлашћену услугу, а уска правила ставите пре ширих дозвола.
Када је транслација у игри, HBA не може разликовати клијенте по њиховим изворним адресама. Држите мрежни пријем чврстим и захтевајте стварне акредитиве базе података, и никада не замењујте trust аутентификацију стварним налогом.
Прво поклапање побеђује, без резерве
PostgreSQL чита датотеку одозго надоле и користи први запис који се поклапа са везом. Нема другог покушаја ако аутентификација тог записа не успе, па раније широко допуштење тихо побеђује касније одбијање.
То правило реда најчешћи је разлог зашто пажљиво написано одбијање никада не ступи на снагу. Ставите специфична правила прва, а широка последња, па читајте датотеку као низ, а не као скуп. Правило које сте додали на дно није политика, то је коментар. Померите га горе и поново учитајте пре него што закључите да се датотека игнорише.
HBA референца дефинише и ред и разлику између записа host и hostssl, што је важно када је поента правила да веза мора бити шифрована.
Поновно учитавање, поновно покретање и одбијени случај
Промене HBA се примењују поновним учитавањем, а приказ pg_hba_file_rules помаже вам да пронађете грешке рашчлањивања. Тај приказ описује тренутни садржај датотека, а не то да ли их је покренути сервер успешно учитао, па чист списак није доказ да су нова правила активна.
Промене слушаоца траже сопствено поновно покретање, и две операције је лако заменити када изгледа да промена нема учинка.
Тестирајте са свежим сесијама: одобрени клијент са предвиђеним налогом се повезује, исти налог са неодобрене стазе не, а неовлашћени идентитет базе података и даље пада из унутрашњости VPN-а. Та три резултата раздвајају мрежну границу од ауторизације базе података, што је и цела поента држања одлука одвојено.