[問題] 請教用router來共用一組IP的設定

fake802 wrote:
暫且不論ARP(http://en.wikipedia.org/wiki/Address_Resolution_Protocol)穿不穿過router,這跟後面這句有邏輯關係會成立嘛?或者我們反過來講,如果WAN端無法看到LAN內的MAC,那麼為什麼電腦犯罪者會被人跑到家裡面抓出來?
(ht...(恕刪)


因為你有access 紀錄,警察跟提供服務業的者吊特定時間的access log,裡面有誰來access 的 IP,在根據IP找ISP要用戶資料,然後就來你家敲門,跟MAC一點關係也沒有
stish wrote:
1. 除非用戶端的分...(恕刪)


您的看法,包含對於能否偵測NAT的部份,我也都認同

我想所謂偵測NAT的技術,也許只是一種大陸網友的一種看法
總之大陸ISP具有封網的能力,是無庸置疑

看了看封包,我還是沒想到封包中有何特徵可以用來判斷
而我能想到比較可能的,也只有觀察單一IP/MAC的連線併發數來判定
由於多人共享,NAT Router的連線併發數的確會較一台電腦多
若某個時間超過系統的值,即拒絕來自那個IP的新連線的發起
這樣的功能,我想不需我多做解釋,基本上是可以達到的,也不是什麼新技術
不過與其說是偵測NAT,倒不如說是預防P2P的激烈手段

但是樓主所提的是,除了Skype之外,其餘網路服務皆無法使用
因此我才會想到會不會是DNS部分的問題
也許只是DNS設定問題,根本也沒有所謂偵測NAT的手段
剛剛我再度做了測試,手動設定網卡IP,DNS後, flush dns
然後開啟Skype,登入仍然正常
從封包中我確定Skype即使在網卡沒有配置DNS Server組態下
不需透過DNS Server查詢 ui.skype.com,也能夠登入成功
看起來是有內建預設的登入主機IP address list(不是ui.skype.com)
一個一個先用UDP探查,就是下圖中的第17-21筆封包
先回應的就先嘗試登入,下圖中,是第22筆封包那個IP先回了
MSN就沒辦法了, 一定得有DNS Server


可惜樓主似乎沒有回音了,不知道後續消息
http://caf677.pixnet.net/blog
小弟是從事電信業,個人較認同 stish 大的看法。
因為社區網路業者都是在 ADSL 電路前加設備,要限頻寬、要做些管控其實不難。
我這里的ISP只偵測80端口,即使無法瀏覽網頁,EMULE/QQ(UDP方式)同樣可以使用,
即使是HTTP數據包但如果走8080/8088等端口,同樣不偵測,同時開一臺筆電+一臺動物機可以正常連接網絡,但是兩臺同時瀏覽網頁就不行了,不過如果有一臺只訪問HTTPS的網站或使用VPN則沒有問題

有人和我說過,TCP/IP協議發出的數據包(报文)文件頭中會有一串數字,雖然即使是一臺電腦,這串數字也會有差距,但是不會差的太大,但是局域網中兩臺不同的電腦這個數字就差的比較大了,據說ISP就是從這串數字來分析路由下電腦的數量的(如下文的红色的id xxxxx为一台主机,蓝色的为另一台主机),不过这种方法经常会出现误判,我多次给ISP打电话抱怨,但是还是经常会出现误判的现象

12:19:41.000000 10.10.49.204.61993 > 10.199.201.37.http: . [tcp sum ok] ack 4292552168 win 64240 (DF) (ttl 127, id 40255, len 40)
12:20:23.000000 10.10.49.204.62017 > 10.199.201.37.http: . [tcp sum ok] ack 1 win 64240 (DF) (ttl 127, id 40756, len 40)
12:21:37.000000 10.10.49.204.62216 > 10.54.226.252.http: S [tcp sum ok] 1820371619:1820371619(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) (ttl 127, id 57601, len 48)
12:21:40.000000 10.10.49.204.61993 > 10.199.201.37.http: . [tcp sum ok] ack 4293696808 win 64240 (DF) (ttl 127, id 41427, len 40)
12:22:06.000000 10.10.49.204.61993 > 10.199.201.37.http: . [tcp sum ok] ack 4293946004 win 64240 (DF) (ttl 127, id 41671, len 40)
12:23:10.000000 10.10.49.204.62017 > 10.199.201.37.http: . [tcp sum ok] ack 1633741 win 64240 (DF) (ttl 127, id 42293, len 40)
12:24:00.000000 10.10.49.204.61993 > 10.199.201.37.http: . [tcp sum ok] ack 4294795172 win 64240 (DF) (ttl 127, id 42632, len 40)
12:24:24.000000 10.10.49.204.61993 > 10.199.201.37.http: SFRPW [bad tcp cksum 1748!] 2115643160:2115643180(20) ack 972685314 win 46144 urg 3585 (DF) (ttl 125, id 42893, len 40)
12:25:05.000000 10.10.49.204.62259 > 10.200.222.45.http: P [bad tcp cksum 6be7!] ack 1 win 19652 (DF) (ttl 127, id 1673, len 40)
12:25:53.000000 10.10.49.204.61993 > 10.199.201.37.http: . [tcp sum ok] ack 940080 win 64240 (DF) (ttl 127, id 43799, len 40)
12:25:56.000000 10.10.49.204.61993 > 10.199.201.37.http: . [bad tcp cksum 579d!] ack 1019539 win 17520 (DF) (ttl 125, id 43846, len 40)
12:25:56.000000 10.10.49.204.62017 > 10.199.201.37.http: E [bad tcp cksum 8380!] 2120652494:2120652506(12) win 11414 urg 5633 (DF) (ttl 125, id 43859, len 40)
12:26:05.000000 10.10.49.204.62259 > 10.200.222.45.http: R [tcp sum ok] 3206002624:3206002624(0) win 0 (DF) (ttl 127, id 1731, len 40)


共享神盾的readme


共享神盾是一款针对网络运营商利用垄断地位对家庭宽带共享进行限制的反突破软件。软件基于Windows底层网络驱动以及报文伪装等技术,可以非常出色的突破封锁。
共享神盾可以突破目前各种封锁设备,如网络尖兵、南京信风等

PS:這款軟體是用WinPcap來修改封包的,如果能力強的話估計用WinPcap就可以解決問題了,这里有篇文章说明了共享神盾的原理,可以参考一下http://www.51gongxiang.cn/shendun/2007-12-06/41.html(简体的)
caf677 wrote:
您的看法,包含對於能...(恕刪)


我目前也比較傾向於 caf677 的說法,因為只有skype正常,算是一個很重要
的線索。而且在skype連線時(其他service都不行),我家也就只有我1台電
腦在開機狀況。我完全沒有辦法理解他怎麼透過只有1台在開機的PC就認定我
還有別的PC,或我在NAT


SKYPE是优先使用UDP连接吧,我这里的ISP是不分析UDP数据包的

不知道ISP是不是把router也判定为一台主机了,在大陆的某些城市,是完全不能使用router的,router可以连接上ADSL,但是router下的主机却无法上网,据说是从MAC上判定的,那些ISP只允许线路连接一个MAC地址,使用USB的小乌龟就可以正常上网(网卡接口的小乌龟也不行,据说网卡接口的小乌龟本身也有一个MAC地址)。

不知道将主机的MAC和router的MAC改成一样的地址能否解决问题

另外这个和DNS没有关系,因为大陆ISP有DNS劫持的毛病,所以我一直用OPENDNS,可能会和网关有点关系,因为那个侦测软件部署的服务器和网关服务器是同一个IP,不过我想这个只要部署在主干网上就可以了吧,网络方面不是很懂,瞎猜的
如果只有一台理論上他不會知道
如果你認為是DNS的問題,那你就改DNS看看
因為現在的IP分享器在設定上都會把自己當作DNS,分享器在去做recursive的查詢,這時候DNS的查詢行為是server,你把他改成DNS client方試看看

不過這種方式的層次太低啦!三兩下就破解了

還是不行,就要分析封包了
stish wrote:
.....Double NAT在傳統的網路上是沒有問題的.....(恕刪)

沒錯,這應不是問題所在,個人曾在分享器之下再串一級分享器,使用多年已沒什麼怪問題,其實公司內部網路很多人這麼使用........
今天做了小小的測試...

將原先有NAT的架構上... 串聯兩個NAT架構...


實驗的整體架構圖
簡單來說 WAN <-> DI-704UP <-> BLW-04GM <-> DI-704UP <-> NB



NB 的 IP



PDA 的 IP



先用NB來ping看看能不能ICMP到PDA上...



再測看看能不能Ping到自己的 Gateway 上...



測試看看能不能ping自己的WAN IP



測試看看能不能ping到 pci BLW-04GM 的 WAN IP



測試看看能不能ping到 192.168.0.100 (Files Server)



測試看看能不能ping到 最後一道IP Sharing的機器...



測試看看能不能ping到 CHT DNS (168.95.1.1)



看看能不能連到 www.mobile01.com 上面...



看PDA能不能連上 www.mobile01.com



查看看從我這邊到www.mobile01.com的連線路徑



查看看從我這邊到花蓮師範學院DNS的連線路徑



實驗結果是可以正常連線啦!!!
多重NAT經過測試,連線是沒有問題的!!!
阿胖技研,專研資訊相關技術!
文章分享
評分
評分
複製連結

今日熱門文章 網友點擊推薦!