☰

Windows netsh TCP portproxy falha ao encaminhar pacotes através de loopback, soluções?

tag-icon • tag-icon windows-7 networking proxy firewall ipv6
Windows netsh TCP portproxy falha ao encaminhar pacotes através de loopback, soluções?

Aqui está a situação, executando o Win 7 Pro SP1 (versão 6.1.7601), o firewall do Windows está completamente desabilitado (até mesmo regras adicionadas para permitir a passagem de qualquer coisa, caso de alguma forma ainda esteja funcionando), nenhum programa em execução em segundo plano (eliminou todos os serviços desnecessários /exe), o ipv6 está instalado e funcionando bem, netsh isatap e 6to4 estão habilitados. Teredo está definido para o estado padrão.

Primeiro, posso configurar um portproxy netsh v4tov4 para a interface 192/8 e nesta situação o portproxy funcionará bem. Em dois shells de comando elevados eu executo:

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]

O proxy da porta encaminha e o netcat funciona conforme o esperado.

Em seguida, simplesmente mudar para localhost (que resolve para [::1]) ou usar explicitamente 127.0.0.1 com uma regra v4tov4 (também tentei v6tov4) falha sempre.

Por exemplo, começando com 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, excluir todas as regras antigas do netsh e testá-las com v6tov6 também é uma bomba completa:

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]

Nota Windows7_x64 é localhost e a interface parece estar funcionando bem.

C:\>ping localhost
Pinging Windows7_x64 [::1] with 32 bytes of data:
Reply from ::1: time<1ms

Também posso conectar-me diretamente ao endpoint netcat de escuta e enviar dados sem problemas:

ncat -6 [::1] 13337

O problema está definitivamente nas regras do netsh portproxy.

Então, o que acontece aqui? O Firewall está completamente desativado. Concha elevada. Nada mais pode atrapalhar (sem AV/IDS).

Tentei adicionar várias combinações de regras v6tov4 e v4tov6, mas também não funcionou. O MS Message Analyzer não está ajudando porque não está captando a interface localhost mesmo quando a conexão é estabelecida.

Alguma ideia?

Editar 15/10/2016 23:58 EST: A interrupção dos seis serviços a seguir desativa o proxy de porta em todos os aspectos. Isso sugeriria que um desses serviços está envolvido no que está acontecendo.

sc stop homegrouplistener
sc stop Browser
sc stop lanmanserver
sc stop smb
sc stop iphlpsvc

Responder1

Isso ocorre intencionalmente. Os pacotes que chegam na interface de loopback (que realmente não existe no Windows) não podem ser originados de nada além de 127.0.0.0/8. Da mesma forma, você não pode enviar pacotes para nada, a não ser 127.0.0.0/8porque não há rota para outros locais. Isso significa que mesmo que o tráfego chegasse, o programa de escuta não poderia responder.

Se você usar um programa proxy, ele pegará o tráfego da rede externa e produziránovotráfego na interface de loopback (e vice-versa). Isso funcionará.

Considere o seguinte exemplo de nmap (OS X):

sudo nmap -Pn -p 80 -S 192.168.2.1 -e lo0 127.0.0.1

Ele injetará pacotes à força (via root) na interface de loopback. Isso pode ser verificado executando tcpdump -i lo0em outro terminal. Porém, mesmo quando ncestava escutando, não encontrava a porta aberta. O seguinte, entretanto, encontra o ouvinte conforme esperado:

nmap -p 80 -e lo0 127.0.0.1

informação relacionada