La aplicación hablaba con su base de datos desde la oficina todos los días. Luego alguien activó el cliente VPN comercial en el mismo portátil y la conexión empezó a reiniciarse después del handshake. Nada en la aplicación cambió, el túnel informa que está sano y el cortafuegos que usted controla no tiene ninguna regla de bloqueo. Lo que cambió es la ruta de salida: los servidores del proveedor son puntos finales compartidos de alto volumen, y los proveedores filtran los puertos de salida para reducir los abusos. Los puertos de base de datos y de envío de correo se llevan la mayor parte, porque son los puertos que atraen escaneos y correo no deseado desde un conjunto de direcciones anónimo.

La prueba de cinco minutos que separa el filtrado de todo lo demás

Desde la misma máquina, sondee un puerto que debe estar abierto y el puerto que falla, en el mismo host, con el túnel activo y luego desactivado. Use el mismo comando las dos veces para que la única variable sea el túnel:

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

Cuatro resultados cubren casi todos los casos. Si el 443 funciona y el 5432 falla solo con el túnel activo, está viendo filtrado de puertos en la ruta de salida. Si ambos fallan con el túnel activo y ambos funcionan sin él, el problema es de enrutamiento o de DNS, no de política de puertos. Si ambos puertos conectan pero la aplicación sigue fallando, la culpa es de la autenticación o de TLS, no de la accesibilidad. Y si solo falla una ubicación de servidor del proveedor, es política por servidor, así que pruebe otra ubicación antes de tocar cualquier configuración.

Opción uno: túnel dividido para la subred de la base de datos

Si el portátil solo necesita el VPN comercial para otros fines, excluya el rango de direcciones de la base de datos del túnel para que el tráfico nunca entre en la salida compartida. Esta es la opción más limpia cuando los dos caminos realmente no necesitan encontrarse, y no cuesta nada más allá de una regla de enrutamiento que pueda documentar. El compromiso es que el túnel dividido introduce una segunda superficie de política: lo que se excluye del túnel tiene que ser deliberado, no un efecto secundario de una subred que alguien añadió después.

Deja de funcionar en el momento en que la base de datos vive dentro de la red que se supone que el VPN debe alcanzar, así que compruébelo antes de comprometerse con ello.

Opción dos: su propio punto final, su propia salida

Ejecutar un pequeño punto final de VPN en un VPS le pone al control de la política de salida y no interviene ningún conjunto compartido. Esta es la opción que merece una comparación honesta con el cliente comercial: gana una dirección de origen predecible y pierde la huella global y la comodidad del proveedor. Para un equipo que necesita puertos de base de datos y de correo todo el día, el compromiso suele favorecer la posesión del punto final, porque el modo de fallo pasa a ser su propia configuración errónea y no la política de abusos de otra persona.

Compare las dos por la estabilidad de la dirección de origen, por quién puede leer su tráfico y por lo que ocurre el día en que el proveedor del punto final cambia su propio filtrado.

Opción tres: saque el portátil de la ruta

Una tarea de CI, un contenedor programado o un host bastión dentro de la red permitida no dependen del estado del túnel de una persona. Llegue a la base de datos por un túnel SSH desde un host que ya está permitido, y el portátil nunca habla directamente con el puerto. Esta es la opción que escala cuando varias personas se topan con la misma restricción, y también es la que elimina el problema en lugar de sortearlo.

Requiere más trabajo por adelantado que una regla de túnel dividido, y no ayuda a la única persona que necesita una sesión interactiva ahora mismo.

Por qué poner la dirección del proveedor en una lista de permitidos es la comparación equivocada

Añadir la dirección de salida del proveedor a una lista de permitidos de base de datos funciona, y también concede acceso a todos los demás suscriptores que comparten esa dirección en ese momento. Para una réplica de solo lectura detrás de una cuenta de aplicación concedida de forma estrecha, la exposición podría ser tolerable durante un día. Para cualquier cosa que se pueda escribir no es un compromiso que merezca ese nombre, y las direcciones de salida rotativas lo empeoran: cada cambio de servidor rompe la regla, y el mantenimiento invita a entradas CIDR amplias que anulan el propósito de una lista de permitidos.

Las direcciones dedicadas o estáticas, donde el proveedor las vende, son la única versión de esto que escala. Ate la lista de permitidos a una dirección que sea solo suya, o no la ate en absoluto.

Elija lo que elija, escriba la ruta y el motivo. La siguiente persona se encontrará con la misma conexión reiniciándose y empezará culpando a la aplicación.

Artículos relacionados