Junos SRX NAT介紹

與ScreenOS相比，SRX在NAT功能實現方面基本保持一致，但在配置上有較大區別，主要差異在于ScreenOS的NAT與policy是綁定的，無論是MIP/VIP/DIP還是基于策略的NAT，在policy中均要體現出NAT內容（除了缺省基于untrust接口的Souec-NAT模式外），而SRX的NAT則作為網絡層面基礎內容進行獨立配置（獨立定義地址映射的方向、映射關系及地址范圍），Policy中不再包含NAT相關配置信息，這樣的好處是易于理解、簡化運維，當網絡拓樸和NAT映射關系發生改變時，無需調整Policy配置內容。

在SRX中安全策略只負責控制業務數據的轉發與否，NAT策略只控制業務數據的源地址和端口的翻譯規則，兩者各自獨立。

SRX的NAT配置分為源地址翻譯(source NAT)，目標地址翻譯(destination NAT)和靜態地址翻譯(static NAT)三種，其配置語法都類似，只是nat rule必須被放到rule-set里使用，任意兩個zone或任意兩個網絡邏輯接口之間只允許有一個rule-set。

Junos為SRX提供了一個完整而集成的NAT功能。NAT在【security】層級下配置，集成了有狀態流處理，但它在邏輯上是security policy配置分離。

一個給定的流量可以最多匹配一個NAT規則，必須匹配一個安全策略security policy。NAT與security policy之間沒有直接的對應關系，一個匹配NAT規則的流量可以被一個或者安全策略匹配。一個匹配security policy規則的流量可以被0,1或者多個NAT規則匹配。但是，一旦一個匹配NAT規則的流，將會在會話表session table建立雙向的表項。

圖5-1所示為在SRX流模型NAT的處理。

SRX內 NAT處理流程

請注意，靜態NAT和目標NAT規則匹配在路由查找/Zone確定之前，也在Policy之前。源NAT和反向靜態NAT的匹配在Policy匹配之后。

SRX這種不依賴于Policy的更靈活和精確的NAT配置模式，使得拓撲和地址翻譯的重新設計成為可能，而Policy可以保持不變。

因為Source NAT在路由和Zone查找之后，配置rule-sets時必須同時指定ingress和egress interface、zone、routinginstance。Static和Destination NAT在路由和Zone查找之前進行處理，rule-sets只需配置ingress的interface、zone、routing instance。

當多個NAT rule-sets包含的上下文都匹配給定流，具有最具體上下文的rule-set用于確定翻譯動作。一個包含匹配接口上下文的rule-set優選于一個具有匹配zone的上下文，而匹配Zone的上下文優于配路由實例的上下文。在所選擇的rule-set內，按照順序評估rules，第一個匹配的用于確定翻譯動作的流程。

SRXNAT和Policy執行先后順序為：目的地址轉換－目的地址路由查找－執行策略檢查－源地址轉換，結合這個執行順序，在配置Policy時需注意：Policy中源地址應是轉換前的源地址，而目的地址應該是轉換后的目的地址，換句話說，Policy中的源和目的地址應該是源和目的兩端的真實IP地址，這一點和ScreenOS存在區別，需要加以注意。

SRX中不再使用MIP/VIP/DIP這些概念，其中MIP被Static靜態地址轉換取代，兩者在功能上完全一致；DIP被Source NAT取代；基于Policy的目的地址轉換及VIP被 Destination NAT取代。ScreenOS中基于Untrust zone接口的源地址轉換被保留下來，但在SRX中不再是缺省模式（SRX中Trust Zone接口沒有NAT模式概念），需要手工配置。類似ScreenOS，Static屬于雙向NAT，其他類型均屬于單向NAT，

此外，SRX還多了一個proxy-arp概念，如果定義的IPPool（可用于源或目的地址轉換）與接口IP在同一子網時，需配置SRX對這個Pool內的地址提供ARP代理功能，這樣對端設備能夠解析到IPPool地址的MAC地址（使用接口MAC地址響應對方），以便于返回報文能夠送達SRX。

值得注意的是SRX不會自動為NAT規則生成proxy-arp配置，因此如果NAT地址翻譯之后的地址跟出向接口地址不同但在同一網絡內時，必須手工配置相應接口proxy-arp以代理相關IP地址的ARP查詢回應，否則下一條設備會由于不能通過ARP得到NAT地址的MAC地址而不能構造完整的二層以太網幀頭導致通信失敗。