華爲E1000防火牆acl規則配置錯誤致使用戶NAT失敗

文章出處：www.net1980.com

                Eudemon防火牆在執行NAT時，當區域間存在多個NAT OUTBOUND的狀況下，該命令不是根據命令配置的前後順序（即排列順序）來執行的，而是以該命令引用的ACL序號的大小順利來執行。

故障現象：
                在某ISP的防火牆中，"客戶A"的私網IP地址198.1.1.40須要轉換成公網地址201.109.109.70；其餘私網地址客戶須要轉換爲公網地址201.109.103.20；數據配置完成以後，咱們發現"客戶A"（198.1.1.40）不能實現NAT轉換，業務不通，而其餘網段用戶則能轉化公網地址201.109.103.20正常上網。

 

數據配置以下：
acl number 3300
rule 101 permit ip source 10.10.46.0 0.0.0.255
rule 102 permit ip source 10.10.47.0 0.0.0.255
rule 103 permit ip source 10.10.48.0 0.0.0.255
rule 104 permit ip source 10.10.49.0 0.0.0.255
rule 105 permit ip source 10.10.53.32 0.0.0.31
rule 106 permit ip source 10.10.53.64 0.0.0.7
rule 107 permit ip source 10.10.54.0 0.0.0.255
rule 1000 deny ip
acl number 3301
rule 0 permit ip source 198.1.1.40 0

nat address-group 0 201.109.103.20 201.109.103.20
nat address-group 1 201.109.109.70 201.109.109.70

firewall interzone trust untrust
packet-filter 3200 inbound
packet-filter 3100 outbound
nat outbound 3301 address-group 1
nat outbound 3300 address-group 0

緣由分析：
                Eudemon防火牆在作NAT時，當區域間存在多個NAT OUTBOUND的狀況下，該命令不是根據命令配置的前後順序（即排列順序）來執行的，而是以該命令引用的ACL序號的大小順利來執行的。在前一命令 ACL中匹配不到的語句則繼續按照下一命令的ACL進行匹配。在此案例中即先執行了ACL 3300中的規則，而在此ACL最後卻存在一條deny ip 的語句，致使後面ACL的用戶匹配此規則而被拒絕NAT。

 

處理步驟：
要解決這個問題，須要修改ACL的編號，刪除ACL 3301，新建ACL 3299：
acl number 3299
rule 0 permit ip source 198.1.1.40 0

firewall interzone trust untrust
packet-filter 3200 inbound
packet-filter 3100 outbound
nat outbound 3299 address-group 1
nat outbound 3300 address-group 0
通過上述調整後，從新測試，此時198.1.1.40地址的用戶已經可以轉換爲公網IP 地址201.109.109.70上網，業務正常。

故障總結：
一、 在進行防火牆地址轉換時，須要注意NAT OUTBOUND命令的執行順序是按照ACL的大小順序執行的，並不是按照命令配置順序執行。
二、 這也說明了維護經驗積累的重要性，這種故障技術難度不大，但假如沒有處理過這類故障的話，也要花費較多的時間進行檢查。

 

原文連接： http://www.net1980.com/2010/01/13/%E5%8D%8E%E4%B8%BAe1000%E9%98%B2%E7%81%AB%E5%A2%99acl%E8%A7%84%E5%88%99%E9%85%8D%E7%BD%AE%E9%94%99%E8%AF%AF%E5%AF%BC%E8%87%B4%E7%94%A8%E6%88%B7nat%E5%A4%B1%E8%B4%A5/