淺談內網web服務器發佈到公網後路由器迴流問題--NAT--PAT---技術研究

淺談路由器迴流問題：

迴流問題是指，當用路由器防火牆等設備將內網服務器發佈到公網上，供internet用戶訪問的過程當中出現的一種現象，就是你發現web服務器已經成功發佈了，internet用戶也已經能夠經過你路由器公網接口地址成功訪問了，而你卻發現本身在內網中與web服務器同網段的主機上直接訪問那個路由器公網地址是沒法訪問到web服務器的頁面內容的。這就是迴流問題。

 

下面具體分析一下產生這個現象的緣由：

假設內網web服務器地址192.168.0.1 ，路由器公網地址200.200.200.1

來自internet用戶的地址是200.200.200.100  ，來自內網與web服務器同網段用戶的地址是192.168.0.100

 

        首先看一下外網用戶發出對web服務器頁面訪問的過程，

第一步，外網用戶在瀏覽器輸入http://200.200.200.1 以後發生了什麼？http協議是利用tcp協議的80端口工做的，而tcp是面向鏈接的協議，也就是說，使用該協議傳輸數據是須要事先跟目標服務器協商的，協商好了才能發數據，tcp協議須要三次對話協商，首先客戶端發了一個源地址200.200.200.100的目標地址200.200.200.1目標端口80的請求包告知目標主機「我打開了80端口我想與你鏈接」這個數據包按照目標地址經過網絡傳輸到了路由器的公網接口，因爲路由器對公網接口以及它的內網接口之間作了NAT技術，因此該數據包在路由器公網接口被加工改造，將目標地址改爲了192.168.0.1源地址不變放到了路由器的緩存隊列中，路由器轉發程序發現該數據包是發往192.168.0.1的，根據自身路由表中的直連路由直接找到內網接口，這樣數據包就到了內網接口，而後就開始在內網接口發送該數據包的脈衝信號，與內網接口相連的交換機，收到該數據包會查找本身的MAC地址表，看192.168.0.1的主機與本身哪一個接口相連，因而該數據包就被髮到了與web主機相連的交換機端口打上本身端口的MAC地址後發往web主機，這樣服務器就接收到了這個請求包。由於交換機對此問題不產生影響因此以後的內容就不談交換機轉發的過程了。

         第二部，根據TCP協議，服務器接收到這目標地址爲192.168.0.1源地址爲200.200.200.100的數據包後須要發回確認包告訴訪問者本身贊成鏈接，並打開本身的80端口。因而發送一個源地址192.168.0.1目標地址200.200.200.100的確認迴應包到路由器的內網接口，在內網接口經過NAT端口映射技術將此包的源地址改寫爲外網口地址200.200.200.1目標地址不變放入緩存隊列，轉發程序發現該包是去往200.200.200.100的，根據路由表中的直連路由直接送到外網接口，因而外網接口把包發給了外網用戶的主機。

 

         第三部，根據tcp協議，外網主機收到了源地址200.200.200.1目標地址200.200.200.100的迴應包後還需再次發送一個確認包，告訴目標主機，「我要發送數據了，你作好準備「

經過前面三步就完成了tcp的鏈接，開始傳輸數據的過程，此後的數據包都是，你請求什麼頁面什麼內容，服務器就給傳什麼內容，請求包目標地址都是200.200.200.1。 

/////整個tcp鏈接過程當中，訪問者客戶端主機是不知道真正給他提供迴應和服務的真正主機在哪的

