Si has usado proxies antes, es probable que la lista blanca de IP te resulte familiar: registras la dirección de tu servidor con el proveedor, y cualquier conexión desde esa dirección se permite sin credenciales. Es un modelo habitual, y quienes llegan desde otros productos suelen buscar esa opción.
La respuesta directa para el gateway residencial es que no existe lista blanca de IP. La autenticación es usuario y contraseña en cada solicitud, y las credenciales son el único mecanismo de autenticación. Se trata de una decisión de diseño deliberada y no de una función ausente, y merece la pena entender por qué, porque cambia la forma de asegurar el acceso. La lista blanca sí existe en otras partes de la línea de productos, en los proxies ISP y en los planes heredados basados en puertos, y esto explica cómo configurarla ahí.
Por qué el gateway residencial usa credenciales en lugar de eso
El producto residencial es un único endpoint, p.shifter.io:443, donde toda la segmentación reside dentro del nombre de usuario. Una solicitud para una salida en EE. UU. con una sesión persistente usa el mismo host y puerto que una solicitud para una salida rotativa en Alemania; solo cambia la cadena del nombre de usuario. Ese diseño tiene una consecuencia para la autenticación: la credencial ya lleva información por solicitud, así que tiene que estar presente en cada solicitud de todos modos.
La autenticación por credenciales también es considerablemente más portable, algo que importa más de lo que parece a primera vista. La lista blanca vincula el acceso a una dirección de salida fija, y gran parte de la infraestructura moderna no tiene una. Los contenedores obtienen direcciones nuevas cuando se reprograman, los grupos de autoescalado añaden y quitan nodos, las funciones serverless salen a través de un espacio de direcciones compartido que cambia sin previo aviso, los ejecutores de CI son efímeros, y un desarrollador con un portátil o una conexión doméstica tiene una dirección dinámica que puede cambiar de un día para otro. Con la lista blanca, cada uno de estos casos se convierte en un ticket de soporte. Con credenciales en un almacén de secretos, la misma configuración funciona desde un portátil, un contenedor, un trabajo de CI y un clúster de producción sin que nadie tenga que registrar nada.
Así que si viniste buscando la opción de lista blanca en los proxies residenciales, lo que hay que configurar en su lugar es la gestión de credenciales, que se explica más abajo.
Dónde sí se aplica la lista blanca
Dos productos usan autenticación por IP de origen, y si la lista blanca es un requisito estricto para ti, estos son los que debes mirar.
Los proxies ISP admiten dos modos de autenticación, y eliges uno por plan en el panel. En el modo de IP de origen autorizada, registras la dirección de tu servidor y luego te conectas a tus IPs fijas por el puerto 1337 sin credenciales de ningún tipo. En el modo de usuario y contraseña, te conectas desde cualquier lugar con credenciales, una línea por IP. La disyuntiva es exactamente la descrita antes: la lista blanca mantiene las credenciales fuera de tu código por completo, a costa de solo funcionar desde direcciones registradas. Los proxies ISP son un producto distinto del residencial rotativo, con direcciones estáticas fijas en lugar de un pool rotativo, así que si estás eligiendo entre ambos, la comparación está en ISP frente a proxies residenciales y en qué son los proxies residenciales estáticos.
Los planes heredados de lista de puertos se autentican únicamente por IP de origen. Cada puerto de tu asignación tiene su propio subdominio, y añades a la lista blanca la dirección de tu servidor en el panel, o gestionas la lista mediante la API de gestión heredada, y luego te conectas a cualquier puerto de tu lista. Si estás en uno de estos planes, la lista blanca no es opcional, es el único mecanismo de autenticación. El contexto sobre por qué el sector se alejó de este modelo está en por qué la era del puerto individual ha terminado.
Configurar una lista blanca en proxies ISP
La mecánica es sencilla, pero dos detalles causan la mayoría de los fallos.
Primero, registra tu dirección de salida, no una local. La dirección que importa es la dirección pública desde la que llega tu tráfico, que no es tu dirección de LAN, ni la dirección interna de tu contenedor, ni lo que muestra ifconfig en la máquina. Determínala desde la máquina que realmente hará las solicitudes:
# ejecuta esto EN el servidor que se conectará a los proxies
curl -s https://ipinfo.io/ipSi tu infraestructura sale a través de una puerta de enlace NAT o un balanceador de carga, esa dirección compartida es la que debes registrar, y merece la pena confirmar que es estable y no asignada dinámicamente.
Segundo, elige el modo de autenticación de forma deliberada en el panel, dentro de ISP Proxies, porque los dos modos son alternativas y no un sistema en capas. Una vez estás en el modo de IP de origen autorizada, te conectas sin credenciales:
# modo de IP de origen autorizada: sin usuario ni contraseña
curl -x 185.199.108.153:1337 https://ipinfo.io/jsonSi esto devuelve un error y estás seguro de que la dirección está registrada, las causas habituales son que tu dirección de salida ha cambiado, que registraste una dirección IPv4 mientras tu tráfico sale por IPv6 o al revés, o que las solicitudes provienen de un nodo distinto al que usaste para probar.
La disyuntiva, dicha con claridad
La lista blanca elimina los secretos de tu código y de tu configuración, lo cual es genuinamente valioso: nada que se pueda filtrar en un repositorio, nada que rotar, nada que acabe en un registro. Su debilidad es que falla en el momento en que tu dirección de salida cambia, y no puede admitir el acceso desde cualquier sitio que no tenga una dirección estable.
La autenticación por credenciales es portable y funciona desde cualquier entorno, pero las credenciales son un secreto que ahora te pertenece, lo que significa que deben estar en un gestor de secretos y no en el código fuente, y necesitan un plan de rotación.
Ninguno de los dos es intrínsecamente más seguro. Fallan de forma distinta, y la elección correcta depende de si tu infraestructura tiene una salida estable.
Asegurar las credenciales residenciales, ya que no hay lista blanca
Si estás en el gateway residencial, esta es la sección que sustituye a la lista blanca para ti.
Mantén las credenciales fuera del control de versiones y fuera de las imágenes de contenedor, y cárgalas desde variables de entorno respaldadas por un gestor de secretos. Usa credenciales separadas por entorno cuando puedas, para que un valor de desarrollo filtrado no exponga producción. Trata la rotación como un despliegue y no como un clic en el panel: actualiza primero el almacén de secretos, despliega los clientes y luego rota el valor antiguo, porque cualquier cliente que aún tenga la contraseña anterior empezará a devolver 407 en el momento en que cambie, que es la versión más común y autoinfligida del problema tratado en cómo solucionar errores 407 y de credenciales.
Después, controla el otro lado. Incluso sin una lista blanca del lado del proveedor, puedes restringir qué sistemas propios llegan al gateway mediante reglas de salida ordinarias, políticas de red o un grupo de seguridad, de modo que una credencial filtrada sea menos útil desde fuera de tu infraestructura. Y supervisa el uso de ancho de banda, porque un consumo inexplicado es la señal de que una credencial se ha filtrado, algo más fácil de detectar cuando tienes una línea base a partir de tu propia supervisión del pipeline.
Errores habituales
Registrar una dirección privada como un valor 10.x o 192.168.x, que nunca puede coincidir, ya que solo la dirección de salida pública es visible para el proveedor. Añadir a la lista blanca un portátil o una conexión doméstica y sorprenderse cuando deja de funcionar tras reiniciar el router y reasignar la dirección. Olvidar que el autoescalado añade nodos con direcciones distintas. Registrar IPv4 mientras el tráfico realmente sale por IPv6. Y suponer que una entrada de lista blanca en un producto cubre otro: una lista blanca de proxy ISP no tiene ningún efecto en el gateway residencial, que seguirá exigiendo credenciales.
En resumen
No hay lista blanca de IP en el gateway residencial, y es así por diseño: la segmentación reside en el nombre de usuario, así que las credenciales están presentes en cada solicitud de todos modos, y la autenticación por credenciales sigue funcionando en contenedores, autoescalado, CI y conexiones dinámicas donde una lista blanca fallaría. Si necesitas específicamente autenticación por IP de origen, los proxies ISP la ofrecen como uno de dos modos seleccionables y los planes heredados de lista de puertos la usan de forma exclusiva, y en ambos casos lo que hay que registrar es tu dirección de salida pública y no nada local. En residencial, sustituye la lista blanca por una gestión disciplinada de credenciales: gestor de secretos, valores por entorno, un procedimiento de rotación que actualice los clientes antes de invalidar la contraseña antigua, además de controles de salida y supervisión del uso por tu parte.
La referencia completa de autenticación para cada producto está en la documentación de autenticación, y los detalles específicos del gateway están en gateway y autenticación. El producto en sí son los proxies residenciales, un único endpoint y un único par de credenciales en todos los países y modos de sesión, con precios por GB.