De ce o setare de proxy HTTP nu repară o conexiune PostgreSQL
Separați protocolul de bază de date al PostgreSQL de rutarea HTTP și verificați calea socketului necesară pentru SOCKS.
http.proxyHost poate direcționa un client HTTP participant, dar nu face nimic pentru PostgreSQL JDBC. PostgreSQL trimite protocolul său de bază de date, nu o cerere HTTP.
URL-ul de conexiune JDBC trebuie să numească în continuare serverul de bază de date și baza de date. Înlocuirea serverului cu o adresă de proxy HTTP nu poate învăța driverul comanda CONNECT.
Pentru un serviciu SOCKS, investigați implementarea socketului de sub JDBC. Java expune aceste proprietăți de pornire pentru socketurile participante:
-DsocksProxyHost=203.0.113.10 -DsocksProxyPort=1080Înlocuiți punctul final din documentație. Acestea sunt argumente JVM, nu parametri de URL JDBC. Verificați calea reală a socketului JDK/driverului și orice fabrică de socketuri personalizată înainte de a vă aștepta să le folosească.
Proprietățile se aplică întregului proces, așa că includeți alte conexiuni în evaluarea impactului. Un conector dedicat documentat sau un tunel aprobat poate oferi o limită mai clară atunci când doar traficul bazei de date trebuie să urmeze ruta.
Proxy-ul are în continuare nevoie de permisiune și de accesibilitate la portul bazei de date. Apoi baza de date aplică regulile de acces ale gazdei, TLS-ul destinației și propria autentificare. Păstrați numele de gazdă al certificatului și țineți contul bazei de date separat de contul proxy.
Înregistrați prima etapă eșuată: conexiunea la proxy, negocierea, TCP-ul bazei de date, TLS sau autentificarea la baza de date. Această dovadă identifică următoarea modificare; ajustarea repetată a proprietăților HTTP neutilizate nu poate face acest lucru.