この記事の構成を前提に話を進めます。
今回のテーマ
Q: 以下のコンフィグでは正しくNATされません。なぜでしょう？
iosv-2(config)#ip nat outside source static 20.1.1.1 10.1.1.1A: no-alias add-routeがなく、NAT前にルーティング処理がされるから。
解説と検証
ping(iosv-3→10.1.1.1)
iosv-3
◎事前に#debug ip icmpを実行している。
- 10.1.1.1からのリプライを受信していることが確認できる。
iosv-3#ping 10.1.1.1 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 33/33/33 ms
iosv-3#
*Jan 22 23:05:05.065: ICMP: echo reply rcvd, src 10.1.1.1, dst 10.1.1.3, topology BASE, dscp 0 topoid 0iosv-2
◎事前に#debug ip icmpと#debug ip natを実行している。
- iosv-3(10.1.1.3)のICMPにリプライを送信している。
- しかし、debug ip natの出力がなく、NATされていないことがわかる。
- 「受信していないこと」を確認するのでブログ媒体で証跡は取れないが、iosv-1ではICMPを受信しておらず、iosv-2が返してしまっていることがわかる。
iosv-2#debug ip icmp
ICMP packet debugging is on
iosv-2#debug ip nat
IP NAT debugging is on
iosv-2#
*Jan 22 22:56:24.943: ICMP: echo reply sent, src 10.1.1.1, dst 10.1.1.3, topology BASE, dscp 0 topoid 0NATの処理順序について
CCOにNATの処理順序について記載がある。
抜粋すると、inside→outsideへの通信の場合、先にルーティングをしてからNAT変換することになる。
今回の場合、以下のようなフローになる。
- iosv-3から10.1.1.1宛にICMP Echo Requestが送信される。
- iosv-2がICMP Echo Requestを受信する。
- RIBを参照する。
- 宛先が10.1.1.1であるため、同セグのGigabitEthernet0/0(inside向きのインターフェース)から送信すればよいと判断する。
- NAT処理が行われる（今回は10.1.1.0/24に返すだけなのでNATされない）
- iosv-3にEcho Replyが着信する。
参考：iosv-2のRIB
10.1.1.1/32がdirectly connected, GigabitEthernet0/1(inside向きのインターフェース)となっていることが確認できる。
iosv-2#sh ip ro | b Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.1.1.0/24 is directly connected, GigabitEthernet0/1
L 10.1.1.1/32 is directly connected, GigabitEthernet0/1
L 10.1.1.254/32 is directly connected, GigabitEthernet0/1
20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 20.1.1.0/24 is directly connected, GigabitEthernet0/0
L 20.1.1.254/32 is directly connected, GigabitEthernet0/0no-aliasとadd-route
上記の理由から、10.1.1.1の送信インターフェースをGigabitEthernet0/0(outside向きのインターフェース)にする必要がある。
この時に必要なコマンドが２つ、「no-alias」と「add-route」。
コンフィグ
add-routeは文字通り経路を追加するもの。
no-aliasが問題児。ざっくり言うとエイリアスを作成しARPの代理応答を行うそうだが、当該バージョン以降コードの実装方式が変わったらしく、不具合が現れるのだそう。
ARPの代理応答はproxy-arpで問題ないのでno-aliasで無効にすると問題なくNATしてくれる。
iosv-2(config)#ip nat outside source static 20.1.1.1 10.1.1.1 no-alias add-routeRIB(iosv-2)
「S 10.1.1.1/32 [1/0] via 20.1.1.1」が追加されており、宛先が10.1.1.1のパケットはoutsideへ流すようになった。
iosv-2#sh ip ro | b Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.1.1.0/24 is directly connected, GigabitEthernet0/1
S 10.1.1.1/32 [1/0] via 20.1.1.1
L 10.1.1.254/32 is directly connected, GigabitEthernet0/1
20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 20.1.1.0/24 is directly connected, GigabitEthernet0/0
L 20.1.1.254/32 is directly connected, GigabitEthernet0/0参考
Understand the NAT Order of Operation