Hier ist die Situation: Ich führe Win 7 Pro SP1 (Version 6.1.7601) aus, die Windows-Firewall ist vollständig deaktiviert (es wurden sogar Regeln hinzugefügt, um alles durchzulassen, falls es trotzdem noch läuft), es laufen keine Programme im Hintergrund (alle unnötigen Dienste/Exes wurden beendet), IPv6 ist installiert und funktioniert einwandfrei, Netsh Isatap und 6to4 sind aktiviert. Teredo ist auf den Standardzustand eingestellt.
Erstens kann ich einen Netsh v4tov4-Portproxy für die 192/8-Schnittstelle einrichten und in dieser Situation wird der Portproxy einwandfrei funktionieren. In zwei erhöhten Befehlsshells führe ich aus:
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]
Die Port-Proxy-Weiterleitungen und Netcat funktionieren wie erwartet.
Als nächstes schlägt jedes Mal ein einfacher Wechsel zu localhost (was sich in [::1] auflöst) oder die explizite Verwendung von 127.0.0.1 mit einer v4tov4-Regel (ich habe auch v6tov4 versucht) fehl.
Beginnend mit 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]
Schließlich ist auch das Löschen aller alten Netsh-Regeln und der Versuch mit v6tov6 ein völliger Reinfall:
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]
Beachten Sie, dass Windows7_x64 ein lokaler Host ist und die Schnittstelle einwandfrei zu funktionieren scheint.
C:\>ping localhost
Pinging Windows7_x64 [::1] with 32 bytes of data:
Reply from ::1: time<1ms
Außerdem kann ich mich direkt mit dem lauschenden Netcat-Endpunkt verbinden und ohne Probleme Daten senden:
ncat -6 [::1] 13337
Das Problem liegt definitiv an den Netsh-Portproxy-Regeln.
Was ist also hier los? Die Firewall ist vollständig ausgeschaltet. Erhöhte Shell. Sonst läuft nichts, was stören könnte (kein AV/IDS).
Ich habe versucht, verschiedene Kombinationen von v6tov4- und v4tov6-Regeln hinzuzufügen, aber das hat auch nichts bewirkt. MS Message Analyzer hilft nicht, da es die Localhost-Schnittstelle nicht erkennt, selbst wenn die Verbindung hergestellt wird.
Irgendwelche Ideen?
Bearbeiten 15.10.2016 23:58EST: Durch das Stoppen der folgenden sechs Dienste wird das Portproxying generell deaktiviert. Das würde darauf schließen lassen, dass einer dieser Dienste an dem Geschehen beteiligt ist.
sc stop homegrouplistener
sc stop Browser
sc stop lanmanserver
sc stop smb
sc stop iphlpsvc
Antwort1
Dies ist beabsichtigt. Pakete, die über die Loopback-Schnittstelle ankommen (die es unter Windows eigentlich nicht gibt), können nur von stammen 127.0.0.0/8. Ebenso können Sie Pakete nur an senden, 127.0.0.0/8da es keine Route zu anderen Standorten gibt. Das heißt, selbst wenn der Datenverkehr ankommen würde, könnte das abhörende Programm nicht antworten.
Wenn Sie ein Proxy-Programm verwenden, nimmt es den Verkehr vom externen Netzwerk auf und erzeugtneuDatenverkehr auf der Loopback-Schnittstelle (und umgekehrt). Das funktioniert.
Betrachten Sie das folgende (OS X) nmap-Beispiel:
sudo nmap -Pn -p 80 -S 192.168.2.1 -e lo0 127.0.0.1
Es wird zwangsweise (über Root) Pakete in die Loopback-Schnittstelle einspeisen. Dies kann durch Ausführen tcpdump -i lo0auf einem anderen Terminal überprüft werden. Allerdings nckonnte es auch beim Lauschen den offenen Port nicht finden. Folgendes findet den Listener jedoch wie erwartet:
nmap -p 80 -e lo0 127.0.0.1