Un VPN comercial bloqueja el port 5432? Compareu les vostres opcions

L'aplicació parlava amb la seva base de dades des de l'oficina cada dia. Després algú va activar el client VPN comercial al mateix portàtil i la connexió va començar a reiniciar-se després de l'handshake. Res de l'aplicació no va canviar, el túnel informa que està sa, i el tallafoc que controles no té cap regla de bloqueig. El que va canviar és el camí de sortida: els servidors del proveïdor són punts finals compartits d'alt volum, i els proveïdors filtren ports de sortida per reduir els abusos. Els ports de base de dades i d'enviament de correu s'emporten la major part, perquè són els ports que atrauen escanejos i correu brossa des d'un conjunt d'adreces anònim.

La prova de cinc minuts que separa el filtratge de tota la resta

Des de la mateixa màquina, sondeja un port que ha d'estar obert i el port que falla, al mateix amfitrió, amb el túnel actiu i després aturat. Fes servir la mateixa ordre les dues vegades perquè l'única variable sigui el túnel:

Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432

Quatre resultats cobreixen gairebé tots els casos. Si el 443 funciona i el 5432 falla només amb el túnel actiu, estàs veient filtratge de ports al camí de sortida. Si tots dos fallen amb el túnel actiu i tots dos funcionen sense, el problema és d'encaminament o DNS, no de política de ports. Si tots dos ports connecten però l'aplicació encara falla, la culpa és de l'autenticació o del TLS, no de l'abast. I si només falla una ubicació de servidor del proveïdor, és política per servidor, així que prova una altra ubicació abans de tocar cap configuració.

Opció u: túnel dividit per a la subxarxa de la base de dades

Si el portàtil només necessita el VPN comercial per a altres finalitats, exclou el rang d'adreces de la base de dades del túnel perquè el trànsit no entri mai al punt de sortida compartit. Aquesta és l'opció més neta quan els dos camins realment no s'han de trobar, i no costa res més enllà d'una regla d'encaminament que puguis documentar. El compromís és que el túnel dividit introdueix una segona superfície de política: el que s'exclou del túnel ha de ser deliberat, no un efecte secundari d'una subxarxa que algú va afegir més tard.

Deixa de funcionar en el moment que la base de dades viu dins de la xarxa que es pretén que el VPN abasti, així que comprova-ho abans de comprometre-t'hi.

Opció dos: el teu propi punt final, la teva pròpia sortida

Executar un petit punt final de VPN en un VPS et posa al control de la política de sortida i no hi intervé cap conjunt compartit. Aquesta és l'opció que val la pena comparar honestament amb el client comercial: guanyes una adreça d'origen previsible i perds l'abast global i la comoditat del proveïdor. Per a un equip que necessita ports de base de dades i de correu tot el dia, el compromís sol afavorir la possessió del punt final, perquè el mode de fallada passa a ser la teva pròpia configuració errònia i no la política d'abusos d'algú altre.

Compara les dues opcions per l'estabilitat de l'adreça d'origen, per qui pot llegir el teu trànsit i pel que passa el dia que el proveïdor del punt final canvia el seu propi filtratge.

Opció tres: treu el portàtil del camí

Una tasca de CI, un contenidor programat o un amfitrió bastió dins de la xarxa permesa no depèn de l'estat del túnel d'una persona. Arriba a la base de dades per túnel SSH des d'un amfitrió que ja està permès, i el portàtil mai parla directament amb el port. Aquesta és l'opció que escala quan diverses persones topen amb la mateixa restricció, i també és la que elimina el problema en lloc d'envoltar-lo.

Requereix més feina prèvia que una regla de túnel dividit, i no ajuda la persona que ara mateix necessita una sessió interactiva.

Per què posar l'adreça del proveïdor a la llista permesa és la comparació equivocada

Afegir l'adreça de sortida del proveïdor a una llista permesa de base de dades funciona, i també dona accés a tots els altres subscriptors que comparteixen aquella adreça en aquell moment. Per a una rèplica només de lectura darrere d'un compte d'aplicació concedit estretament, l'exposició podria ser tolerable durant un dia. Per a qualsevol cosa escriptible no és un compromís que valgui la pena nomenar, i les adreces de sortida rotatives ho empitjoren: cada canvi de servidor trenca la regla, i el manteniment convida entrades CIDR àmplies que anul·len el propòsit d'una llista permesa.

Les adreces dedicades o estàtiques, allà on el proveïdor les ven, són l'única versió d'això que escala. Lliga la llista permesa a una adreça que sigui només teva, o no la lliguis gens.

Triïs el que triïs, escriu el camí i el motiu. La persona següent es trobarà la mateixa connexió que es reinicia i començarà culpant l'aplicació.