一般普通路由器只要做完端口映射，NAT是不需要設置的，稍微高級點的路由器，就需要配置一下了。然后就可以訪問了。
下面是網站找的說明：(下面的說明都2007年左右，原理沒問題，不過現在所有的路由器都應該支持“回流”了)
簡單說明一下：
假設你的外網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.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負責中轉，“回流”構成了
具體在軟件上的實現，不是我的事了 現在的“回流”應用常見於私服 Linux里的iptables可以增加一條規則來實現對回流的支持 很多硬件路由器不用設置就內建支持的 Win2K的ICS/NAT內建的映射是標准DNAT，同樣是不支持的、除非用第三方工具 CC、RouterOS聽說是支持的，不懂，沒空去整過 SW現在還有好多人在問，好像是沒輒，我不知道SW是不是能跟iptables一樣靈活 BBIagent以前的版本沒戲、現在不知 。。。。。(此處省略五千字)
不知大家明白了沒有，反正我倒是有點糊塗了，繼續睡覺去。。。 睡眠不足，亂寫了一氣，前面也許寫錯許多，而且老實說最后一段是寫的沒有耐心了 寫得頭痛，以后有空再作修改補充罷