很是有意思的策略地址轉換故障排查

某客戶要求本地主機A（10.1.1.1）新增訪問需求，原主機A在邊界路由器將地址轉換爲A1（23.1.1.30）後訪問外聯單位的主機B（1.1.1.1），現新增長一個系統C（3.3.3.3）,須要將地址轉換爲A2（23.1.1.31）去訪問。以下圖所示網絡結構，R3模擬外聯單位路由器，R4模擬互聯網;

簡單來講就是一個策略NAT：

A（10.1.1.1）-》B（1.1.1.1）將A地址轉換爲23.1.1.30

A（10.1.1.1）-》B（3.3.3.3）將A地址轉換爲23.1.1.31

首先定義匹配策略，須要定義源和目的，使用擴展訪問控制列表：

ip access-listextended nat30

 permit ip host 10.1.1.1 host 1.1.1.1

ip access-listextended nat31

 permit ip host 10.1.1.1 host 3.3.3.3

而後定義route-map：

route-map nat30permit 10

 match ip address nat30    

route-map nat31permit 10

 match ip address nat31

最後定義nat：

ip nat insidesource static 10.1.1.1 23.1.1.30 route-map nat30

ip nat insidesource static 10.1.1.1 23.1.1.31 route-map nat31

而後進行測試，居然不通！！！

 

而後進行測試，居然不通！！！

 

而後進行測試，居然不通！！！

 

因爲是生產環境，沒法抓包，沒法debug….

 

本身檢查了幾遍IP地址、調用的策略名等沒有任何問題，命令放入IOS同版本的模擬器去執行，測試無問題！

 

Show ip access 檢查匹配項，居然無匹配，說明問題出在匹配上，繼續檢查acl、IP地址等等等等……

 

開始懷疑其它nat轉換影響了該策略轉換，發現現網配置裏有這麼一條：

ip nat pool nat100 23.1.1.100 23.1.1.100 netmask255.255.255.255

access-list 110permit ip host 10.1.1.1 any

ip nat insidesource list 110 pool nat100 overload

 

也就是說本網段訪問其它地址時會被轉換成23.1.1.100的PAT，在直覺中，策略的靜態一對一轉換轉換應該會優於PAT吧。。。

 

可是在access-list 110中插入deny iphost 10.1.1.1 host 1.1.1.1和deny ip host 10.1.1.1 host 3.3.3.3後測試，沒有任何問題！

 

難道是PAT優先靜態轉換？

 

找到問題所在就好，測試了另一種轉換方式也能夠實現：

 

ip nat pool nat3023.1.1.30 23.1.1.30 netmask 255.255.255.0

ip nat pool nat3123.1.1.31 23.1.1.31 netmask 255.255.255.0

access-list 130permit ip host 10.1.1.1 host 23.1.1.30

access-list 131permit ip host 10.1.1.1 host 23.1.1.31

ip nat insidesource list 130 pool nat30 overload

ip nat insidesource list 131 pool nat31 overload

 

看來都是pat，你們級別同樣了，就最小匹配啦！

 

那麼留給你們的問題是，這兩種實現方式在實際應用中有什麼區別呢？

 

使用靜態route-map的轉換方式，能夠用於對端須要主動發起訪問的狀況，這樣當對端1.1.1.1或3.3.3.3能夠主動訪問23.1.1.30或23.1.1.31。