Puertos bloqueados
Un proveedor de proxies puede prohibir las conexiones con determinados puertos de red. Puede permitir navegar por la web y rechazar las conexiones con los puertos utilizados para enviar correo. El proxy sigue aceptando la conexión del cliente, pero no establece la conexión solicitada con el servidor de correo.
Las restricciones de puertos son uno de los límites de uso de los proxies que determinan qué tareas puede realizar un servicio. Para entender sus efectos, debes distinguir la conexión con el proxy de la conexión que el proxy establece en tu nombre.
¿Qué puerto se está bloqueando?
Un puerto de red es un número que permite distinguir servicios en una dirección de red. El mismo servidor puede aceptar conexiones web en un puerto y conexiones de otra aplicación en otro. Una aplicación necesita la dirección del servidor, el puerto adecuado y el transporte que utiliza: TCP o UDP.
Una conexión proxy tiene dos destinos separados. Primero, tu aplicación se conecta al proxy en la dirección y el puerto que proporciona el proveedor. Después pide al proxy que contacte con el servidor de destino en la dirección y el puerto de ese servidor. El puerto de tu configuración proxy pertenece al primer paso; una restricción del puerto de destino se aplica al segundo.
Por ejemplo, un programa puede conectarse a proxy.example:1080 y solicitar portal.example:443. Ese mismo punto de entrada del proxy también puede recibir una solicitud para mail.example:587. Si el proveedor permite el primer puerto de destino y bloquea el segundo, la conexión web puede funcionar mientras se rechaza la de correo.
Estas restricciones se refieren a conexiones salientes del proxy con servicios externos. Permitir una conexión de este tipo no proporciona a una aplicación de tu ordenador un puerto de entrada accesible para otros usuarios de Internet. El reenvío de puertos de entrada es una capacidad independiente.
Por qué los proveedores restringen puertos
El motivo más claro es evitar el abuso de un servicio concreto. El acceso directo a servidores de correo puede utilizarse para campañas de spam. Las denuncias y las listas de bloqueo de remitentes afectan a las direcciones IP que transportan el tráfico, por lo que las consecuencias pueden ir más allá del cliente que envió los mensajes. Un proveedor puede reducir ese riesgo rechazando las conexiones con los puertos de envío de correo antes de que se transmita ningún mensaje.
Pueden aplicarse consideraciones parecidas a la administración remota, el intercambio de archivos o los servicios de bases de datos. Un proveedor puede restringir los puertos asociados a esos servicios para reducir los intentos de acceso no autorizado y otros ataques. La restricción se aplica a la propia conexión: un administrador legítimo también puede verse impedido de acceder a su servidor mediante ese producto.
La regla no siempre procede del vendedor de proxies. Una empresa de alojamiento o un operador de red pueden filtrar las conexiones salientes de la infraestructura que utiliza el proxy. Un permiso en el software del proxy no puede anular una restricción impuesta en otro punto de la ruta.
Un filtro de puertos es una medida amplia. Puede detener tráfico no deseado sin examinar cada mensaje ni decidir si cada operación es legítima, pero también limita aplicaciones útiles que necesitan el mismo puerto. Este equilibrio explica por qué un proveedor puede mantener un puerto cerrado incluso para un cliente de pago con una tarea razonable.
Cómo funcionan las reglas de acceso a puertos
Hay dos enfoques básicos. Una lista de bloqueo enumera los puertos que no pueden utilizar los clientes; las demás conexiones se evalúan según el resto de reglas del servicio. Una lista de permitidos funciona al revés: el proveedor permite un conjunto concreto de puertos y rechaza los demás. En este segundo modelo, una aplicación web normal que utiliza un puerto no estándar puede ser inaccesible simplemente porque su puerto queda fuera del conjunto permitido.
Una regla puede cubrir un puerto en todas las direcciones externas o combinar el puerto con un destino concreto. Los proveedores también pueden aplicar reglas distintas a diferentes productos o usos aprobados. Por eso, el acceso mediante una red no determina los permisos de otro producto que venda la misma empresa.
El proxy no necesita descifrar el tráfico de la aplicación para aplicar una regla de puerto de destino. En una solicitud HTTP CONNECT, el cliente proporciona el host y el puerto de destino. SOCKS5 también incluye el destino solicitado en su petición de conexión. El proxy puede rechazarla antes de que empiece una sesión protegida con el servidor de destino.
El tráfico TCP y UDP que utiliza el mismo número de puerto puede permitirse o bloquearse por separado. Una conexión satisfactoria con el puerto TCP 443 no demuestra que el puerto UDP 443 esté disponible. También hay otra posibilidad: que el producto proxy seleccionado no transporte UDP en absoluto. En ese caso, la limitación afecta al transporte, en lugar de a un puerto UDP concreto.
Un número de puerto tampoco demuestra por sí solo qué está haciendo una aplicación. Los servicios pueden ejecutarse en puertos no estándar, y un número permitido no hace aceptable cualquier uso que se haga de él. Los proveedores pueden combinar filtros de puertos con restricciones de destino y reglas sobre la propia actividad.
Qué cambia esto para las aplicaciones
Las aplicaciones utilizan conexiones para funciones concretas. Una prueba en el navegador comprueba la conexión web que establece; no prueba todas las conexiones que podría necesitar otro programa. Los ejemplos siguientes muestran cómo una restricción de puertos puede afectar a un servicio que, por lo demás, funciona.
| Conexión | Puertos utilizados en este ejemplo | Efecto de una restricción |
|---|---|---|
| Acceso web mediante TCP | 443 | No puede obtenerse la página mediante esta conexión. |
| Envío de correo | TCP 25 para la entrega entre servidores; TCP 465 o 587 para el envío desde una aplicación de correo | El envío directo de correo mediante la conexión afectada no está disponible. |
| FTP pasivo | TCP 21 para los comandos y un puerto independiente anunciado por el servidor para los datos | El inicio de sesión puede funcionar mientras falla el listado del directorio o la transferencia de archivos. |
| Una aplicación web en un puerto personalizado | Por ejemplo, TCP 8443 | La aplicación puede ser inaccesible aunque funcionen los sitios web en TCP 443. |
El correo ilustra especialmente bien esta diferencia. Una aplicación de correo entrega los mensajes salientes a un servidor de correo, normalmente por el puerto 587 o el 465. El puerto 465 inicia la conexión con cifrado TLS; el 587 suele utilizar STARTTLS para establecerlo. Una restricción de puertos puede impedir cualquiera de las dos conexiones antes de enviar el mensaje. El cifrado protege el intercambio, pero no elimina la regla de acceso del proveedor.
En una interfaz de correo web, el navegador se comunica con un sitio web mediante HTTPS y el servicio de correo gestiona la entrega. El navegador no pide al proxy que establezca esa misma conexión SMTP. Por eso, un buzón web puede seguir siendo utilizable mientras el acceso SMTP está bloqueado. Recibir correo en una aplicación independiente implica otra conexión distinta: el acceso IMAP o POP debe evaluarse por separado del envío.
FTP muestra por qué probar solo el inicio de sesión puede pasar por alto un problema. En modo pasivo, el cliente primero envía comandos por una conexión y después se conecta a un puerto especificado por el servidor para transferir datos. Si la segunda conexión está restringida, la autenticación puede funcionar mientras fallan la lista de archivos o la descarga. Las aplicaciones con conexiones independientes para iniciar sesión, transmitir voz o intercambiar archivos pueden mostrar fallos parciales similares.
Por qué cambiar la configuración del proxy puede no ayudar
Cambiar el puerto de entrada en tu configuración proxy cambia dónde contacta tu aplicación con el proxy. No cambia el puerto de destino solicitado para el servicio externo. Si el proveedor ofrece un punto de entrada en el puerto 443, conectarte a él sigue dejando la solicitud del puerto 587 del servidor de correo sujeta a la restricción de puertos de correo.
Cambiar de un proxy HTTP a SOCKS5 puede resolver un problema de compatibilidad cuando la aplicación necesita una capacidad admitida por el nuevo método de conexión. Por sí solo, no anula las reglas del proveedor. SOCKS5 define cómo solicitar conexiones TCP y reenvío UDP; el servicio decide cuáles de esas solicitudes aceptará.
Sustituir una IP de salida tampoco elimina una restricción que se aplica a todo el producto. Una ruta distinta puede comportarse de otro modo si el fallo lo provoca una red externa concreta, pero la rotación no permite quitar una regla aplicable a todo el producto. Más IP o una cuota de tráfico mayor tampoco cambian ese permiso.
Cómo identificar una restricción de puertos
La prueba más útil es una respuesta explícita del proveedor que indique que el puerto de destino solicitado no está permitido. Un mensaje genérico de acceso denegado es menos preciso. Por ejemplo, la respuesta SOCKS5 para una solicitud rechazada por las reglas identifica una denegación por política, pero no indica qué regla la causó. Un tiempo de espera agotado o un reinicio de conexión, por sí solos, son indicios aún más débiles.
Puede que en ese puerto del servidor de destino no escuche ningún servicio, que solo se acepten ciertas direcciones de origen o que esté temporalmente inaccesible. La aplicación también puede estar utilizando el protocolo equivocado o enviando parte del tráfico fuera del proxy configurado. Comprobar una solicitud web satisfactoria no permite distinguir estas causas de una restricción que afecte a otra conexión.
Para una solicitud útil a soporte, proporciona el producto proxy, el nombre de host o la IP de destino, su puerto, TCP o UDP, la aplicación y el error exacto con la hora del intento. Estos detalles permiten a soporte comprobar la conexión correspondiente en lugar de limitarse a confirmar que el proxy está conectado. Antes de una compra, la misma información ayuda a establecer si el producto permite realizar la tarea.
Cuando el proveedor permite excepciones, la aprobación debe identificar el destino y el uso necesarios. Algunas restricciones son permanentes o proceden de una infraestructura que el proveedor no controla. La pregunta útil es si puede admitirse esa conexión concreta conforme a las reglas del servicio; pedir que se «abran todos los puertos» deja poco claros tanto el requisito como los límites.