Esta es la situación, ejecutando Win 7 Pro SP1 (Versión 6.1.7601), el firewall de Windows está completamente deshabilitado (incluso se agregaron reglas para permitir el paso de cualquier cosa en caso de que de alguna manera aún continúe), no hay programas ejecutándose en segundo plano (eliminó todos los servicios innecesarios /exe), ipv6 está instalado y funciona bien, netsh isatap y 6to4 están habilitados. Teredo está configurado en el estado predeterminado.
Primero, puedo configurar un portproxy netsh v4tov4 para la interfaz 192/8 y en esta situación el portproxy funcionará bien. En dos shells de comando elevados ejecuto:
REM Admin Shell 1
ncat.exe -l 192.168.2.173 13337
REM Admin Shell 2
netsh interface portproxy add v4tov4 listenport=18080 connectport=13337 connectaddress=192.168.2.173
netsh interface portproxy show all
Listen on ipv4: Connect to ipv4:
Address Port Address Port
--------------- ---------- --------------- ----------
* 18080 192.168.2.173 13337
ncat 192.168.2.173 18080
[type a message and it will popup in shell 1]
C:\temp>netstat -a -b | grep -E -A1 13337
TCP 192.168.2.173:13337 Windows7_x64:0 LISTENING
[ncat.exe]
El proxy del puerto reenvía y netcat funciona como se esperaba.
A continuación, simplemente cambiar a localhost (que se resuelve en [::1]) o usar explícitamente 127.0.0.1 con una regla v4tov4 (también probé v6tov4) falla siempre.
Por ejemplo, comenzando con 127.0.0.1
REM Admin Shell 1
ncat.exe -l 127.0.0.1 13337
REM Admin Shell 2
netsh interface portproxy add v4tov4 listenport=18080 connectport=13337 connectaddress=127.0.0.1
netsh interface portproxy show all
Listen on ipv4: Connect to ipv4:
Address Port Address Port
--------------- ---------- --------------- ----------
* 18080 127.0.0.1 13337
ncat 127.0.0.1 18080
Ncat: No connection could be made because the target machine actively refused it. .
C:\temp>netstat -a -b | grep -E -A1 13337
TCP 127.0.0.1:13337 Windows7_x64:0 LISTENING
[ncat.exe]
Finalmente, eliminar todas las reglas antiguas de netsh y probarlo con v6tov6 también es una completa bomba:
REM Admin Shell 1
ncat.exe -6 -l [::1] 13337
REM Admin Shell 2
netsh interface portproxy add v6tov6 listenport=18080 connectport=13337 connectaddress=[::1]
netsh interface portproxy show all
Listen on ipv6: Connect to ipv6:
Address Port Address Port
--------------- ---------- --------------- ----------
* 18080 [::1] 13337
ncat -6 [::1] 18080
Ncat: No connection could be made because the target machine actively refused it.
C:\temp>netstat -a -b | grep -E -A1 13337
TCP [::1]:13337 Windows7_x64:0 LISTENING
[ncat.exe]
Tenga en cuenta que Windows7_x64 es localhost y la interfaz parece funcionar bien.
C:\>ping localhost
Pinging Windows7_x64 [::1] with 32 bytes of data:
Reply from ::1: time<1ms
También puedo conectarme directamente al punto final de escucha de netcat y enviar datos sin ningún problema:
ncat -6 [::1] 13337
El problema definitivamente está en las reglas de netsh portproxy.
Entonces, ¿qué pasa aquí? El firewall está completamente desactivado. Concha elevada. Nada más corriendo para interponerse en el camino (sin AV/IDS).
Intenté agregar varias combinaciones de reglas v6tov4 y v4tov6, pero tampoco funcionó. MS Message Analyzer no ayuda porque no detecta la interfaz del host local incluso cuando se establece la conexión.
¿Algunas ideas?
Editar 15/10/2016 23:58 EST: Detener los siguientes seis servicios deshabilita el proxy de puerto en todos los ámbitos. Eso sugeriría que uno de estos servicios está involucrado en lo que está sucediendo.
sc stop homegrouplistener
sc stop Browser
sc stop lanmanserver
sc stop smb
sc stop iphlpsvc
Respuesta1
Esto es por diseño. Los paquetes que llegan a la interfaz loopback (que realmente no existe en Windows) no pueden originarse desde ningún otro lugar que no sea 127.0.0.0/8. Del mismo modo, no puede enviar paquetes a nada más que 127.0.0.0/8porque no hay ruta a otras ubicaciones. Eso significa que incluso si llegara el tráfico, el programa de escucha no podría responder.
Si utiliza un programa proxy, toma tráfico de la red externa y producenuevotráfico en la interfaz loopback (y viceversa). Esto funcionará.
Considere el siguiente ejemplo de nmap (OS X):
sudo nmap -Pn -p 80 -S 192.168.2.1 -e lo0 127.0.0.1
Inyectará paquetes a la fuerza (a través de la raíz) en la interfaz loopback. Esto se puede verificar ejecutándolo tcpdump -i lo0en otro terminal. Sin embargo, incluso cuando ncestaba escuchando, no encontraba el puerto abierto. Sin embargo, lo siguiente encuentra al oyente como se esperaba:
nmap -p 80 -e lo0 127.0.0.1