Zenn
🔖

ルータとNATの挙動の整理

2024/04/14に公開
nw
tech

まとめ

  • ルータはIPヘッダの中身は書き換えず、宛先ルートにパケットを転送する
  • 静的NAT
    • 最初からNATテーブルにレコードが登録される
    • 両方向のNATを設定しておかないと、設定していない側のパケットは宛先と応答の送信元IPが異なるため、破棄される
  • 動的NAT
    • 通信が発生したとき初めてNATテーブルにレコードが登録される
    • 両方向のNATを設定しておかないと、設定していない側のパケットは宛先と応答の送信元IPが異なるため、破棄される
  • NAPT
    • 通信が発生したとき初めてNATテーブルにレコードが登録される
    • 一方向のNATのため、外部から内部への通信はできない。

ルータの挙動

以下のようにPCとルータを設定する。

  • PC1
    • IP: 192.168.10.1
    • デフォルトゲートウェイ: 192.168.10.254(ルータのPC1側インターフェース)
  • PC2
    • IP: 172.16.10.1
    • デフォルトゲートウェイ: 172.16.10.254(ルータのPC2側インターフェース)
      ※ルータはインターフェースへのIP割当以外何もしていない
      このときのルータのルーティングテーブルは以下の通り。
R1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
C    192.168.10.0/24 is directly connected, FastEthernet0/0
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.10.0 is directly connected, FastEthernet0/1

直接接続されているネットワークのみ登録されている。
この状態で、PC1からPC2への通信は可能。

PC1> ping 172.16.10.1 -c 3
84 bytes from 172.16.10.1 icmp_seq=1 ttl=63 time=16.025 ms
84 bytes from 172.16.10.1 icmp_seq=2 ttl=63 time=18.017 ms
84 bytes from 172.16.10.1 icmp_seq=3 ttl=63 time=17.444 ms

ルータとPC2の間でパケットキャプチャしてみる。


エコー要求パケット(No.2)のIPは以下の通り

  • 送信元: PC1のIP
  • 宛先: PC2のIP
    ちなみに、PC1からPC2にtracerouteしたときの結果は以下。
    ルータのPC1側インターフェースを経由してPC2に届いているのがわかる
PC1> ping 172.16.10.1 -c 3 
84 bytes from 172.16.10.1 icmp_seq=1 ttl=63 time=29.479 ms
84 bytes from 172.16.10.1 icmp_seq=2 ttl=63 time=16.935 ms
84 bytes from 172.16.10.1 icmp_seq=3 ttl=63 time=17.112 ms
PC1> trace 172.16.10.1
trace to 172.16.10.1, 8 hops max, press Ctrl+C to stop
 1   192.168.10.254   9.760 ms  9.322 ms  9.759 ms
 2   *172.16.10.1   29.602 ms (ICMP type:3, code:3, Destination port unreachable)

静的NATの挙動

上記のルータに対して、NATを設定する。
PC1からの通信を、172.16.10.254としてSNATする。

R1(config)#ip nat inside source static 192.168.10.1 172.16.10.254
R1(config)#interface fastEthernet 0/0
R1(config-if)#ip nat inside
R1(config)#interface fastEthernet 0/1
R1(config-if)#ip nat outside

ルータとPC2の間でパケットキャプチャすると、確かに送信元IPが172.16.10.254に変わっている

参考までに、ルータとPC1の間のパケットは何も変わらない

このとき、ルータのNATテーブルは以下の通り。

R1#show ip nat translations 
Pro Inside global      Inside local       Outside local      Outside global
--- 172.16.10.254      192.168.10.1       ---                ---

では、PC2からPC1にpingを飛ばすとどうなるか

PC2> ping 192.168.10.1 -c 3
192.168.10.1 icmp_seq=1 timeout
192.168.10.1 icmp_seq=2 timeout
192.168.10.1 icmp_seq=3 timeout

すべてtimeoutになっている。これは、送信時の宛先IPと異なるIPからレスポンスが帰ってきた(=応答がSNATされた)から。

よって結果は、

  • ICMP要求: NATされない
  • ICMP応答: SNATされる

動的NATの挙動

以下のように、動的NATを設定する。
192.168.10.0/24からの通信を、172.16.10.96/29のIPに変換する。

R1(config)#ip nat pool DYN 172.16.10.97 172.16.10.102 netmask 255.255.255.248
R1(config)#access-list 1 permit 192.168.10.0 0.0.0.255
R1(config)#ip nat inside source list 1 pool DYN

