1

Вот ситуация, в которой работает 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 - это localhost, и интерфейс работает нормально. 

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 ответ1

0

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

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

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

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

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

nmap -p 80 -e lo0 127.0.0.1
|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .