AWSにルータインスタンスを構築する際の注意事項

はじめに

AWSにはCiscoルータのAMIが用意されています。
これを使ってipsecを使ったVPNを構築し拠点間通信のテストを行った際、
クラウド環境ならではのポイントにドハマリしたのでメモとして残しておきます。

構築にあたって参考にしたページはこちら
インフラエンジニア向け、Cisco CSR1000V on AWS を使ってみる
https://dev.classmethod.jp/articles/cisco-csr1000v-on-aws/

設定等は割愛しますが参考ページを見ていただければルータの設定方法等はわかるかと思います（時間があれば後で追記していきます）。
オンプレ環境では筐体用意してケーブルでつないであげればOKですが、クラウド環境ではそのイメージで構築していると痛い目にあうところがポイントです。
（参考にしたページを良く読めという話でもありますが、、、）

システム構成

VPCにサブネットを2つ用意しWindowsサーバ、Ciscoルータのインスタンスを構築します。
※Ciscoルータインスタンスはネットワークインターフェースを2つ用意します。
※一つのAvailability Zoneに2つのサブネットを作成しました。

この構成でVPN越しにプライベートネットワーク同士が通信できるか確認しました。

何でハマったか

ルータ同士のVPN接続、AWSにおいてWindowsサーバとルータ間のpingは問題なく疎通できましたが、
WindowsサーバからVPNを経由した拠点側のクライアントPCに向けてのpingが落ちます。

C:\Users\Administrator>ping 192.168.100.201

Pinging 192.168.100.201 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.100.201:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

切り分けその1

ルータ上で送信元アドレス指定で拠点側のクライアントへpingを打つときちんとレスポンスが帰ってきます。
つまりAWS側、拠点側VPNの設定、拠点側のルーティングは問題ありません。

VPNRouter#ping 192.168.100.101 source 192.168.201.111
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.101, timeout is 2 seconds:
Packet sent with a source address of 192.168.201.111 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/4 ms

切り分けその2

Windowsサーバ側のルーティングの問題か？と思い確認しましたが
デフォルトルートはルータのLAN側（サーバ側）インタフェースを指しています。
つまり拠点側クライアントPC（192.168.100.201）宛のパケットはVPNルータを経由するはず。

C:\Users\Administrator>route print
===========================================================================
Interface List
  4...06 59 4b 8d 94 94 ......AWS PV Network Device #0
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0  192.168.201.111  192.168.201.113    281
    122.26.22.129  255.255.255.255    192.168.201.1  192.168.201.113     26
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  169.254.169.123  255.255.255.255    192.168.201.1  192.168.201.113     50
  169.254.169.249  255.255.255.255    192.168.201.1  192.168.201.113     50
以下省略

( ﾟДﾟ)ﾊｧ?わけがわからん？？？

切り分けその3

トレースを打ってみると…

C:\Users\Administrator>tracert -d 192.168.100.201

Tracing route to 192.168.100.201 over a maximum of 30 hops

  1     *        *        *     Request timed out.
  2     *        *        *     Request timed out.
  3     *     ^C

あれれ、一発目からタイムアウトしている。
おかしい、一発目はゲートウェイアドレスが帰ってくるはずなのになんでタイムアウトするの？？？
セキュリティーグループは全てのトラフィック許可しているのにルータとサーバ間で通信できていない…
Windowsサーバ～ルータ間のpingはOKなのでセキュリティグループではなさそう。
なんだ？何か見落としていることあるのか？

原因

わけがわからなくなり少しふて寝したあとに今回のテストで参考にしたページ（下記参照）をよくよく見てみると…

(2)その際、サーバ側ネットワーク用のインターフェイスを追加します。
マシンが作成できたら、Netwrok Interface で、サーバ側ネットワーク用のインターフェイスの「Source/Dest. Check」を無効にします。」

これはやってなかったな…

ルータのサーバ側に接続するためのインターフェースで「送信元/送信先の変更チェック」を無効にしてみたところ…

C:\Users\Administrator>ping 192.168.100.201

Pinging 192.168.100.201 with 32 bytes of data:
Reply from 192.168.100.201: bytes=32 time<1ms TTL=255
Reply from 192.168.100.201: bytes=32 time<1ms TTL=255
Reply from 192.168.100.201: bytes=32 time<1ms TTL=255
Reply from 192.168.100.201: bytes=32 time<1ms TTL=255

Ping statistics for 192.168.100.201:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

pingが帰ってきた＼(^o^)／

ネットワークインターフェースの「送信元/送信先の変更チェック」って何？

AWSの公式ページ：送信元/送信先チェックを無効にする
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck

EC2 インスタンスは、送信元/送信先チェックをデフォルトで実行します。つまり、そのインスタンスは、
そのインスタンスが送受信する任意のトラフィックの送信元または送信先である必要があります。
しかし、NAT インスタンスは、送信元または送信先がそのインスタンスでないときにも、トラフィックを送受信できなければなりません。
したがって、NAT インスタンスでは送信元/送信先チェックを無効にする必要があります。

こちらの記事を読んでもいまいちピンと来ませんでしたが、

AWSのインスタンスでパケットフォワーディングできない
https://sugarsugar.conf.jp/aws%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9%E3%81%A7%E3%83%91%E3%82%B1%E3%83%83%E3%83%88%E3%83%95%E3%82%A9%E3%83%AF%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%81%A7

AWSインスタンスのネットワークインタフェースはデフォルトとして、自分のIPアドレス以外へのパケットを破棄します。
この設定は [EC2] > [インスタンス]で対象のインスタンスを右クリックして、「送信元/送信先の変更チェック」をクリック、
「無効」にすることで自分のIPアドレス以外も受け付け、ルーティングに従ってパケットフォワーディングされます。

こちらのページで理解できました。
知らんかったわ。

参考ページまとめ

インフラエンジニア向け、Cisco CSR1000V on AWS を使ってみる
https://dev.classmethod.jp/articles/cisco-csr1000v-on-aws/
AWSのインスタンスでパケットフォワーディングできない
https://sugarsugar.conf.jp/aws%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9%E3%81%A7%E3%83%91%E3%82%B1%E3%83%83%E3%83%88%E3%83%95%E3%82%A9%E3%83%AF%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%81%A7
送信元/送信先チェックを無効にする
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck