Base de conocimientos de ProxyCompass
Autenticación del proxy: ¿IP permitidas o usuario y contraseña?
La autenticación del proxy comprueba si tu aplicación puede utilizar un servicio de proxies. Conocer la dirección y el puerto del proxy no suele ser suficiente: el servicio también necesita distinguir a los clientes permitidos de otros sistemas que pueden llegar a él. Esto restringe el uso de los proxies comprados a los clientes que autorizas.
Los dos métodos habituales utilizan pruebas distintas. Con la autenticación por IP, el proxy comprueba de dónde procede la conexión. Con la autenticación mediante usuario y contraseña, la aplicación proporciona credenciales. El primer método vincula el acceso a una dirección de red; el segundo puede permitir que la aplicación mantenga su acceso al pasar a otra red. Un servicio también puede exigir ambas condiciones a la vez.
Esta elección afecta a cómo te conectas, qué aplicaciones puedes utilizar y qué sucede cuando cambia tu entorno de trabajo. Es una parte separada de la elección de una configuración de proxy: la autenticación no determina si la IP de salida es de centro de datos o residencial, estática o rotativa. Determina quién puede utilizar el servicio que proporciona esa IP.
Cómo funcionan los dos métodos de autenticación
Autenticación por IP: permiso para un origen de conexión
Con la autenticación por IP, añades una dirección de cliente a la lista de permitidas del proveedor, a menudo llamada whitelist o allowlist. Cuando llega una conexión, el proxy compara su IP de origen con esa lista. Si coincide y se cumplen las demás condiciones de acceso del servicio, la aplicación puede utilizar el proxy sin enviar un nombre de usuario y una contraseña de proxy separados.
Para un proxy de Internet, la dirección relevante suele ser la IP pública de salida de tu red. Es la dirección desde la que tu aplicación llega al proxy, no la IP de salida que el proxy presenta después a los sitios web. Comprar un proxy estático no convierte en estática tu conexión doméstica: estas direcciones pertenecen a partes distintas de la ruta.
Por tanto, el acceso sigue siendo cómodo mientras el origen permitido no cambie. Un programa puede reiniciarse u otro dispositivo permitido puede conectarse mediante esa red sin necesitar su propia contraseña de proxy. Si cambia la IP de salida, el permiso anterior no cubre automáticamente la nueva dirección. La guía de autenticación por IP explica cómo identificar la dirección de origen correcta y gestionar su lista de permitidas.
Usuario y contraseña: permiso proporcionado por la aplicación
Con la autenticación mediante usuario y contraseña, el proveedor emite credenciales para utilizar el proxy. La aplicación las envía como parte del protocolo de proxy compatible. Un navegador puede pedir al usuario que las introduzca; un script puede proporcionarlas desde su configuración sin mostrar una ventana de inicio de sesión.
Cuando las credenciales son el único requisito de autenticación, el acceso puede acompañar a la aplicación entre redes. La misma configuración operativa puede seguir conectándose desde una nueva IP de origen. Esto resulta útil cuando el lugar donde se ejecuta una tarea cambia con más frecuencia que sus ajustes de proxy.
Las credenciales pertenecen a la conexión con el proxy. No son automáticamente la contraseña del panel del proveedor ni inician sesión en el sitio web de destino. Ese sitio sigue aplicando sus propias reglas de inicio de sesión y acceso. La guía de autenticación con usuario y contraseña trata los campos de conexión, los clientes compatibles y los formatos de credenciales.
Autenticación por IP frente a usuario y contraseña
La comparación siguiente describe los dos métodos por separado. Aquí, el acceso por contraseña significa acceso sin una restricción IP adicional; el acceso combinado se explica más adelante.
| Qué cambia en la práctica | Autenticación por IP | Usuario y contraseña |
|---|---|---|
| Base del acceso | Una conexión debe llegar desde una IP de origen permitida. | La aplicación debe proporcionar credenciales de proxy válidas. |
| Configuración de la aplicación | No se necesitan credenciales de proxy, pero siguen siendo necesarios el protocolo, la dirección y el puerto correctos. | La aplicación debe admitir el intercambio de credenciales del proxy. |
| Cambio a otra red | El nuevo origen debe estar ya permitido o añadirse a la lista. | Las mismas credenciales pueden funcionar desde la nueva red. |
| Varias aplicaciones | Las aplicaciones que utilizan la misma salida de red permitida comparten su permiso por IP. | Cada aplicación debe enviar credenciales aceptadas por el servicio; varias aplicaciones pueden utilizar el mismo par si se permite. |
| Qué revela la filtración de una dirección de proxy | La dirección y el puerto por sí solos no superan la comprobación de IP de origen desde una red no aprobada. | Una configuración completa que contenga credenciales válidas puede dar acceso desde otra red. |
| Qué debes mantener | Las direcciones de origen permitidas y las rutas de red que las utilizan. | Las credenciales y las aplicaciones configuradas para enviarlas. |
Ninguno de los métodos determina el número de IP de salida del servicio. Una IP de cliente permitida o un conjunto de credenciales pueden dar acceso a muchos proxies. Ninguno les proporciona conexiones ilimitadas ni convierte sus direcciones de salida en exclusivas de un cliente.
Cómo elegir para tu aplicación y tu red
Primero comprueba si la aplicación puede utilizar el método ofrecido
Un programa puede admitir un protocolo de proxy sin admitir todas sus opciones de autenticación. Los campos de dirección y puerto por sí solos no demuestran que pueda enviar un usuario y una contraseña. Por ejemplo, la compatibilidad SOCKS5 incorporada en Chrome no incluye autenticación SOCKS5 mediante usuario y contraseña. Unas credenciales correctas no compensan esa función ausente del cliente.
Si la aplicación necesaria admite el protocolo ofrecido, pero no puede enviar sus credenciales, la autenticación por IP puede proporcionar una ruta utilizable. Esto sigue requiriendo una dirección de origen permitida. Cuando esa dirección cambia con frecuencia, pasar al acceso por IP resuelve el problema de las credenciales, pero deja pendiente gestionar el origen. En su lugar, quizá necesites un cliente con la compatibilidad de autenticación requerida o una salida de red estable.
Por tanto, la comprobación útil antes de comprar es concreta: ¿puede esta aplicación utilizar este protocolo de proxy con este método de autenticación? Que funcione en otro navegador o herramienta de línea de órdenes no resuelve esa cuestión.
Después considera qué suele cambiar en tu configuración
La autenticación por IP encaja con un trabajo cuya salida de red es estable y está controlada. Una vez permitida esa salida, cambiar el programa que está detrás no exige distribuir credenciales de proxy a cada proceso nuevo. Los ajustes de acceso del servicio siguen vinculados a la red que utiliza el trabajo.
Las credenciales encajan con un trabajo cuyo lugar de ejecución cambia. Si una tarea se traslada a otro servidor o se inician nuevos procesos de trabajo desde redes distintas, el acceso no necesita un cambio separado de la lista de permitidas para cada origen, siempre que el servicio acepte credenciales sin vinculación a IP. La configuración del proxy puede acompañar a la aplicación.
La distinción importante es con qué frecuencia cambia el origen de salida, no si llamas al equipo portátil, VPS o servidor en la nube. Un portátil puede permanecer detrás de una salida fija de oficina; un despliegue de servidores puede alternar entre direcciones públicas. Elige según la ruta de conexión real y los cambios que esperas durante el trabajo normal.
Si ambos métodos funcionan, elige el más sencillo de mantener
Considera quién mantendrá la configuración. Un administrador de red que controla una salida fija compartida por varias aplicaciones puede gestionar el acceso mediante un único permiso de origen. A un desarrollador que traslada trabajos entre entornos, pero no controla sus IP públicas, pueden resultarle más fáciles de mantener las credenciales sin vinculación a IP.
Incluye los recursos adicionales que exija la elección. Una IP pública fija, más entradas en la lista de permitidas o una puerta de enlace gestionada pueden tener un coste. El acceso por contraseña puede evitar esos costes, pero solo si funciona desde las redes necesarias. Compara las opciones reales del servicio; la presencia de una contraseña no hace por sí sola más barato un proxy.
Autenticación combinada: IP y contraseña
Un proveedor puede ofrecer acceso por IP y por contraseña como alternativas, o exigirlos juntos. Son modalidades distintas. En el modo combinado, las credenciales válidas solo se aceptan cuando la conexión también procede de una dirección o red permitida. Una contraseña correcta por sí sola no basta, y un origen permitido por sí solo tampoco.
Esto puede encajar con aplicaciones que exigen campos de usuario y contraseña, manteniendo una restricción sobre el origen del acceso. También puede limitar el uso de credenciales copiadas fuera de la red permitida. No proporciona la misma libertad para moverse entre redes arbitrarias que el acceso por contraseña sin vinculación a IP.
En los paquetes estáticos de ProxyCompass, el modo combinado acepta credenciales válidas desde direcciones IPv4 públicas de clientes de la misma subred /24 que una IP añadida a la lista de permitidas. Esas direcciones tienen los mismos tres primeros números. Por tanto, varias direcciones de cliente de esa subred pueden utilizar las credenciales mediante una sola entrada en la lista. Esta regla afecta a los clientes que se conectan al servicio, no a las IP de salida compradas. La guía de usuario y contraseña enlazada arriba muestra los ejemplos de conexión.
¿Qué método proporciona mejor control del acceso?
La autenticación por IP sitúa la decisión de acceso en la salida de red. Quien obtiene solo la dirección del proxy no puede utilizarlo desde otro origen no aprobado. Pero el proxy no puede identificar personas individuales simplemente porque compartan una IP permitida. Si varios usuarios llegan a él por la misma dirección pública, esa comprobación ve el mismo origen para todos. Esto importa en salidas de oficina compartidas y direcciones públicas compartidas entre abonados de Internet.
La autenticación con usuario y contraseña sitúa el permiso en credenciales que las aplicaciones pueden presentar independientemente de su ubicación. Esto funciona bien entre redes distintas. También significa que una configuración copiada con credenciales válidas puede seguir siendo utilizable en otro lugar. Cuando un proveedor ofrece credenciales separadas para distintos usuarios o trabajos, estas pueden permitir una gestión del acceso más detallada; una contraseña compartida por todos no crea esa separación.
Por tanto, la elección depende de qué controlas de forma más fiable: el grupo de sistemas detrás de una salida de red permitida o las credenciales proporcionadas a las aplicaciones. El acceso combinado requiere ambas condiciones, por lo que restringe los lugares desde los que pueden utilizarse incluso credenciales válidas.
El control de acceso y el cifrado son cuestiones separadas. La autenticación por IP no cifra el tráfico, y una contraseña no crea automáticamente una conexión cifrada. Proteger las credenciales durante el transporte exige protección en la propia conexión entre cliente y proxy. Abrir un sitio HTTPS a través de un proxy no protege por sí solo un intercambio anterior de inicio de sesión sin cifrar con ese proxy.
¿Hace la autenticación por IP más rápido un proxy?
El acceso por IP puede evitar un intercambio de credenciales, pero el establecimiento de conexión es distinto entre HTTP y SOCKS. En SOCKS5, la autenticación con usuario y contraseña añade una solicitud y una respuesta durante el establecimiento. Con HTTP, un cliente puede esperar un desafío de autenticación y repetir su solicitud, o enviar las credenciales adecuadas desde el principio. Por tanto, el acceso por contraseña no siempre añade un viaje de ida y vuelta de red.
Esa diferencia importa más cuando un trabajo crea repetidamente conexiones nuevas para pequeñas cantidades de trabajo. Importa menos cuando se reutilizan conexiones establecidas. Por ejemplo, solicitar más páginas del mismo sitio mediante un túnel HTTPS existente no repite el inicio de sesión del proxy utilizado para establecer ese túnel. Es un coste de establecimiento de conexión, no una reducción fija de la velocidad de transferencia de datos del proxy.
Si ambos métodos encajan con tu configuración, compáralos con el mismo protocolo, recursos de proxy similares y tu patrón real de conexiones. Una prueba que abre una conexión nueva en cada solicitud responde a una cuestión distinta de otra que reutiliza conexiones. Sin esa comparación, afirmar que un método de autenticación es siempre más rápido ayuda poco a elegir un servicio.
¿Puede la autenticación revelar que una dirección ejecuta un proxy?
Sí. Una contraseña puede impedir el uso no autorizado y aun así permitir que un sistema externo reconozca el servicio. Por ejemplo, un comprobador puede contactar con la dirección y el puerto de un proxy HTTP sin credenciales válidas. Una respuesta 407 Proxy Authentication Required, con la cabecera Proxy-Authenticate, identifica expresamente un requisito de autenticación de proxy. El comprobador no necesita conocer la contraseña para recibir esa prueba.
Un servicio restringido por IP puede revelar menos si bloquea un origen no aprobado antes de devolver una respuesta de proxy reconocible. Pero una lista de permitidas por sí sola no garantiza ese comportamiento: el servidor podría devolver un rechazo distintivo. Un punto protegido por contraseña también puede tener filtrado de red. La diferencia relevante es a qué puede llegar una conexión externa y qué respuesta recibe.
También importa la dirección comprobada. Cuando la dirección de entrada y la IP de salida del proxy son la misma, una respuesta reconocible puede identificar la dirección que ven los sitios web. Con una puerta de enlace que utiliza IP de salida distintas, identificar la puerta de enlace no identifica por sí solo todas las salidas de su grupo.
El sitio web de destino no recibe automáticamente el desafío de inicio de sesión del proxy durante la navegación ordinaria: ese intercambio se produce entre cliente y proxy. Un sitio o su servicio de detección necesitarían otras pruebas, que podrían incluir una comprobación separada de la dirección. Por tanto, cambiar únicamente la autenticación no promete hacer irreconocible una IP como proxy ni eliminar la información ya conocida sobre ella.