127.0.0.1 accediendo a internet [cerrado]

TL; DR: Parece que la aplicación está diseñada sin tener en cuenta que hay cosas como proxies explícitos donde la resolución de DNS se realiza en el proxy. La "solución" sugerida por el soporte de la aplicación no funcionará. En su lugar, necesitan repensar el diseño de su aplicación.

Dada la descripción, parece que la aplicación está usando un nombre de dominio público y que el DNS para este dominio devuelve una IP local al host, por ejemplo, una búsqueda en localhost.example.com devuelve 127.0.0.1 . Este tipo de configuraciones se usa normalmente para permitir un certificado SSL público para un servidor en la máquina local (mala idea ya que a menudo todos los clientes comparten la misma clave privada para el certificado de esta manera) o que alguna aplicación en Internet puede compartir cookies con el aplicación local (es decir, www.example.com en Internet y localhost.example.com comparten el mismo dominio de cookie example.com ).

El problema con este enfoque es que no funciona con configuraciones donde el nombre de host no se resuelve en el host local sino en algún proxy (típicamente proxy HTTP o proxy SOCKS5). En este caso, 127.0.0.1 no significa la máquina local donde se ejecuta el navegador y el servidor local y donde se origina la solicitud. En su lugar, 127.0.0.1 es la máquina proxy donde el nombre de host se resuelve en una dirección IP y luego el tráfico se reenvía a esta IP.

La "solución" sugerida por el soporte de la aplicación era permitir el acceso al dominio en el proxy. Esto no ayudará, ya que no resuelve el problema de que 127.0.0.1 desde la perspectiva del proxy no es el sistema de los clientes, sino el propio sistema proxy. Esto significa que normalmente no funcionará para acceder al servidor local esperado. Pero en el peor de los casos, también puede presentar un problema de seguridad, ya que a menudo se ejecuta una interfaz administrativa local en el proxy que podría permitir el acceso no autorizado desde el host local, ya que el sistema local se considera confiable.

Este tipo de configuración interrumpida, por ejemplo, la realiza Spotify para permitir el acceso a un servidor web local desde Internet, es decir, whatever.spotilocal.com devuelve 127.0.0.1 - vea también ¿Cuál es la ventaja de tener un nombre de dominio (spotilocal) que se resuelve? a 127.0.0.1? . Y por supuesto, están teniendo problemas con los proxies - spotify bloqueado por el calamar .

Simplemente configure su aplicación y el entorno de ejecución correctamente y asegúrese de que el tráfico para localhost, 127.0.0.1 y la URL que la aplicación utiliza para referirse a sí mismo no se envíe a su servidor proxy en primer lugar y todo su Los problemas se resolverán sin cambios en la lista blanca y el firewall ...

Dependiendo de su sistema operativo, busque una lista de exclusión de proxy, establezca una variable de entorno no_proxy o similar

Imagina que estás pasando notas en la escuela primaria. Envías el siguiente mensaje:

From: Me
To: Jeff
Message: I want to fight you by the flag pole after school

Pasas este mensaje a la persona que tienes a tu lado, y ellos lo transmiten ... y el mensaje finalmente llega a Jeff. Jeff ahora está muy confundido, porque está bastante seguro de que acaba de enviarse un mensaje sobre pelearse con el asta de la bandera después de la escuela ... pero no recuerda haberlo enviado ... y si intenta responder, recibirá aún más confundido y, finalmente, simplemente deje caer la nota en el suelo y olvídese de lo que sucede.

Para una computadora 127.0.0.1 es esencialmente Me específicamente usado para que la computadora hable a sí misma (por ejemplo, comunicación entre procesos). Si bien esto puede no parecer útil a la primera pasada ... en realidad se usa bastante para el reenvío de puertos en SSH, así como para probar las aplicaciones de servidor durante el desarrollo.

  

¿Cuáles son las implicaciones de seguridad de permitir el acceso 127.0.0.1 a Internet?

Ninguna. Durante décadas, 127.0.0.0/8 se ha definido como solo utilizable dentro del host. No es una dirección IP válida para ningún uso en ningún lugar de ninguna red.

RFC 5735 dice esto sobre el rango:

   127.0.0.0/8 - This block is assigned for use as the Internet host
   loopback address.  A datagram sent by a higher-level protocol to an
   address anywhere within this block loops back inside the host.  This
   is ordinarily implemented using only 127.0.0.1/32 for loopback.  As
   described in [RFC1122], Section 3.2.1.3, addresses within the entire
   127.0.0.0/8 block do not legitimately appear on any network anywhere.

La referencia de RFC 1122 es aún más explícita:

        (g)  { 127, <any> }

             Internal host loopback address.  Addresses of this form
             MUST NOT appear outside a host.

RFC 1122 tiene ahora más de 29 años. Toda implementación correcta de IP en cualquier enrutador o dispositivo con conexión a Internet seguirá este comportamiento.

La única forma en que los paquetes dirigidos a esta IP podrían moverse en una red es si la implementación del protocolo IP se rompió severamente en primer lugar.

  

¿Alguna idea de por qué una aplicación dependería de este tipo de configuración (no soy un desarrollador)?

No hay una consideración válida para esta configuración. Ninguna. Cero. Zilch. Tampoco debería considerar realizar cambios de configuración para permitir dicho tráfico.

Si el desarrollador de la aplicación le está diciendo que haga esto, entonces (a) no saben de qué están hablando o (b) están tratando de hacer algo tan severamente quebrantado que han demostrado (a).

El único uso para enviar tráfico a 127.0.0.1 es si el tráfico se envía a una aplicación o servicio que se ejecuta en el propio host (es decir, como un servidor proxy alojado localmente, túneles de cualquier tipo, etc.). Esa aplicación o servicio puede procesar el tráfico e intentar enviarlo a algún otro destino, pero si está intentando enviar tráfico para otro host a 127.0.0.1, se interrumpe. Periodo.