「DirectConnect」でAWSのSG設定もルートテーブル設定も完璧だったのに「特定の拠点」から「特定のEC2」だけ繋がらなかった話
こんにちはこぐまです。
先月末くらいに発生した出来事を備忘録として。
ふしぎなつながらない事象
DirectConnectで接続しているサービス提供先のとある拠点からこんな問い合わせがありました。
「なんか、サーバAにはつながるんだけどサーバBにはつながらないんだよね。」
サーバAとサーバBは同一AWSアカウント、同一VPC、同一AZ内に存在し、まったく同じセキュリティグループをアタッチしています。
なんで、普通に考えれば、（サーバAにつながるのであれば）サーバBにつながらないことはあまり考えられないですよね。
あるとすればサーバBのOSの設定としてFWなどで制限しているか・・ですが、そんなこともないようです。
そしてさらに不思議なことに、この拠点とは別の拠点（こちらもDirectConnectで接続している）から試行してみると、
「いや、こっちの拠点からはサーバAもBもつながるんだよ～」
とのこと。
このヒアリング結果から「んーーー？？？」となっていろいろ調べてみました。
答えは意外なところに。。
実はサーバBには特定のアプリをインストールしていました。
そのアプリはGUIでインストールする必要があったので、
以下のパッケージをインストールしていました。
sudo yum groupinstall -y "gnome-desktop"じつはこれが原因でした。
これをインストールすると、Linuxの「KVM」という仮想化基盤に必要な「libvirtd」というデーモンが作成されます。
そして、このlibvirtdが有効化されていると、「サーバB」と「サーバBの上にこれから生み出されるゲストOS」との橋渡しとなる仮想ブリッジ（virbr0）が作成されます。この仮想ブリッジのIPがデフォルトで「192.168.122.1」なのです。そして「サーバBの上につくられるゲストOS」のセグメントはデフォルトで「192.168.122.0/24」となります。
つまりどういうことかというと・・
１．このサーバB上で仮想化基盤が有効となっている（このサーバB上でゲストOSを作ることができるような状態となっている。）
２．ゲストOSと通信するために「192.168.122.1」という仮想ブリッジ（virbr0）が作られる。
３．ゲストOSの存在するセグメントは「192.168.122.0/24」なので、
「192.168.122.0/24」向けの通信はこの仮想ブリッジ（virbr0）に向けるようなルーティングが作られる。
そして、実はこのセグメントは、最初につながらないと言っていた
拠点のセグメントだったというわけです・・。
つまり、拠点からこのサーバBまでは届くんだけれど、戻りの通信として、向き先が存在しないゲストOS上に向いてしまうということでした。
正常に通信できる拠点は、このセグメントではないので、この不要なルーティングの影響を受けずに通信できていたというわけですね。
もちろんGUIでインストールするために必要だっただけなので、ゲストOSなんて作るつもりはありません。仮想ブリッジ向けのルーティングを消して正常に疎通が取れることを確認後、再起動しても再び仮想ブリッジとルーティングが作成されないように、libvirtd自体を無効化しました。
１．不要な仮想ブリッジ向けのルートを無効化
sudo ip route del 192.168.122.0/24
２．libvirtd自体を無効化
systemctl disable libvirtd なお、libvirtdのデフォルトの設定として上記のようなセグメントや仮想ブリッジIPが設定されているようなので、DirectConnect利用かつ、ゲストOSと通信をしたい場合は、かぶらないようにゲストOSのセグメントを調整することもできます。
戻りの道案内が明後日の方向を向いていた！といういい勉強になりました！
読んで下さってありがとうございました！
ご参考