O Windows netsh TCP portproxy falha ao encaminhar pacotes por meio de loopback, soluções?

1

Aqui está a situação, rodando o Win 7 Pro SP1 (versão 6.1.7601), o firewall do Windows está completamente desabilitado (até mesmo regras adicionadas para permitir qualquer coisa), nenhum programa rodando em segundo plano (morto) cada serviço / exe desnecessário, ipv6 está instalado e funcionando bem, netsh isatap e 6to4 estão habilitados. Teredo é definido para o estado padrão.

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

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 de porta encaminha e o netcat funciona como esperado.

Em seguida, simplesmente mudando para localhost (que resolve para [:: 1]) ou explicitamente usando 127.0.0.1 com uma regra v4tov4 (também tentou v6tov4) falhar toda vez.

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]

Por fim, excluir todas as regras antigas do netsh e testá-lo com o 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]

Observação 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 é definitivamente com as regras do portproxy netsh.

Então, o que dá aqui? O firewall está completamente desligado. Concha elevada. Nada mais correndo para ficar no caminho (sem AV / IDS).

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

Alguma idéia?

Editar 2016/10/15 23: 58EST: Parar os seis serviços a seguir desabilita a eliminação de portas em toda a linha. Isso sugere que um desses serviços está envolvido com o que está acontecendo.

sc stop homegrouplistener
sc stop Browser
sc stop lanmanserver
sc stop smb
sc stop iphlpsvc
    
por Dustin Darcy 16.10.2016 / 00:03

1 resposta

0

Isso é por design. Os pacotes que chegam na interface de loopback (que realmente não existem no Windows) não podem originar de nada além de 127.0.0.0/8 . Da mesma forma, você não pode enviar pacotes para nada além de 127.0.0.0/8 porque não há rota para outros locais. Isso significa que, mesmo que o tráfego chegasse, o programa de audição não poderia responder.

Se você usa um programa proxy, ele recebe tráfego da rede externa e produz o tráfego novo na interface de loopback (e vice-versa). Isso vai funcionar.

Considere o seguinte exemplo nmap (OS X):

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

Ele irá forçar (via root) a inserir pacotes na interface de loopback. Isso pode ser verificado executando tcpdump -i lo0 em outro terminal. No entanto, mesmo quando nc estava ouvindo, não encontraria a porta aberta. O seguinte, no entanto, encontra o ouvinte como esperado:

nmap -p 80 -e lo0 127.0.0.1
    
por 16.10.2016 / 00:13