究竟為什么內(nèi)網(wǎng)不能用公網(wǎng)地址訪問內(nèi)網(wǎng)服務(wù)器。不是任何設(shè)備都存在此問題,拿cisco的設(shè)備來說,不同版本的ios,有的就沒有這個問題,而有的版本就有問題,netscreen的防火墻也沒有這個問題,關(guān)鍵是開發(fā)者有沒有意識到這個問題,通過修改ios,完全可以避免。對于這個問題,解決方法是有,比如內(nèi)網(wǎng)dns欺騙、pix上得alias等等,但是究竟為什么有些設(shè)備不支持呢?今天我斗膽發(fā)個貼,因為有些結(jié)論純粹靠想,也沒有設(shè)備進行試驗,所以希望大家跟貼討論,達到拋磚引玉的目的,謝謝了先!
以下所有內(nèi)容均針對出口是以太網(wǎng)的情況,對于串口接入,不會出現(xiàn)這種問題。
本地出口地址是5.5.5.1,isp對端是5.5.5.2(掩碼沒寫,稍后會分別討論)。 1.1.1.1和1.1.1.2是內(nèi)網(wǎng)兩臺服務(wù)器的內(nèi)網(wǎng)地址,被靜態(tài)映射到公網(wǎng)上的5.5.5.4和5.5.5.5. 內(nèi)網(wǎng)的pc全部被pat到出口上。本地路由器一條缺省路由到isp對端。
我想這個拓撲應(yīng)該是非常普遍的了,我認為就是因為這個非常普遍的拓撲,造成了很多人所反應(yīng)的“內(nèi)網(wǎng)不能通過公網(wǎng)地址訪問內(nèi)網(wǎng)服務(wù)器”這個問題。我認為這個問題的關(guān)鍵原因就在于掩碼,就是在3層上做文章。
第一節(jié)
先來看看一般情況下,這個環(huán)境的掩碼的規(guī)劃。假設(shè)isp分配一段8地址子網(wǎng)給本地,這樣isp路由器接口和本地路由器接口共占用2個,網(wǎng)絡(luò)地址、廣播地址共占用2個,可用的一共4個,掩碼是248。對于圖示的拓撲,假設(shè)本地路由器出口掩碼是248(內(nèi)網(wǎng)pc的pat地址相應(yīng)的也就是掩碼為248),被映射的兩個地址掩碼也是248,這個最普遍的掩碼規(guī)劃,結(jié)果是:服務(wù)器、內(nèi)網(wǎng)pc的pat地址、本地出口地址全部處于同一個網(wǎng)段。我們分析一個包的來龍去脈,來看看到底內(nèi)網(wǎng)pc通過公網(wǎng)地址可否訪問到內(nèi)網(wǎng)服務(wù)器。
假設(shè)內(nèi)網(wǎng)一臺pc1.1.1.111發(fā)出ping 5.5.5.4(服務(wù)器的公網(wǎng)地址)請求,包源地址1.1.1.111,目的地址5.5.5.4,路由器收到這個包后,檢查路由表,發(fā)現(xiàn)5.5.5.4就位于自己的出口網(wǎng)段(假設(shè)出口為以太口),所以直接通過arp廣播請求5.5.5.4的mac地址,問題出現(xiàn)了,誰會應(yīng)答這個請求呢?沒有人,所以,這種情況下(所有公網(wǎng)地址在同網(wǎng)段)當(dāng)然不會通。不但內(nèi)網(wǎng)訪問服務(wù)器不行,服務(wù)器之間通過公網(wǎng)地址訪問也不會通。
結(jié)論一:只要出口地址和服務(wù)器映射的公網(wǎng)地址在同網(wǎng)段,就有問題。
第二節(jié)
基于上面的討論,我們知道了只要出口地址和服務(wù)器映射的公網(wǎng)地址在同網(wǎng)段,就會發(fā)生“無人應(yīng)答”的必然結(jié)果,所以我們這次改變掩碼規(guī)劃,將出口掩碼變長,變?yōu)?52(isp掩碼也要相應(yīng)改變)。在這里首先聲明一個要點,就是nat池的地址可以和出口不在同網(wǎng)段,以前有帖子也討論過,我自己一開始也迷惑,后來想明白了,只要isp路由器上有這些地址的路由就可以,下一條是本地路由器,這樣本地路由器便可以接受到這些包。
我們再次分析一個包的流程。內(nèi)網(wǎng)pc1.1.1.111發(fā)出ping 5.5.5.4請求,包源地址1.1.1.111,目的地址5.5.5.4,路由器收到這個包后,檢查路由表,這一次,發(fā)現(xiàn)5.5.5.4不在本地的任何接口,所以走了缺省路由,將包發(fā)給了isp對端口,并在本地nat表中生成一條項目,記錄內(nèi)網(wǎng)地址1.1.1.111被轉(zhuǎn)換成公網(wǎng)地址5.5.5.1加上端口號(假設(shè)端口號是8888),isp接受到的包,目的地址是5.5.5.4,源地址變成了5.5.5.1,它檢查它的路由表,發(fā)現(xiàn)5.5.5.4路由下一條是5.5.5.1,也就是本地路由器,所以又將此包發(fā)給本地路由器,經(jīng)過了一次往返后,本地收到這個包,首先接受nat引擎的過慮,發(fā)現(xiàn)5.5.5.4正在被靜態(tài)映射到內(nèi)網(wǎng)的1.1.1.1的主機,所以改變目的地址為1.1.1.1,源地址還是5.5.5.1,這樣就交給了路由引擎,查看路由表,1.1.1.1的路由當(dāng)然有了,通過2層直接發(fā)給1.1.1.1,至此,去程的包分析完畢。
我們再分析回程的包。服務(wù)器1.1.1.1收到包后,準備回應(yīng)給5.5.5.1(加端口號),發(fā)出reply包,源地址1.1.1.1,目的地址5.5.5.1:8888,本地路由器收到后,先給路由引擎,發(fā)現(xiàn)5.5.5.1就是出口地址,問題又來了,包的目的就是出口,而不是經(jīng)過出口,這時候路由器該怎么辦呢?假如是從外向內(nèi)來的包訪問5.5.5.1:8888,這時候會先提交個nat引擎,做nat轉(zhuǎn)換。但是這是從內(nèi)向外發(fā)出的包,要先提交給路由引擎,我認為此時,由于收到的包是從內(nèi)向外的,目的直接就是針對出口來的,而出口并沒有開啟什么端口,除非為了web管理,或者telnet管理開啟80或23端口,所以路由器會丟棄,因為沒有得到應(yīng)答。
結(jié)論二:只要出口地址和內(nèi)網(wǎng)pc的pat地址同網(wǎng)段,同樣會有問題
第三節(jié)
我們再變更掩碼方案,使得內(nèi)網(wǎng)pc的pat地址和服務(wù)器映射地址同網(wǎng)段,但和出口不同網(wǎng)段。假設(shè)內(nèi)網(wǎng)pc的pat地址為5.5.5.6(和服務(wù)器地址同網(wǎng)段)
我們再次分析一個包,內(nèi)網(wǎng)pc1.1.1.111發(fā)出ping 5.5.5.4請求,包源地址1.1.1.111,目的地址5.5.5.4,路由器收到這個包后,檢查路由表,發(fā)現(xiàn)5.5.5.4不在本地的任何接口,所以走了缺省路由,將包發(fā)給了isp對端口,并在本地nat表中生成一條項目,記錄內(nèi)網(wǎng)地址1.1.1.111被轉(zhuǎn)換成公網(wǎng)地址5.5.5.6加上端口號,isp接受到的包,目的地址是5.5.5.4,源地址變成了5.5.5.6,它檢查它的路由表,發(fā)現(xiàn)5.5.5.4路由下一條是5.5.5.1,也就是本地路由器,所以又將此包發(fā)給本地路由器,經(jīng)過了一次往返后,本地收到這個包,首先接受nat引擎的過慮,發(fā)現(xiàn)5.5.5.4正在被靜態(tài)映射到內(nèi)網(wǎng)的1.1.1.1的主機,所以改變目的地址為1.1.1.1,源地址還是5.5.5.6,這樣就交給了路由引擎,查看路由表,1.1.1.1的路由當(dāng)然有了,通過2層直接發(fā)給1.1.1.1,至此,去程的包分析完畢。
我們再分析回程的包。服務(wù)器1.1.1.1收到包后,準備回應(yīng)給5.5.5.6(加端口號),發(fā)出reply包,源地址1.1.1.1,目的地址5.5.5.6,本地路由器收到后,先給路由引擎,發(fā)現(xiàn)5.5.5.6不在本地任何端口下,所以走了缺省路由,發(fā)給isp,并在nat表中生成一條記錄,將1.1.1.1轉(zhuǎn)換為5.5.5.4,isp接受到包源地址變?yōu)?.5.5.4,目的地址是5.5.5.6,通過檢查路由表,發(fā)現(xiàn)5.5.5.6這個地址的路由下一條應(yīng)該是5.5.5.1,也就是本地路由器,所以包又被發(fā)回來了,經(jīng)過一次往返,本地收到了這個包,首先提交給nat引擎,發(fā)現(xiàn)目的地址5.5.5.6在nat表中對應(yīng)著內(nèi)網(wǎng)pc1.1.1.111,所以將5.5.5.6替換成1.1.1.111,源地址不變,還是5.5.5.4,然后提交給路由引擎,路由器在2層將包發(fā)給1.1.1.111,這時,1.1.1.111這臺主機收到了從5.5.5.4返回的包,而他一開始ping請求包,就是發(fā)給5.5.5.4這個公網(wǎng)地址的,所以ping通了!!!!
結(jié)論三:內(nèi)網(wǎng)pc的pat地址和服務(wù)器公網(wǎng)地址同網(wǎng)段,同時和出口地址不同網(wǎng)段,這樣沒有問題。