勘違いから学んだポートの疎通確認の基礎
こんにちは、ようへいです。
アプリケーション開発一筋で約20年。
2024年はAWS専任として、日々成長を感じながら悪戦苦闘しています。
今日の記事は、ポートの疎通確認の基礎について。
セキュリティグループに空けた穴について、検証目的で疎通確認をしたい。
そんなの簡単でしょ、と思いつつやってみたらハマってしまいました。
インフラ部分はまるっきり素人な自分の勘違いと、「そうなんだ！」と感じた気づき、理解したことのアウトプットです。
構成図
Jump Server（踏み台サーバ）と、その先にあるTarget InstanceのEC2インスタンスがあります。
Target Instanceに、Jump Serverからのポート22（SSH）の通信を許可するようにセキュリティグループを設定しました。
検証したいこと
Target InstanceにJump Serverからのポート22の通信を許可したので、通信がTarget Instanceのポート22に辿り着くことを確認します。
やってみたこととその結果
Jump Server→Target Instanceのポート22への疎通確認として、Jump Serverからncコマンドを実行。
宛先はTarget InstanceのプライベートIPアドレスです。
nc -vz 10.10.1.1 22セキュリティグループに穴を開けたんだから、自明の理でしょ、と思っていたところ、結果は次の通り。
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Connection refused.接続拒否！
こんなところで躓くとは。
ネットワークACLやセキュリティグループは穴が空くほど確認し、問題ないことを確認しました。
疎通しない原因
これの調査、理解に時間を費やし、インフラの基礎が出来上がっていないことを痛感しました。
辿り着いた結論は
Target InstanceでSSHサービスが起動されてなかったこと。
これが原因でした。
だから、ポート22が疎通しなかった・・・・。
勘違い内容と正しい理解
勘違い内容
セキュリティグループに穴を空ければ疎通するはずだ、と理解していたこと。
その背景には、OS的にはポートは全て空いていて、セキュリティグループでふさいでいる、と間違った認識をしていたこと。
正しい理解
疎通するには、以下の2つの条件が揃う必要があります。
Target Instance側で、対象ポートをListenしているアプリがいる
Target Instance側のセキュリティグループに、対象ポートが許可されている
今回で言えば、ポート22を許可するルールはあるが、ポート22をListenするSSHサービスが動いていなくてポートが塞がっており、疎通できませんでした。
つまり、家（Listenされているポート）があって、そこへの道路（通信の許可ルール）があること。
どちらかが欠けていると、人（通信）は辿り着かない。
これの理解が必要だったんですね。
この点の理解が無かったため、時間を要しました。
SSHサービスを起動した結果
nc -vz 10.10.1.1 22
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Connected to 10.10.1.1:22.
Ncat: 0 bytes sent, 0 bytes received in 0.08 seconds.無事に疎通することができました。
Target InstanceのパブリックIPでは疎通しなかった
nc -vz 30.1.1.1 22
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Connection refused.これも知っていたら、当たり前や！ってなる話なのですが、自分的には発見なのでアウトプットします。
プライベートIPを指定した場合は、上述の通り疎通しました。
これはAWSのネットワーク内での通信なので疎通します。
（多分、VPCがピアリング接続されてるんだと思われる）
もう少し掘り下げると
同一ネットワーク内の通信では、Target Instanceから見たアクセス元IPアドレスは、セキュリティグループで許可したJump ServerのプライベートIPアドレスだからです。
なぜパブリックIPでは疎通しないのか
パブリックIPを指定した場合、通信はインターネットを経由することになります。
（ここが知らなかった。そうなのか、と。）
通信がインターネットに出てしまうと、Target Instanceから見たアクセス元IPアドレスは、Jump ServerのパブリックIPに変換され、そのIPアドレスはTarget Instance側のセキュリティグループで許可されていないため接続が破棄されてしまい、疎通しないことになります。
さいごに
AWSばかり勉強していたことで、AWSはそれなりに力が付いてきましたが、そもそもインフラの知見が少ないので、そこが足枷になりました。
AWSの勉強もそうですが、インフラの勉強もセットでやらなきゃいけないなぁ、という課題に出会えた1日でした。
（また、生産性が良くないねぇ、なんて小言を言われるんだろうなぁ・・・）
この記事が気に入ったらサポートをしてみませんか？