[概要]
下記のようなNATでNAT OutsideからInsideへ通信を行った際に、
意図しないNATが行われてしまう動作を取り上げます。
ip nat outside source route-map TEST pool POOL add-route
access-list 100 deny ip 10.0.0.0 0.0.0.255 10.0.10.0 0.0.0.255
access-list 100 permit ip 10.0.0.0 0.0.0.255 10.0.100.0 0.0.0.255
access-list 100 deny ip any any
route-map TEST permit 10
match ip address 100
ip nat pool POOL 192.168.0.2 192.168.0.200 netmask 255.255.255.0
このNAT設定はOutsideからInsideへ通信に対して、
route-map TESTに合致した場合に送信元のIPアドレスを変換することになります。
もっと言えば、下記のACLに合致したときのみNATが適応されることを意図しております。
access-list 100 permit ip 10.0.0.0 0.0.0.255 10.0.100.0 0.0.0.255
しかしながら、このOutsideからInsideへの通信において、
このpermitに送信元IPアドレスのみが合致している場合でもNATが行われてしまいます。
もう少し具体的に見てみます。
[NW構成]
IPアドレスは一例です。
[試験]
ルータ1より通信を行います。
下記の場合はroute-mapのpermitに合致しますので、NATされます。
ルータ1#ping 10.0.100.2 source lo0 (10.0.0.1)
そして、NATルータにエントリが作成されます。
NATルータ#show ip nat translations
この状態でroute-mapのdenyに合致し、NATされないはずの通信を行うと、
NATされてしまいます。ただし、送信元IPアドレスは先に作られたエントリに合致します。
ルータ1#ping 10.0.10.2 source lo0 (10.0.0.1)
なお、NATルータにエントリがない状態ですと、この通信はNATされることはありません。
(参考)
NATルータにて"debug ip nat detailed"を有効にしますとその様子がご覧になれます。
*Oct 20 04:54:10.835: NAT: s=10.0.0.1->192.168.0.2, d=10.0.10.2 [106]
*Oct 20 04:54:10.835: NAT*: i: icmp (10.0.10.2, 22) -> (192.168.0.2, 22) [106]
*Oct 20 04:54:10.835: NAT*: s=10.0.10.2, d=192.168.0.2->10.0.0.1 [106]
[見解]
本件のNAT設定は実装上サポートされない設定となります。
ルータは先にNATのエントリをチェックし、
該当がない場合にroute-map等のチェックが行われる動作になります。
このため、送信元がNATのエントリに一致しているとroute-mapで除外されるべき通信であっても、
NATで変換がされてしまいます。
[回避策]
INとOUTを入れ替えip nat "inside" sourceにて同様の設定をご検討ください。