☰

Windows netsh TCP portproxy не может пересылать пакеты через петлю. Решения?

tag-icon • tag-icon windows-7 networking proxy firewall ipv6
Windows netsh TCP portproxy не может пересылать пакеты через петлю. Решения?

Вот ситуация: запущена Win 7 Pro SP1 (версия 6.1.7601), брандмауэр Windows полностью отключен (даже добавлены правила, разрешающие что-либо, на всякий случай, если он все еще работает), в фоновом режиме не запущено ни одной программы (отключены все ненужные службы/exe), ipv6 установлен и работает нормально, netsh isatap и 6to4 включены. Teredo установлен в состояние по умолчанию.

Во-первых, я могу настроить netsh v4tov4 portproxy на интерфейс 192/8, и в этой ситуации portproxy будет работать нормально. В двух командных оболочках с повышенными правами я запускаю:

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]

Прокси-сервер порта перенаправляет и netcat работает как положено.

Далее, простое изменение на localhost (который преобразуется в [::1]) или явное использование 127.0.0.1 с правилом v4tov4 (также пробовал v6tov4) каждый раз приводит к сбою.

Например, начиная с 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]

Наконец, удаление всех старых правил netsh и попытка их использования с v6tov6 также оказались полной неудачей:

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]

Обратите внимание, что Windows7_x64 — это локальный хост, и интерфейс, похоже, работает нормально.

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

Также я могу напрямую подключиться к прослушиваемой конечной точке Netcat и отправлять данные без каких-либо проблем:

ncat -6 [::1] 13337

Проблема определенно в правилах netsh portproxy.

Так что тут происходит? Брандмауэр полностью отключен. Оболочка повышена. Больше ничего не запущено и не мешает (никаких AV/IDS).

Я пробовал добавлять различные комбинации правил v6tov4 и v4tov6, но это тоже ничего не дало. MS Message Analyzer не помогает, потому что он не улавливает интерфейс localhost, даже когда соединение устанавливается.

Есть идеи?

Редактировать 2016/10/15 23:58EST: Остановка следующих шести служб отключает проксирование портов по всем направлениям. Это предполагает, что одна из этих служб вовлечена в происходящее.

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

решение1

Это сделано намеренно. Пакеты, приходящие на интерфейс обратной связи (который на самом деле не существует в Windows), не могут исходить ни от чего, кроме 127.0.0.0/8. Аналогично, вы не можете отправлять пакеты ни куда, кроме , 127.0.0.0/8поскольку нет маршрута в другие места. Это означает, что даже если бы трафик пришел, прослушивающая программа не смогла бы ответить.

Если вы используете прокси-программу, она берет трафик из внешней сети и выдаетновыйтрафик на интерфейсе loopback (и наоборот). Это будет работать.

Рассмотрим следующий пример nmap (OS X):

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

Он принудительно (через root) вводит пакеты в интерфейс loopback. Это можно проверить, запустив tcpdump -i lo0на другом терминале. Однако даже при ncпрослушивании он не находил открытый порт. Однако следующее находит прослушиватель, как и ожидалось:

nmap -p 80 -e lo0 127.0.0.1

Связанный контент