WindowsのEC2インスタンスのルートテーブルを編集する際に、誤った設定をしてしまいインスタンスに疎通できなくなってしまうことがあるかと思います。
そのような場合の対処法について、re:Postでは下記2通りの方法を説明します。
- EC2 シリアルコンソールを使用する
- 一時的にENIをもう一つアタッチする
本記事では一時的にENIをもう一つアタッチする方法に着目して説明します。
ドキュメント
今回試す環境
- Windows Server 2022(ami-0987eed561fe06332 Windows_Server-2022-English-Full-Base-2024.07.10)
- EC2Launch 2.0.1948.0
ルートテーブルを変更して疎通できなくしてみる
まずはルートテーブルの設定を削除してインスタンスに対して疎通できなくしてみます。
今回、構成したWindows環境のデプロイされているサブネットは10.10.10.0/24となっており、EC2インスタンスのローカルIPアドレスは10.10.10.42/32としています。
インスタンスにログインし、ルートテーブルを確認すると、0.0.0.0/0の向け先がVPCルーター（10.10.10.1/32）になっている事が確認できます。
（サブネットを作成すると、先頭から5個のIPアドレスはAWS側が予約していて、VPCルーターは先頭から2番目の10.10.10.1/32になる）
このルート削除するとインスタンスに疎通できなくなります。
下記コマンドで設定を削除します。
Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Remove-NetRoute
実行するとルートが削除されRDPなどつながらなくなります。
一時的なENIをもう一つアタッチして復旧してみる
元々のローカルIPアドレス 10.10.10.42/32 は疎通できなくなったため。
新しいENIを作成してインスタンスにアタッチします。
今回、10.10.10.0/24のサブネットを利用しているため、この範囲内となる10.10.10.90/32のENIを作成し、疎通できなくなったインスタンスにアタッチします。
Network Interfaceを作成して、適宜必要なセキュリティグループを割り当てます。
作成したENIを疎通できなくなっているインスタンスにアタッチします。
EC2インスタンスにENIが2枚アタッチされました。
作成したENIに紐づくIPアドレスに対して、RDPで疎通できるか確認してみます。
認証画面がでてきたので疎通できているようです。
ログインしてルートテーブルを確認してみます。
Get-NetRouteで確認すると、削除してVPCルーター向けの設定が復活しています。
また先ほどルートを確認した際に比べてInterfaceIndexの番号が増えているのがわかります。（画像ではもともとあった3番だけではなく、12番が増えている）
Get-NetIPAddress | select InterfaceIndex, IPAddress
でそれぞれを確認してみる、12番が今回アタッチした10.10.10.90だということがわかります。
このルートテーブルをみていると気付くかもしれませんが、この時点で10.10.10.42の削除したルート設定も復旧されており、10.10.10.42でもアクセスできるようになっています。
ルートテーブルが復旧したため、一時的に作成したENIをデタッチして削除します。
なぜルートテーブルが更新されたのか
Windowsのイベントログから理由をさぐってみます。
システムログを確認すると2枚目のENIをアタッチした時間ごろにアダプターのリセットが走っているようです。
これによりルートテーブルがリフレッシュされて復旧されているように思われます。
総評
AWSでネットワーク周りの変更時に、設定の不備から疎通できなくなってしまう。
などということは無いには越したことはありませんが、こういう復旧方法についても理解しておく事で、いざという場合に備えたい所です。