配置NAT迴流致使外網解析到了內網IP

單位有3個域名，用量很大，2014年開始本人研究部署了Bind+DLZ +Mysql的三機智能多鏈路DNS，很是好用，優勢是：

一、使用Mysql管理記錄，配置、管理、查詢方便。

二、自動判斷運營商，返回指定IP，實現智能多鏈路。目前咱們單位有電信、移動、教育網專線和固定IP，經過Bind的View，判斷請求源IP自動返回對應運營商的服務IP。很好很強大也很實用。

三、根據配置自動爲內網分配對應的運營商解析。。。我單位內網用戶較多，有一個很多見的需求，內網部分用戶要使用電信專線、部分用戶要使用移動專線，然而走電信的就得用電信DNS解析、走移動就得用移動DNS解析，一樣的，Bind的View也很好的解決了這個問題。

 

 

然而、、、、、今天忽然讓我崩潰了，有二、3個域名外網訪問部分出錯、打不開網頁。我仔細研究，發現外網被解析成了內網IP。。。以下圖：

這讓我很頭疼呀，仔細分析，把Bind從Dump緩存、Config文件、ACL文件所有翻了個遍，沒發現問題。。。。。這個問題的情況是這樣的：只有二、3個域名有這個問題，其它子域名（近幾十個）都沒問題。。。。

很奇葩，我都有點懷疑跟服務器有沒有關係呀。。。。。

 

折騰二、3天沒搞定，也沒想通。。。今天晚上從路由器入手打算再走一遍，我手頭有3個路由器，一行行看配置，終於找到點眉頭，被解析錯誤的地址，我在其中一個路由器上作了NAT迴流。。。

好吧，什麼是NAT迴流？這裏簡單講講，詳細的你們上網搜吧，就是我作了nat server，好比： nat server protocol tcp global X.X.X.X any inside 192.168.200.57 any。這時外網用戶經過X.X.X.X的公網IP、內網用戶經過192.168.200.57的IP分別能夠訪問對應的服務，固然主要是用DNS了，可是若是我內網裏有人用X.X.X.X的公網IP去訪問呢？這時正常、默認的NAT配置是訪問不了了，詳細我也不說了，搜到這篇文章的興許就是這個故障，這時就要作一個NAT迴流，讓路由器從內網過來的訪問公網IP請求可以像在外網同樣訪問，這時配置NAT迴流就能夠，我是這樣弄的（路由器是H3C的）：

一、先搞個迴流的ACL。。。個人故障就在這裏了，一會說。

 acl number 3010
 rule 5 permit ip source 172.16.0.0 0.0.255.255
 rule 6 permit ip source 172.17.0.0 0.0.255.255
 rule 7 permit ip source 172.21.0.0 0.0.255.255
 rule 8 permit ip source 172.22.0.0 0.0.255.255
 rule 15 permit ip source 192.168.0.0 0.0.255.255
 rule 100 deny ip

 

二、在內網接口上配置，注意是內網，而不是外網。

interface GigabitEthernet2/2/0
 port link-mode route
 nat outbound 3010
 nat server protocol icmp global X.X.X.X inside 192.168.200.57
 nat server protocol tcp global X.X.X.X any inside 192.168.200.57 any
 ip address 10.10.248.1 255.255.255.252

 

那爲何這個迴流會致使外網解析到了內網IP呢？？？緣由是我在作Acl的時候，當時只是爲了測試一下這個200.57的業務內網用公網IP訪問，就簡單的內網IP都給Permit了，這個配置NAT迴流是能夠了，但因爲沒有匹配目標IP，致使全部包都能迴流，致使內網的DNS回傳給外網DNS服務器的響應包識別爲是內網地址段來的，就丟了個內網IP給人家運營商服務器。。。把上面Acl改完善就OK了，完整的應該是這樣：

 rule 5 permit ip source 172.16.0.0 0.0.255.255 destination 192.168.200.57 0
 rule 6 permit ip source 172.17.0.0 0.0.255.255 destination 192.168.200.57 0
 rule 7 permit ip source 172.21.0.0 0.0.255.255 destination 192.168.200.57 0
 rule 8 permit ip source 172.22.0.0 0.0.255.255 destination 192.168.200.57 0
 rule 100 deny ip

也就是嚴格匹配內網地址段 to 內網須要NAT迴流的服務器內網地址。。。這樣對這臺的NAT迴流也正常（內網用它的公網IP也能夠訪問）、同時也不會出現BIND解析出錯的問題。。。

 

固然若是你不提供像個人這個智能BIND解析服務，那你就像上面那個籠統的ACL也是能夠的。。。我這是兩個功能在一塊兒就衝突了的。

2016-11-18補充：

後來發現，其實光ACL也沒用，仍是會這樣呀。。。。。苦苦研究一個多月，最終在廠商工程師的幫助下解決了問題，原來是路由器的DNS-ALG在做怪，H3C路由器V5平臺下ALG功能默認是開啓的，而V7下默認是關閉了就沒這問題。個人是V5，得手動關閉一下：系統視圖下：undo alg dns

解決問題了。。。。OK，那麼alg dns是什麼鬼呢？來看看：

NAT ALG 功能，僅在要經過NAT 設備進行DNS、FTP、SIP 和RTSP 等應用（如DNS 服務器在公網中，須要在內網中使用域名訪問位於內網的服務器時）時，須要配置NAT ALG 功能。使能ALG 功能可使NAT 設備識別被封裝在報文數據部分的IP 地址或端口信息，並根據動態造成的NAT 地址（或同時包括端口號）映射表項進行替換，使報文正常穿越NAT。

因此呢，nat server只在inbound生效，應該是報文從內網返回命中內斂口，出去了返回的是私網解析。。。

 

至此，該問題完全解決。。。