=====================

         下面看從內網與web服務器同網段的主機訪問web服務器的過程，

 

         第一步，與前面相似，瀏覽器輸入：http://200.200.200.1, 而後根據ctp協議發送目標200.200.200.1源192.168.0.100目標端口80的請求包，這個請求包正常到了路由器內網接口，以後可能有幾種狀況，均可能引發迴流問題。

        第一種狀況：

        下面注意該過程與上面的區別，該包是發往路由器外接口的，而不是發往外網的，因此路由器不會啓用pat地址轉換，直接把包根據路由表投遞給外網接口，外網接口發現這個包是發送給本身的而且目標端口是80，因而自動應用NAT端口映射技術，修改包的目標地址爲192.160.0.1源地址不變放入緩存隊列，轉發程序正常根據目標地址把包送到了web服務器。

         web服務器收到目標地址爲192.168.0.1源端口是192.168.0.100的數據包後根據TCP協議做出迴應，須要發送目標地址192.168.0.100  源地址192.168.0.1的迴應包，這個包這回沒到達路由器內網接口，而是直接經過交換機就跑回來了，由於在ip網絡中，相同網段有直接通訊的特性，而你的內網客戶端這回就萌了，「我何時給你發過請求啊？你算幹嗎的你給我一個迴應確認包啊！」因而你的客戶端繼續等待200.200.200.1給他迴應！

 

         能夠看出，tcp的迴應包是不能正常發回的，你的主機在苦苦等待而沒有結果後，宣告TCP第二次握手等待超時，鏈接失敗。

 

         還可能有一種狀況，也就是說，你內網客戶機採用與web服務器不一樣網段來訪問200.200.200.1，發送完請求包後，服務器會將回應包仍然發到路由器內網端口，因爲是發往內部主機的，路由器仍是不會啓用pat轉換，而是經過直連路由直接轉發給你的客戶機，這樣你的客戶機仍然收不到源地址爲200.200.200.1的迴應包，仍是不能成功創建鏈接。    

         

        另一種狀況，若是路由器將你發往200.200.200.1的數據包算作是發往外網，對其作了pat轉換，或路由器是強制地址轉換的，那麼該數據包的源地址將變爲200.200.200.1到達路由器外部接口，而路由器若是有相關防錯功能，也許該數據包就直接被幹掉了，若是能夠繼續轉發那麼該數據包將以源地址爲200.200.200.1目標地址192.168.0.1到達web服務器。而服務器迴應的數據包就會以目標地址200.200.200.1 源地址200.200.200.1到達路由器外部接口。而路由器外部接口此時就盟了。

 

         前兩種狀況的關鍵之處就是外網接口應用了NAT端口映射技術，致使你的主機老是在等待路由器的外部端口回覆確認信息。然後一種狀況關鍵之處就在於當你從內網其餘主機訪問路由外部端口地址時，被應用了PAT技術，將包的源地址進行了修改，致使web服務器迴應包不知道真實的訪問者地址。

         也就是說NAT端口映射技術沒有很好的與PAT端口複用技術協同工做，致使迴流問題產生，若是不該用PAT作端口地址轉換複用，或nat端口映射，就不會有迴流問題，那麼同時也無法訪問外網。外部主機也訪問不了內部服務器。

         在此過程當中若是想判斷你內網客戶端發往web服務器的數據包究竟有沒有被路由器進行pat轉換，能夠在web服務器上使用抓包軟件，看一下收到的tcp請求包的源地址是192.168.0.100仍是200.200.200.1就知道了。

        

        下面簡要介紹一下NAT技術

NAT分爲：分爲靜態NAT，動態NAT，NAT端口映射

NAT就是在路由器上將出去的數據包源地址轉換爲其餘接口地址使之與其餘網絡段匹配，回來的數據包將目標地址再轉換回原來發包的主機地址。方便公網的訪問，而且屏蔽數據包來源，還起到節省公網地址的做用。設是路由除了轉發之外的看家本領，咱們從局域網訪問internet就是靠它實現的。

 

       運營商不可能把每一個要上網的用戶都分配一個公網IP，公網IP是不準重複的，由於它用來惟一標定網絡上每一個路由器或主機的位置，重複就會出問題。且公網的網絡設備數量龐大，公網上的全部路由器和主機配置的都是公網IP地址，因此公網IP地址是有限的能夠說是稀缺的，而局域網中主機和網絡設備數量少，通常都使用私有地址配置，不一樣局域網中的不一樣主機IP重複是沒什麼問題的，只要在一個局域網中保證沒有重複，每臺設備都能惟一標定就好了，

      那麼如何讓內網用戶可以訪問公網服務器的內容又與公網在邏輯上是分開的呢？那就得依靠NAT技術了

 

       靜態NAT就是指靜態一對一轉換，通常將要上網主機發到外網接口的數據包源地址轉換爲外網爲接口地址，最初的NAT有個缺陷，就是當某一個主機正在訪問網絡時，那麼他佔用了路由器外網接口地址，那麼其餘主機就無法訪問，最初是這樣解決的，只要要求運營商多分配些合法IP地址就好了，在路由器上設置一個可用於地址轉換的合法ip地址列表，也叫可用轉換地址池。這樣內網不一樣主機同時訪問時可讓路由器自動使用地址池中的不一樣地址作轉換。同時路由器會將對應關係記錄到映射表中。以便服務器迴應數據包時查找對應主機。

 

       動態NAT就是根據要訪問網絡的主機網卡MAC地址來讓路由自動判斷那個是須要轉換的主機，不須要指定轉換哪些iP地址。不過這個技術仍是不經常使用的。

 

        隨着局域網要上網主機的增多，運營商能提供的合法公網地址又有限，這樣就沒法知足大量局域網主機同時上網的需求，因而又誕生了PAT技術

 

        PAT技術又稱基於端口的地址制轉換技術，能夠說是NAT技術的升級

