Q&A
> ポートの開放などは調べてやっていて、インスタンスのセキュリティの詳細画面でもhttpとhttpsは緑のチェックが入っていて問題はないように見えます。
具体的にはどこで何を設定しましたか？
セキュリティグループの設定はやったんでしょうか。
前提・実現したいこと
AWSでEC2を立ち上げたところオープンアドレスが開けないです。ポートの開放などは調べてやっていて、インスタンスのセキュリティの詳細画面でもhttpとhttpsは緑のチェックが入っていて問題はないように見えます。
参考にしたサイトです。
https://dev.classmethod.jp/articles/creation_vpc_ec2_for_beginner_1/
https://dev.classmethod.jp/articles/creation_vpc_ec2_for_beginner_2/
VPCのCIDRは10.0.0.0/17
サブネットは
AZ:1a, CIDR:10.0.1.0/24 と
AZ:1c, CIDR:10.0.2.0/24 です。（どちらもパブリックで使うつもり？です。）
EC2の方では上の1aの方のサブネットIDが表示されています。
EC2をSSH接続してApacheをインストールして起動しています。起動の確認もできています。
ステータスチェック（EC2のを選択して画面下に出てくるやつのメニューバーにあるやつです。）も合格と表示されています。
また、macのファイヤウォールを無しにしたり、AVASTのウェブシールドを無効にしたりと言ったことも調べたら出てきたので試しました。
発生している問題・エラーメッセージ
ERR_CONNECTION_TIMED_OUT このサイトにアクセスできませんec2-＊＊-＊＊＊-＊＊＊-＊＊＊.ap-northeast-1.compute.amazonaws.com からの応答時間が長すぎます。
Chromeです。
試したこと
自分がネットで「AWS オープンアドレス開けない」、「AWS 応答時間がながすぎる」
補足情報（FW/ツールのバージョンなど）
追記
画像を送ります。参考にしてください。情報が足りなかったらまた教えて下さい。
サブネット２のRTBとACLは１と同じです。
セキュリティグループ２はあとで作るAWS RDS(MySQL)に使う予定です。
はい、セキュリティグループのインバウンドルールの設定をしました。
HTTP(80) 0.0.0.0/0
HTTPS(443) 0.0.0.0/0
SSH(22) マイIP
カスタムTCP(8000) マイIP（Djangoが8000番を使うらしいので）
こんな感じです。
VPCはおそらく新規作成したんだと思いますが、ルートテーブルの設定はどうなっていますか
ルートテーブルは２つのサブネットと関連付けられていて、VPCの自分がつくったものです。
ルートは
10.0.0.0/17 local アクティブ
0.0.0.0/0 igw-**** アクティブ
インターネットゲートウェイは自分の作ったVPCにアタッチされているものです。
念の為ですが、インスタンスは自分で作ったVPC内に作成していますか？
はい、EC2の詳細のところには自分で作ったVPCのIDが書かれています。
今度はオープンアドレスを開こうとしたら、接続が拒否されるようになってしまいました。設定は変更していません。
上のコメントは大学から開こうとした時に起こったもので、自分の携帯でデザリングしたら今まで通りのTIMED OUTが出たので大学のWi-Fiの問題だと思います。紛らわしかったので今削除リクエストを送っています。何の話をしているかわからない場合は削除後だと思われま
回答2件
0
明確な回答ではないですが、調査の方法として先日AWSはReachability Analyzerというサービスを発表しました。
【速報】VPC内の接続性テストとトラブルシューティングを簡単にする！VPC Reachability Analyzerが発表されました！ #reinvent
こちらを使ってどこで通信が詰まってるかを可視化すると原因調査に大いに役立つと思います。
ただ、1回の分析で0.1USDの課金が発生するのでご注意ください。
今回のケースだとVPCのインターネットゲートウェイから該当インスタンスまで80番ポートでの接続を確認すれば良さそうです。
分析してその中に問題が発見できなかった場合、AWSの外に問題がある可能性が高そうです。
投稿2021/10/18 06:27
総合スコア7588
80番ポートと443番ポートどちらも問題がありませんでした。到達可能と表示されました。
AWSの外の問題だとすると何が考えられますかね。
Apacheを使っていたとして443ポートはListenしているんでしょうか。
443ポートでListenしてないにも関わらずhttpsで接続しようとしていたりはしませんか？
（Apacheはデフォルトだと80番ポートしかListenしません）
外というと自分が接続しているネットワークや、AWSに到達するまでの経路上のどこかに問題があるとしか言えません。
tracerouteなどで確かめてみてください。
返信遅れてすみません。少し忙しくて。
Apacheの443ポートがListenしているのか調べようと思います。
AWSのオープンアドレスがhttps://[パブリックIPアドレス]で開くので443ポートをListenさせる必要がありそうです。
80番がListenしているのは確認して(ss, netstatで)、http:// パブリックIPアドレス で開くと、同じようにTimed outが出るので、traceroute -T -p 80 パブリックIPアドレス をしたところ、***と！Xが返ってきてダメでした。
調べたところ443番ポートは自己署名証明書？が必要みたいで大変そうなのですが、80番がダメな状態のまま443をListenさせてもうまくいく気がしないのですが、まずは、80番ポートでも開けるようにしたほうが良いと思いますか？
また、!Xは途中のNW機器がACLによりその通信を拒否していることが多いです。と調べるとあるのですが、自分の場合NW機器は家のWi-Fi、ACLはAWSのネットワークACLという認識であってますか。
沢山質問してしまって申し訳ないのですが、よろしくお願いします。
tracerouteの結果を、一部マスクしたものでいいので貼ってください。
ここでいうACLはAWSのネットワークACLを含む、経路中にある全てのNW機器のACLです。
アドレスにたどり着くまでには自宅のNW機器から通信が出た後も様々な機器を経由します。
tracerouteの結果を見てほしいと言ったのはその経路中のどこで問題が発生しているかを確認したいからです。
traceroute to ＊＊.＊＊＊.＊＊＊.＊＊＊ (＊＊.＊＊＊.＊＊＊.＊＊＊), 30 hops max, 60 byte packets
1 * * *
2 ec2-＊＊.＊＊＊.＊＊＊.＊＊＊.ap-northeast-1.compute.amazonaws.com (＊＊.＊＊＊.＊＊＊.＊＊＊) 0.616 ms !X 0.675 ms !X 0.625 ms !X
マスクしてあるのは全て同じで、EC2のパブリックIPアドレスです。
よろしくお願いします。
経路中にほとんど何もないのが驚きですね…。
でもSSHはできるんですよね？
Reachability Analyzerの結果を文字だけの記載じゃなくて、なにを設定した結果うまく行ったのかわかるように貼ってください（IPとかはマスクしてください。）
SSH接続はできます。ssかnetstatでもESTABLISHEDとなっていました。
この返信には画像は貼れないみたいです。また、なにを設定した結果うまくいったのかわかるというのは、Reachability Analyzerの結果の画面ではわからないように思います。送信元と送信先の間にどこを通ったのかがわかるだけです。一応書いておくと、
インターネットゲートウェイ → ネットワークACL → セキュリティグループ → ネットワークインターフェイス → EC2インスタンス という感じです。
インターネットゲートウェイは自分で作ったVPCにアタッチされているもの
ネットワークACLのインバウンドルールはデフォルトのままで、100ですべてAllow、＊ですべてDenyです。
セキュリティグループは以前送ったものでインスタンスと紐付いているもの
ネットワークインターフェイスはin-useでVPCは自作のもの, subnetはインスタンスに紐付いているやつ, セキュリティグループも、インスタンスは自分で作ったやつです。
ここではなく本文に追記してください。
言葉での説明は不正確になりがちなので、できる限りスクリーンショットなどで実際の設定値を貼ってください。
apacheの起動の確認も、どのように確認したかを書いてください。
具体的にはsystemctl status httpdの結果ですね。
追記しました。
見た感じAWS上の設定には問題がなさそうなので、やはりtracerouteの結果を考えると自分が今接続しているネットワークに問題があるかもしれません。
接続が拒否されました、であればリクエストは届いてると思われますが、タイムアウトということでそういうわけではなさそうなので。
ちなみにここからは問題とあまり関係ありませんが、
プライベートIPを隠す意味はあまりないです（どうせVPCの中だけで使うものなので）
また、セキュリティグループ2について、RDSに使うのであればHTTPやHTTPSではなく今回であればMySQLのポートを、接続元（今回だとEC2インスタンスですかね）を含むCIDRブロックか、またはセキュリティグループで許可しましょう。
家のWi-Fiは低速で良いものではなさそうなので、試しに自分の携帯(mineoのdocomo回線)をデザリングしてhttp://パブリックIPを開いたところ[504] Gateway Timeoutと今までとは少し違ったエラーになりました。ただTimeoutであることには変わりないのかなとは思いました。何か参考になればと思いコメントしました。ちなみにtracerouteの結果はWi-Fiと変わりませんでした。
セキュリティグループ２についてですが、RDSを作る際にそのように設定する予定でいました。教えていただきありがとうございます。
Apacheはデフォルト以外に何かカスタマイズしましたか？
よく考えたらSSHはできているので特定のポートの通信だけ届いてないようですね。
注意すべきは（443は多分Listenしてないので）httpsではなくhttpで接続することぐらいですが、見た感じAWS内部の設定には問題がないので謎です。
オープンアドレスをクリックして開くとhttpsで開いてしまうのでご注意を。
sudo systemctl enable httpd.serviceを設定しました。
また、バージョンはServer version: Apache/2.4.51 ()です。
http://で接続して、保護されていない通信とも表示されているので、そこは大丈夫だと思います。
設定ファイルは何も変えてませんか？
何も変えてないならデフォルトのままですね。
そうするといよいよ謎ですね。ネットワーク的に問題がなければ接続できるはずですが…。
さすがにないとは思いますが、プライベートIPに接続しようとはしてませんよね？
設定ファイルは一度いじりましたが、そのファイルは削除したのでデフォルトのままです。
もちろんパブリック IPv4 アドレスに接続しています。
パブリック IPv4 DNSも同じように[504]Gateway Timeoutです。
Apache以外の方法を探したほうが良いですかね。
なんとか自己解決できました。色々と設定などを見ていただきありがとうございました。
iptablesの設定で解決したということは、デフォルトのAmazon Linux2ではオンになってないiptablesをどこかでオンにしたということでしょうか…？
ポリシー次第ですが、セキュリティグループがあるのでそちらのほうでコントロールすることを推奨します。
AWSのサイト(https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-instance-hosting-unresponsive-website/)でも同じことが提案されているのですが、ポリシーに反する可能性はあるのでしょうか。
これは推奨しているのではなくて、トラブルシュートの手順ですよね。
iptables（AmazonLinux2だとfirewalld)が実行されてるか確認して、実行されてたら必要なポートが許可されているか確認する、と書いてあるだけかと。
確認だけでなく、「次のコマンドを実行して、ポート 80 が受信 HTTP 接続リクエストを受け入れるようにします。」と設定を変更しているように見えるのですが。
firewalldの方も「ファイアウォールが実行されている場合は、次のコマンドを実行して、ポート 80 および 443 での接続を許可するように設定します。」とあるのですが。
自分のはAmazon Linux2なのにiptablesの設定をして接続できたのは謎ですが、どちらも設定を変更しているように見えます。
書いたとおりで、「iptablesやfirewalldが実行されている場合は」許可する設定を追加するというだけの話で何ら矛盾はないです。
そりゃ、許可されてるか確認して許可されてなかったらそのままするんじゃ、何のために確認したのかわかりませんよね。
今試しに素のAmazon Linux2のインスタンスをx86とArm両方で作ってみてApacheをインストールしてアクセスできるか確かめてみましたが、いずれも特に何もせずアクセスが可能でした。
なのでどこかでiptablesを有効化したのではないでしょうか。
素のAmazon Linux2を使っているのではなく誰かが作ったAMIを使っているのであればそのAMIが原因です。
firewalldもrunnningだったのですが、iptablesもfirewalldもいつ入れたのかは把握できてないです。
AMIはVPCを初めて設定した時にサブネットのCIDRを適当にしてしまったので、それを直す時に自分が一度作ったEC2をもう一度作る時にイメージを作成しました。
iptablesをsudo yum remove iptablesしたところ、iptablesとfirewalld両方削除されたみたいで、コマンドが見つかりませんとターミナルで表示されます。Apacheのテストページは問題なく表示されるのでこれでデプロイに進んでいいでしょうか。
何かをインストールするときに一緒に入れてしまった可能性が高そうですね。
別に自分は上司でも決済者でも承認者でもなんでもないので、好きなように進めて何ら問題はありません。
恐らくそうだと思います。
わかりました。ありがとうございました。
0
自己解決
このサイトを参考にしました。
https://www.rem-system.com/ec2-apache-install/
この中のiptablesの設定を見て、httpの利用するTCPポートの80番を許可するようにルールを追加しました。
投稿2021/10/29 16:02
総合スコア4
あなたの回答
tips
プレビュー
