PostgreSQL преку VPN: која изворна адреса ќе ја види pg_hba

PostgreSQL никогаш не дознава дека клиентот е на VPN. Тој прима TCP врска од адреса и множество акредитиви и одлучува што да прави со нив. Затоа правењето на пристапот зависен од тунелот значи да се подредат три одделни одлуки за да се согласат, а потоа да се провери единствената адреса што серверот навистина ја гледа, наместо онаа што ја нацртавте на дијаграмот.

Три одлуки што не смеат да се спојат

Каде слуша серверот е една одлука. Кој сообраќај може да стигне до таа адреса е втора, донесена од firewall-от на домаќинот и секоја мрежна граница пред него. Кој идентитет на база на податоци може да се автентицира од кој извор е трета, донесена во pg_hba.conf.

Секоја се спроведува од различен компонент, и секоја пропаѓа со различна порака. Нивното спојување во дискусија е начинот на кој луѓето завршуваат со уредување на HBA-датотеката за да поправат проблем со firewall. Држете ги по ред: слушач што не е врзан не може да се достигне, на филтриран порт не може да се поврзе, а 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. Тие три резултати ја одвојуваат мрежната граница од авторизацијата на базата на податоци, што е целата поента на држењето на одлуките одделно.