它在NAT轉換的基礎之上，將內網不一樣主機發到外網接口的數據包源地址轉換爲同一外網地址，但端口使用不一樣端口轉發，並且將數據包進入時的端口和轉發出去時的端口以及源ip地址對應關係記錄到一個映射表中，用於迴應數據包返回時查找對應的主機。注意，在菜用PAT端口複用技術時，數據包包的源端口和目的端口是沒有被改寫的。只是路由器自身使用了不一樣端口進行轉發。

 

         現在使用的都是PAT轉換技術，才使得這麼多的局域網主機可以同時上網的，不過有時也習慣將PAT稱爲動態NAT轉換。

=================

 

         針對迴流問題的解決方案分析，

         若是迴流問題是前兩種狀況產生的，那麼能夠考慮將內網訪問主機改成其餘網段，並強制其pat轉換，而後仍是考慮如何讓那個目標地址和源地址都爲外網口自身的數據包能繼續轉發下去。

         有人提出能夠在路由器上再作一個反向NAT端口映射，可實際上要作的事用反向端口映射來形容是不恰切的。

         根據個人理解：

         nat端口映射是改寫包的目標地址

         nat轉換是改寫數據包的源地址

         二者配合使用才完成了內網與外網服務的互通

         試想如何將源地址爲外網口地址的數據包的目標地址轉換爲內網主機地址呢？由於通常都是將內網固定地址映射爲指定外網端口，意義是將該外網端口的來源爲任何地址的數據包的目標地址改成內網指定地址，而須要作的是將內網多個地址映射到外網口的指定地址，意義是未來源爲固定地址的數據包的目標地址改成指定的一些地址。

但該方法可能有些路由器或防火牆不支持，

-------------------------------

        而反向NAT端口映射要作的事是什麼呢？

        是將外網某臺服務器的的端口映射到路由器內網端口，讓用戶訪問內網路由接口就能夠直接訪問到外面的服務器，並且要保證返回數據包能在外網接口正常將源地址修改成路由器內網口地址或可用的內網地址。

         但要注意的是其餘的可用內網地址必須是定義在內網口的地址池中的地址，

這些地址就至關於給該網口配置的附加地址。

         以上所作的就是反向NAT端口映射，和反向nat轉換。

 

         因此實際解決迴流問題的配置操做應該叫作：

         正向的指定多個內網主機到外網固定地址的NAT端口映射。

         也就是限定了數據包來源只能是外網端口地址，若是不限定來源，那麼外網的全部訪問數據包將直接到達內網，也就是說至關於把正個內網經過nat端口映射發佈到了網上。

 

         作該配置前，首先應當看內網發佈的含有80端口的其餘服務器可否經過路由器外網口地址正常訪問該WEB服務器。若是不能實現的話，就是說明該配置是行不通的。

 

         若是行的通能夠發佈另外一個主機的全部端口到外網，以便將該主機做爲測試機，從而省去了找運營商另外添接線路的麻煩。

 

          //不過這臺主機的全部端口都是暴露在網上的，有必定的安全隱患，發佈的時候能夠考慮只開放相關的端口

          另外在端口映射的同時若是可以限定外網訪問者地址來源那是最好，最好能直接指定爲外網口地址。

 

總之可否實現迴流仍是得看路由器或防火牆是否支持相應配置了，根據以上解決思路來看仍是有個疑點的，由於以上思路的配置不過是實現了路由器外端口源與目標端口都爲外端口地址的數據包的繼續轉發給內網主機，而沒作上述配置前路由器自己是已經作了一條該端口到內網web服務器的映射的，若是以上配置可行，那麼原來的配置也該可行，那麼該回應數據包是否會返回web服務器自身呢？