
情況是這樣的,運行Win 7 Pro SP1(版本6.1.7601),Windows 防火牆完全禁用(甚至添加了允許任何內容通過的規則,以防萬一它仍然在運行),沒有程式在後台運行(殺死了所有不必要的服務) /exe),ipv6 已安裝且工作正常,netsh isatap 和 6to4 已啟用。 Teredo 設定為預設狀態。
首先,我可以為 192/8 介面設定一個 netsh v4tov4 portproxy,在這種情況下 portproxy 將正常工作。在兩個提升的命令 shell 中我運行:
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 沒有幫助,因為即使連線確實建立,它也不會取得本機主機介面。
有任何想法嗎?
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
沒有到其他位置的路由,否則您無法將資料包發送到任何地方。這意味著即使流量到達,監聽程序也無法應答。
如果您使用代理程序,它會從外部網路獲取流量並產生新的環回介面上的流量(反之亦然)。這會起作用。
考慮以下 (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