Dlaczego ustawienie proxy HTTP nie naprawia połączenia PostgreSQL

Oddziel protokół bazy danych PostgreSQL od routingu HTTP i sprawdź ścieżkę gniazda wymaganą przez SOCKS.

http.proxyHost może kierować uczestniczącego klienta HTTP, ale nie robi nic dla PostgreSQL JDBC. PostgreSQL wysyła swój protokół bazy danych, a nie żądanie HTTP.

URL połączenia JDBC nadal musi wskazywać serwer bazy danych i bazę danych. Zastąpienie serwera adresem proxy HTTP nie może nauczyć sterownika polecenia CONNECT.

W przypadku usługi SOCKS zbadaj implementację gniazda poniżej JDBC. Java udostępnia te właściwości startowe dla uczestniczących gniazd:

-DsocksProxyHost=203.0.113.10 -DsocksProxyPort=1080

Zastąp punkt końcowy z dokumentacji. To argumenty JVM, a nie parametry URL JDBC. Zweryfikuj rzeczywistą ścieżkę gniazda JDK/sterownika i wszelką niestandardową fabrykę gniazd, zanim zaczniesz oczekiwać, że ich użyje.

Właściwości obowiązują dla całego procesu, więc uwzględnij inne połączenia w ocenie wpływu. Udokumentowany dedykowany łącznik lub zatwierdzony tunel mogą zapewnić wyraźniejszą granicę, gdy tą trasą ma przechodzić tylko ruch bazy danych.

Proxy nadal potrzebuje uprawnień i osiągalności portu bazy danych. Baza danych stosuje następnie reguły dostępu hosta, TLS miejsca docelowego i własne logowanie. Zachowaj nazwę hosta certyfikatu i trzymaj konto bazy danych osobno od konta proxy.

Zapisz pierwszy nieudany etap: połączenie z proxy, negocjację, TCP bazy danych, TLS lub logowanie do bazy danych. Te dowody wskazują następną zmianę; wielokrotne dostrajanie nieużywanych właściwości HTTP tego nie zrobi.

Powiązane artykuły