PostgreSQL przez VPN: jaki adres źródłowy zobaczy pg_hba

Listener, zapora i pierwsza pasująca reguła HBA to trzy decyzje. Sprawdź źródło, które PostgreSQL faktycznie otrzymuje, zanim wybierzesz prefiks.

PostgreSQL nigdy nie dowiaduje się, że klient jest w sieci VPN. Otrzymuje połączenie TCP z adresu i zestaw poświadczeń, a następnie decyduje, co z nimi zrobić. Uzależnienie dostępu od tunelu oznacza więc uporządkowanie trzech odrębnych decyzji tak, aby były zgodne, a potem sprawdzenie jedynego adresu, który serwer faktycznie widzi, a nie tego, który narysowano na diagramie.

Trzy decyzje, których nie wolno łączyć

Gdzie serwer nasłuchuje, to jedna decyzja. Który ruch może dotrzeć do tego adresu, to druga, podejmowana przez zaporę hosta i każdą granicę sieci przed nią. Która tożsamość bazy danych może się uwierzytelnić z którego źródła, to trzecia, podejmowana w pg_hba.conf.

Każdą egzekwuje inny komponent i każda kończy się innym komunikatem. Łączenie ich w dyskusji prowadzi do tego, że ludzie zaczynają edytować plik HBA, aby naprawić problem z zaporą. Trzymaj je w kolejności: nasłuchujący, który nie jest przypisany, jest nieosiągalny, do filtrowanego portu nie można się połączyć, a reguła HBA rozstrzyga tylko to, co dzieje się po powstaniu połączenia. Gdy zmiana nie ma efektu, ustal, którą z trzech warstw faktycznie zmieniono.

Gdzie serwer nasłuchuje

Przypisz do adresu faktycznie przypisanego maszynie, a nie do nazwy interfejsu:

listen_addresses = '10.20.0.30'

Baza danych może stać za bramą VPN bez własnego interfejsu tunelu, i właśnie dlatego adres jest właściwą rzeczą do nazwania. Zmiana tego ustawienia wymaga pełnego restartu; przeładowanie nie wystarcza.

Następnie filtruj port, zwykle 5432, na hoście i na każdej granicy przed nim. Przypisanie do prywatnego adresu nie jest dowodem publicznego odrzucenia, ponieważ przekierowanie portu lub mapowanie adresu w chmurze nadal może dostarczyć pakiety do tego prywatnego nasłuchującego.

Adres, który HBA faktycznie widzi

Przy dostępie routowanym serwer widzi wewnętrzny adres tunelu każdego klienta. Przy tłumaczeniu źródła widzi zamiast tego przetłumaczony adres bramy, a każdy klient zapada się w tę jedną wartość. Zbadaj źródło poprzez własne dowody połączeń serwera, zanim wybierzesz prefiks do dozwolenia.

Dla wdrożenia, które już używa TLS i SCRAM, celowo wąski przykład dostępu zdalnego wygląda tak:

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

To pozwala jednej roli i jednej bazie danych przez TLS z podanej puli, a następnie odrzuca inny zdalny dostęp TCP. Nie zastępuje pełnego pliku HBA: zachowaj lokalną administrację, replikację i każdą inną autoryzowaną usługę, a wąskie reguły umieść przed szerszymi zezwoleniami.

Gdy tłumaczenie jest w grze, HBA nie potrafi rozróżnić klientów po ich pierwotnych adresach. Utrzymuj ścisłe dopuszczanie sieci i wymagaj prawdziwych poświadczeń bazy danych, i nigdy nie zastępuj uwierzytelniania trust rzeczywistym kontem.

Wygrywa pierwsze dopasowanie, bez wariantu zapasowego

PostgreSQL czyta plik od góry do dołu i używa pierwszego rekordu pasującego do połączenia. Nie ma drugiej próby, jeśli uwierzytelnienie tego rekordu się nie powiedzie, więc wcześniejsze szerokie zezwolenie po cichu pokonuje późniejsze odrzucenie.

Ta zasada kolejności jest najczęstszą przyczyną, dla której starannie napisane odrzucenie nigdy nie zaczyna działać. Umieść reguły szczegółowe najpierw, a szerokie na końcu, a potem czytaj plik jako sekwencję, a nie jako zbiór. Reguła dodana na dole nie jest polityką, to komentarz. Przenieś ją wyżej i przeładuj, zanim uznasz, że plik jest ignorowany.

Dokumentacja HBA określa zarówno kolejność, jak i różnicę między rekordami host i hostssl, co ma znaczenie, gdy sensem reguły jest to, że połączenie musi być szyfrowane.

Przeładowanie, restart i przypadek odmowy

Zmiany HBA są stosowane przez przeładowanie, a widok pg_hba_file_rules pomaga znaleźć błędy analizy. Ten widok opisuje bieżącą zawartość pliku, a nie to, czy działający serwer załadował je pomyślnie, więc czysta lista nie jest dowodem, że nowe reguły działają.

Zmiany nasłuchującego wymagają własnego restartu, a obie operacje łatwo pomylić, gdy zmiana wydaje się nie mieć efektu.

Testuj na świeżych sesjach: zatwierdzony klient z zamierzonym kontem łączy się, to samo konto z niezatwierdzonej ścieżki nie, a nieautoryzowana tożsamość bazy danych nadal zawodzi od wewnątrz VPN. Te trzy wyniki oddzielają granicę sieci od autoryzacji bazy danych, co jest całym sensem utrzymywania decyzji osobno.

Powiązane artykuły