R1(config)#interface fastEthernet 0/0
R1(config-if)#ip nat inside
R1(config-if)#exit

R1(config)#interface fastEthernet 0/1
R1(config-if)#ip nat outside
R1(config-if)#exit

R1#show ip nat statistics 
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Outside interfaces:
  FastEthernet0/1
Inside interfaces: 
  FastEthernet0/0
Hits: 0  Misses: 0
Expired translations: 0
Dynamic mappings:
-- Inside Source
[Id: 1] access-list 1 pool DYN refcount 0
 pool DYN: netmask 255.255.255.248
	start 172.16.10.97 end 172.16.10.102
	type generic, total addresses 6, allocated 0 (0%), misses 0

何の通信もしない場合、NATテーブルは空になる

R1#show ip nat translations

pingを打ち続けると、NATテーブルに変換内容が記載される

R1#show ip nat translations 
Pro Inside global      Inside local       Outside local      Outside global
--- 172.16.10.97       192.168.10.1       ---                ---

ルータとPC2の間でパケットキャプチャする

すると、Sourceが変換されていることがわかる。
NATテーブルの通り、192.168.10.1から172.16.10.97に変換されている。

PC2からPC1にpingを打ってみる。

PC2> ping 192.168.10.1 -c 3

192.168.10.1 icmp_seq=1 timeout
192.168.10.1 icmp_seq=2 timeout
192.168.10.1 icmp_seq=3 timeout

すべてtimeoutになっている。

これは、送信時の宛先IPと異なるIPからレスポンスが帰ってきた(=応答がSNATされた)から。
よって結果は、

  • ICMP要求: NATされない
  • ICMP応答: SNATされる

NAPTの挙動

NAPTを設定する

R1(config)#access-list 1 permit 192.168.10.0 0.0.0.255
R1(config)#ip nat inside source list 1 interface FastEthernet 0/0 overload

R1(config)#interface fastEthernet 0/0
R1(config-if)#ip nat inside             

R1(config)#interface fastEthernet 0/1
R1(config-if)#ip nat outside

このときも、通信が発生するまでは特にNATテーブルには何も記載されない。
PC1からPC2のTCP/8080にpingを打ってみる

PC1> ping 172.16.10.1 -P 6 -p 8080 -c 100

Connect   8080@172.16.10.1 seq=1 ttl=63 time=18.075 ms
SendData  8080@172.16.10.1 seq=1 ttl=63 time=20.197 ms
Close     8080@172.16.10.1 seq=1 ttl=63 time=30.726 ms

NATテーブルは以下のようになる。

R1#show ip nat translations 
Pro Inside global      Inside local       Outside local      Outside global
tcp 192.168.10.254:18828 192.168.10.1:18828 172.16.10.1:8080 172.16.10.1:8080
tcp 192.168.10.254:29956 192.168.10.1:29956 172.16.10.1:8080 172.16.10.1:8080

さらに、NAPTの効果を感じるために、PC3を追加する。

このとき、PC1とPC3の送信元、宛先Portを揃えて、以下の条件でTCP接続する。

  • PC1(192.168.10.1:20000)→PC2(172.16.10.1:8080)
  • PC3(192.168.10.3:20000)→PC2(172.16.10.1:8080)

TCP接続

PC1> ping 172.16.10.1 -P 6 -p 8080 -s 20000 -c 5
PC3> ping 172.16.10.1 -P 6 -p 8080 -s 20000 -c 5

このとき、NATテーブルは以下の通り。

R1#show ip nat translations 
Pro Inside global      Inside local       Outside local      Outside global
tcp 192.168.10.254:1024 192.168.10.3:20000 172.16.10.1:8080  172.16.10.1:8080
tcp 192.168.10.254:20000 192.168.10.1:20000 172.16.10.1:8080 172.16.10.1:8080

これらを、Switch1とルータ、ルータとPC2の間でパケットキャプチャしてみる。

Switch1→ルータ

ルータ→PC2

NATテーブルの通り、PC1のPortは変換されず、PC3のPortは20000から1024に変換されることがわかった。

そして、PC2→PC1への通信は失敗する。戻りのパケットのIPが異なるから。
NAPTは一方向NATだから期待通り。

PC2> ping 192.168.10.1 -P 6 -p 8080 -s 2000 -c 1

Connect   8080@192.168.10.1 timeout

確かに、戻りのパケットのIPがルータのIPになっているからパケットは破棄される。

Discussion