問題：在NR289-E 路由器對8010端口進行映射（虛擬服務），映射到我自己的電腦的80端口，設置成功後，但在本機上（即192.168.1.80這台PC機）訪問域名和外網ip時，都是無法打開，還以為是映射不成功或是被路由器屏蔽了呢！
一直沒法解決，只好因vpn功能，讓別人訪問。
不管它了，字的時候無意間試了試，發現能訪問，於是經過確認才知道外網可以訪問，內網不能訪問。
在王龍找到一個叫 a龍的QQ網友，給了詳細的解釋。
本來就是這樣，不是你的問題。所有類似你這樣的做法，都是外網可以訪問，內網不能訪問。
簡單説明一下：
假設你的外網IP為 202.1.1.1 內網有2台192.168.1.10 192.168.1.11
做了IP地址映射 202.1.1.1:80->192.168.1.10:80
1。公網PC1訪問你的站點
PC1:X->202.1.1.1:80 (1個session 包含：[source ip:source port , desti p:dest port]4個參數 )
地址轉換後： pc1:x->192.168.1.0:80
192.168.1.0 到數據後，發數據給源站點
192.168.10:80->pc1:x 經過地址轉換 202.1.1.1:80->pc1:x
所以外網可以訪問你映射的站點.
2。如果在內網訪問
192.168.1.11:x->202.1.1.1:80 地址轉換後 192.168.1.11:x->192.168.1.10:80 到達站點
站點返回數據：
192.168.1.10:80->192.168.1.11:x
這裏是關鍵:192.168.1.10檢查後發現目標ip為192.168.1.11為同一網段，
所以直接把數據發給192.168.1.11,不再通過202.1.1.1轉發。
但是，192.168.1.11是向202.1.1.1發起連接，並沒有和192.168.1.10連接，所以將丟棄192.168.1.10發回的數據。
也就是説 192.168.1.11訪問202.1.1.1永遠也連接不上。
前段時間在公司的路由器上配置把公網IP映射到局域網中的一台電腦，映射為web服務器，在公司外面可以使用公網IP正常訪問web服務，但公司內部使用公網IP確無法訪問web服務。最開始以為是路由器配置問題，多次排查配置，沒有發現問題；然後想到會不會是本機路由表的問題，嘗試設置一些靜態路由，問題依然沒有解決；最後終於在網上找到類似的問題，原因是路由器硬件的問題，路由器不支持數據迴流造成。
關於“數據迴流”介紹，在網上看到一篇很好的文章以下轉帖。原文地址：http://www.5mwl.com/thread-17384-1-1.html
迴流是什麼？最簡單的一個實例：
網吧內網一台主機192.168.0.2建了個WEB服務站點端口80，然後在網關(其內網地址是192.168.0.1、公網地址為218.4.218.4)上映射80端口到192.168.0.2的80端口，這樣INTERNET上就能以http://218.4.218.4:80的地址訪問到192.168.0.2的WEB站點了。然後出現了個問題，在同網吧的另一台電腦192.168.0.3上，鍵入http://218.4.218.4:80，卻無法訪問該WEB站點。就這個現象，我們就稱之為“不支持迴流”了，這裏指的是網關上的映射方式不支持迴流，所以説“迴流”一説，是針對映射方式而言的。
現在我們來看常規情況下，是為什麼會發生這種情況的
過程如下：
192.168.0.3要請求訪問218.4.218.4的80端口，根據它掌握的路由表，它本身是不知道電腦218.4.218.4在哪裏的，所以把將這個數據包發送給它的默認路由，即電腦192.168.0.1。注意：這個數據包的源地址是192.168.0.3、源端口假設是1025、目標地址是218.4.218.4、目標端口是80、SYN標誌位為1、這是建立TCP連接的第一次握手。如果“把目標地址為218.4.218.4的數據包發給了192.168.0.1”你聽起來覺得有點矛盾，那麼我解釋一下：其實這個數據包的目標IP地址是218.4.218.4，目標MAC地址卻是192.168.0.1的電腦192.168.0.1接收到了這份數據包(因為它的身份是路由器，所以允許接收和轉發目標地址不是自已、MAC地址卻是自已接口 MAC地址的數據包)，它分析這個數據包的目標地址，發現這個數據包是需要中轉到電腦192.168.0.2:80去的，於是它把這個數據包轉發給了電腦 192.168.0.2:80。注意：這個數據包的源地址是192.168.0.3、源端口是1025、目標地址為192.168.0.2、目標端口為80、SYN標誌位為1。我們要注意這個數據包在轉發後發生了變化了，即目標地址變了。電腦192.168.0.2順利接到了數據包，它馬上作出迴應，發送一個數據包給電腦192.168.0.3。注意：這個數據包的源地址是192.168.0.2、源端口是80、目標地址192.168.0.3、目標端口為1025、SYN標誌位為1、ACK標誌位為1、這是建立TCP連接的第二次握手。電腦192.168.0.3順利接到了數據包，然而它發現這是一個來自192.168.0.2:80的迴應，因為ACK標誌位值為1擺在那裏呢。它想不起來什麼時候給192.168.0.2:80這個目標對象發送過SYN請求，它認為這是一個錯誤的數據包，於是決定把這個數據包丟棄。然後繼續等待 218.4.218.4:80的迴應，一直等到超時。而電腦192.168.0.2這邊，它等192.168.0.3:1025的第三次握手請求包發送過來，以便建立一個TCP的連接。同樣也沒有結果，一直等到超時。三次握手在規定的時間內沒有完成，訪問宣佈流產了。
那麼怎麼樣才能正常訪問呢？也就是説怎麼樣形成“迴流”呢？
玄機在於電腦192.168.0.1把第一次握手的那個數據包在轉發時，不僅要修改目標地址和端口，也要修改源地址和端口，我們來看一下情況會有什麼不同：電腦192.168.0.1接收到了這份數據包(因為它的身份是路由器，所以允許接收和轉發目標IP地址不是自已、MAC地址卻是自已接口MAC地址的數據包)，它分析這個數據包的目標地址，發現這個數據包是需要中轉到電腦192.168.0.2:80去的，於是它把這個數據包通過自已的5201端口轉發給了電腦192.168.0.2:80，並在內存裏面記錄下來了，192.168.0.1:5201已定位給了192.168.0.3:1025。注意：這個數據包的源地址是192.168.0.1、源端口是5201、目標地址為192.168.0.2、目標端口為80、SYN標誌位為1。電腦192.168.0.2順利接到了數據包，它馬上作出迴應，發送一個數據包給電腦192.168.0.1。注意：這個數據包的源地址是192.168.0.2、源端口是80、目標地址192.168.0.1、目標端口為5201、SYN標誌位為1、ACK標誌位為1、這是建立TCP連接的第二次握手。電腦192.168.0.1順利接到了數據包，檢查內存記錄發現，這個數據包真正的收貨人是192.168.0.3:1025，於是它把這個數據包轉發給192.168.0.3。注意：這個數據包的的源地址是218.4.218.4、源端口為80、目標地址為192.168.0.3、目標端口為1025。我們要注意這個數據包在轉發後發生變化了，即源地址變了。這很重要！為什麼會變，因為在它心目當中，192.168.0.2:80早已定位給了218.4.218.4:80，映射規則使然。電腦192.168.0.3順利接到了數據包，發現期待已久的218.4.218.4:80終於有了迴音，它興奮不已的發出第三次的握手請求。注意：這個數據包的源地址是192.168.0.3、源端口是1025、目標地址是218.4.218.4、目標端口是80、ACK標誌位為1、這是建立TCP連接的第三次握手。跟前面的數據包一樣，這個數據包會從192.168.0.1那裏中轉給192.168.0.2以後192.168.0.2:80和192.168.0.3:1025之間來往通信的數據包，全部由192.168.0.1負責中轉，“迴流”構成了
|
[精華] NAT後無法在內網通過外部IP訪問內部服務的問題的詳細説明(原創)
|
|
|
|
作者:fushuyong 發表於：2005-05-11 09:41:20 |
|
【 |
|
最近，到處看到有人問這個問題，怎麼以前沒人問，現在這麼多人問呢？前兩天我還在華為的論壇上仔細的説了這個問題，現在複製到這邊來。希望能幫助大家理解這個問題。 這是個理論問題，我們先從NAT講起：NAT有兩種基本類型，一種是SNAT（Source NAT)，一種是DNAT(Dest. NAT).SNAT即源NAT是改變數據包的IP層中的源IP地址，一般是用來將不合法的IP外出請求轉換成合法的IP的外出請求，就是普通的用一個或者幾個合法IP來帶動一整個非法IP段接入。 DNAT即目的NAT，就是改變數據包的目標IP地址，使得能對數據包重新定向，可以用做負載均衡或者用於將外部的服務請求重定向到內網的非法IP的服務器上。 好了，羅嗦了一通，大致就是這樣了。 那麼之所以會出現無法在DNAT的內部網絡通過DNAT服務的外部IP地址來訪問的情況，是因為，如果服務從內部請求，那麼經過DNAT轉換後，將目標IP改寫成內網的IP地址，譬如172.16.10.254,而請求的機器的IP是 172.16.10.100,數據包被網關172.16.10.1順利的重定向到172.16.10.254的服務端口，然後，192.16.10.254根據請求發送迴應給目的IP地址，就是172.16.10.100,但是，問題出現了，因為172.16.10.100請求的地址是外部IP 假設是221.232.34.56,所以他等待着221.232.34.56的迴應，而172.16.10.254的迴應請求被看做是非法的，被丟棄了。這就是問題的所在了。 呵呵，寫的有點混亂，不好意思。不知道大家明白沒有.那麼如何解決這個問題，我説個用iptables實現的例子， #我們先把發向外網IP221.232.34.56 80號端口的數據重定向到172.16.10.254 理論上來講，如果只要從外網訪問，這就完成了。 iptables -t nat -A PREROUTING -p tcp -d 221.232.34.56 --dport 80 -j DNAT --to-destination 172.16.10.254 #解決內網通過外網IP訪問的情況 iptables -t nat -A POSTROUTING -p tcp -d 172.16.10.254 --dport 80 -j SNAT --to-source 172.16.10.1 我們將內網的請求強行送回到網關172.16.10.1，依靠網關在內核建立的狀態表再轉發到真實的請求地址172.16.10.100. 當然，這並不是最好的解決方法，最好的解決方法是將服務器放在另外一個網段，也就是説所謂的DMZ（解除武裝區），這樣就不會出現上面所説的問題了。 如果大家還不清楚，給個參考文檔： http://iptables-tutorial.frozentux.net/iptables-tutorial.html#DNATTARGET 就先説到這裏了，我要去上班了。
|
路由器迴流(端口映射特例）
迴流是什麼？最簡單的一個實例：
網吧內網一台主機192.168.0.2建了個WEB服務站點端口80，然後在網關(其內網地址是192.168.0.1、公網地址為218.4.218.4)上映射80端口到192.168.0.2的80端口，這樣INTERNET上就能以 http://218.4.218.4:80的地址訪問到192.168.0.2的WEB站點了。
然後出現了個問題，在同網吧的另一台電腦192.168.0.3上，鍵入 http://218.4.218.4:80，卻無法訪問該WEB站點。
就這個現象，我們就稱之為“不支持迴流”了，這裏指的是網關上的映射方式不支持迴流，所以説“迴流”一説，是針對映射方式而言的。
現在我們來看常規情況下，是為什麼會發生這種情況的
我以前對iptables特別感興趣的時候，曾對這個問題非常迷惑不解，直到去年為了考試，學習網絡基礎的時候才搞明白這個事情
過程如下：
192.168.0.3要請求訪問218.4.218.4的80端口，根據它掌握的路由表，它本身是不知道電腦218.4.218.4在哪裏的，所以把將這個數據包發送給它的默認路由，即電腦192.168.0.1。
注意：這個數據包的源地址是192.168.0.3、源端口假設是1025、目標地址是218.4.218.4、目標端口是80、SYN標誌位為1、這是建立TCP連接的第一次握手。
如果“把目標地址為218.4.218.4的數據包發給了192.168.0.1”你聽起來覺得有點矛盾，那麼我解釋一下：其實這個數據包的目標IP地址是218.4.218.4，目標MAC地址卻是192.168.0.1的 @蒼星歸來
電腦192.168.0.1接收到了這份數據包(因為它的身份是路由器，所以允許接收和轉發目標地址不是自已、MAC地址卻是自已接口 MAC地址的數據包)，它分析這個數據包的目標地址，發現這個數據包是需要中轉到電腦192.168.0.2:80去的，於是它把這個數據包轉發給了電腦 192.168.0.2:80。
注意：這個數據包的源地址是192.168.0.3、源端口是1025、目標地址為192.168.0.2、目標端口為80、SYN標誌位為1。我們要注意這個數據包在轉發後發生了變化了，即目標地址變了。
電腦192.168.0.2順利接到了數據包，它馬上作出迴應，發送一個數據包給電腦192.168.0.3。
注意：這個數據包的源地址是192.168.0.2、源端口是80、目標地址192.168.0.3、目標端口為1025、SYN標誌位為1、ACK標誌位為1、這是建立TCP連接的第二次握手。
電腦192.168.0.3順利接到了數據包，然而它發現這是一個來自192.168.0.2:80的迴應，因為ACK標誌位值為1擺在那裏呢。它想不起來什麼時候給192.168.0.2:80這個目標對象發送過SYN請求，它認為這是一個錯誤的數據包，於是決定把這個數據包丟棄。然後繼續等待 218.4.218.4:80的迴應，一直等到超時。
而電腦192.168.0.2這邊，它等192.168.0.3:1025的第三次握手請求包發送過來，以便建立一個TCP的連接。同樣也沒有結果，一直等到超時。三次握手在規定的時間內沒有完成，訪問宣佈流產了。
那麼怎麼樣才能正常訪問呢？也就是説怎麼樣形成“迴流”呢？
玄機在於電腦192.168.0.1把第一次握手的那個數據包在轉發時，不僅要修改目標地址和端口，也要修改源地址和端口，我們來看一下情況會有什麼不同：
電腦192.168.0.1接收到了這份數據包(因為它的身份是路由器，所以允許接收和轉發目標IP地址不是自已、MAC地址卻是自已接口MAC地址的數據包)，它分析這個數據包的目標地址，發現這個數據包是需要中轉到電腦192.168.0.2:80去的，於是它把這個數據包通過自已的5201端口轉發給了電腦192.168.0.2:80，並在內存裏面記錄下來了，192.168.0.1:5201已定位給了192.168.0.3:1025。
注意：這個數據包的源地址是192.168.0.1、源端口是5201、目標地址為192.168.0.2、目標端口為80、SYN標誌位為1。
電腦192.168.0.2順利接到了數據包，它馬上作出迴應，發送一個數據包給電腦192.168.0.1。
注意：這個數據包的源地址是192.168.0.2、源端口是80、目標地址192.168.0.1、目標端口為5201、SYN標誌位為1、ACK標誌位為1、這是建立TCP連接的第二次握手。
電腦192.168.0.1順利接到了數據包，檢查內存記錄發現，這個數據包真正的收貨人是192.168.0.3:1025，於是它把這個數據包轉發給192.168.0.3。
注意：這個數據包的的源地址是218.4.218.4、源端口為80、目標地址為192.168.0.3、目標端口為1025。我們要注意這個數據包在轉發後發生變化了，即源地址變了。這很重要！為什麼會變，因為在它心目當中，192.168.0.2:80早已定位給了218.4.218.4:80，映射規則使然。
電腦192.168.0.3順利接到了數據包，發現期待已久的218.4.218.4:80終於有了迴音，它興奮不已的發出第三次的握手請求。
注意：這個數據包的源地址是192.168.0.3、源端口是1025、目標地址是218.4.218.4、目標端口是80、ACK標誌位為1、這是建立TCP連接的第三次握手。
跟前面的數據包一樣，這個數據包會從192.168.0.1那裏中轉給192.168.0.2
以後192.168.0.2:80和192.168.0.3:1025之間來往通信的數據包，全部由192.168.0.1負責中轉，“迴流”構成了