"ドメイン名".com で繋げようとしても繋がらない...
その後、Route53にてWEBサーバーのグローバルIPでも繋いでみましたが
このサイトにアクセス出来ませんと表示されました。
それと、朝CLIでログインが出来なかった為
bastionセキュリティーグループのインバインドを
再度マイIPで変更してしまいました
その後、CLIからは接続できるようになったのですが、こちらに原因があるかも知れません
以下は簡単な図です。
-------
[インターネット]→[ALB(ロードバランサー)]→Webサーバ
-------
質問されていた内容から判断しますと以下点が原因である可能性があると思われます。
1
>htttps://"ドメイン名".com で繋げようとしても繋がらないです
→
・Route53にALBのレコード登録がされていない
ALBをRoute53へ登録する際、IPアドレスではなくALIAS名(例:dualstack.alb-ロードバランサー名.ap-northeast-1.elb.amazonaws.com)で登録する必要があります。
この時は、ドメイン名とALBのALIAS名(例:dualstack.alb-ロードバランサー名.ap-northeast-1.elb.amazonaws.com)です。
また、Webサーバへドメイン名でアクセスする際、WebサーバのグローバルIPアドレスをRoute53に登録する必要があります。
この時はドメイン名とグローバルIPアドレスです。
・セキュリティグループの設定
ALBにもセキュリティグループの設定が必要です。httpsでのアクセスが必要な場合、
TCP443でのアクセス許可、httpでのアクセスが必要な場合、TCP80でのアクセス許可が必要です。
また、同様にWebサーバへのアクセスもセキュリティグループの設定が必要です。
>CLIを使い、WEBサーバーから、アクセスログを
>tail -f /var/log/httpd/access_log で拾うと
>
>2行目に、
>"GET /favicon.ico HTTP/1.1" 404 209 "http://18.178.186.129/"
>と書かれており、ページが見つからない状態だとわかりました
>
>また、ロードバランサーのモニタリングで確認すると
>リクエスト自体はされている事がわかりました。
>
>ロードバランサーまでは、接続が出来ていると言う事でしょうか?
→
リクエスト数(カウント)でしょうか。ここの数が1以上になっていればロードバランサーまでの接続ができている
ということになります。ただし、その先のWebサーバに関してはApacheのアクセスログで判断します。
ついでに以下のコマンドで実行してみましたところ、"http://18.178.186.129/"
へのhttp(TCP80)へのアクセスはできていることは確認しました。これはWebサーバなのでしょうか。それとも
メールサーバなのでしょうか。
※コマンドは以下のurlに記載しています。
https://docs.google.com/document/d/1FVxQQ0-i6h_xUXEqzqAtoL4yodgFT-hLeex9RRXsWNw/edit?usp=sharing
>また、ターゲットグループを確認すると
>
>「これらのいずれのアベイラビリティーゾーンにも、正常なターゲットは含まれていません。リクエストはすべてのターゲットにルーティング中です。」
>
>と表示されており
>ステータス : unhealthy
>説明 : Health checks failed with these codes: [504]
>との表記もありました、この事踏まえて
→
・ALB→Webサーバへの通信許可の設定
セキュリティグループの設定でALBからEC2への通信許可(TCP80)の設定はされていますでしょうか。
通信許可がされているかどうかご確認いただけますでしょうか。
4
>インスタンスの状態は、runningで
>CLIからは、接続が出来ているので
>
>セキュリティーで弾かれてるのでしょうか??
>また、グローバルIPも現在bastionサーバーとWEBサーバーの二つに使っている状態なので
>そこでしょうか??
→
CLIからの接続が出来ている点から考えますと、BastionサーバからWebサーバへのSSH接続は出来ていると思います。
今回の焦点はインターネットからWebサーバへのアクセスが出来ていないという状況かと思いますので、
セキュリティグループの設定も一つの要因でもあります。ただし、これだけでないこともありますので
一度、WebサーバをALBから切り離して以下の順で切り分けることをおすすめします。つまり、すべてバラバラにした状態で切り分けるというやり方です。
また、イメージがつかみにくい場合、今回のレッスンであります構成図も併せて参照することをおすすめします。
1.インターネットからWebサーバへTCP80でのアクセス(グローバルIPアドレスでのアクセスとDNS名でのアクセス両方)が可能か。
アクセス可能
→
TCP80でのアクセスが可能。
アクセスできない
→
"http://IP Address"でのアクセスは可能か。できない場合はTCP80でアクセスできるようにセキュリティグループの設定変更をする。
"http://Domain Name.com"でのアクセスは可能か。できない場合はRoute53でWebサーバのグローバルIPアドレスとドメイン名のレコードを登録する。
Route53でドメイン登録後、digコマンド(※ dig ドメイン名 A)を実行し、「ANSWER SECTION」にWebサーバのグローバルIPアドレス登録されているかどうか確認する。
2.項番1で問題ないことを確認したら、ALBのターゲットグループに紐づける。
紐づけた後、ターゲットグループのタブ「ターゲット」ステータスを確認する。
[healthy]の場合
ALB→Webサーバとの通信は問題なし。
[unhealthy]の場合
ALB→Webサーバとの通信許可設定(TCP80)がされているかどうか確認する。
3.項番2で問題ないことを確認したら、以下を実施する。
・Route53でAレコードの設定
項番1で実施した、WebサーバのグローバルIPアドレスとドメイン名のレコードを登録から、ALBとドメイン名へ変更する。
ALBをRoute53へ登録する際、IPアドレスではなくALIAS名(例:dualstack.alb-ロードバランサー名.ap-northeast-1.elb.amazonaws.com)で登録する。
Route53でドメイン登録後、digコマンド(※ dig ドメイン名 A)を実行し、「ANSWER SECTION」にグローバルIPアドレス登録されているかどうか確認する。
ALBの場合、複数のグローバルIPアドレスが表示されます。
・ALBのセキュリティグループ設定
ALBのセキュリティグループ設定でTCP443の接続許可設定を行う。
接続許可設定を行った後、以下のコマンドを実施する。実施後、ステータスコードが200で返ってくることを確認する。
----
curl -i https://Domain Name.com
----
もし、今後どうしてもできない場合は以下のような感じで質問することをおすすめします。今回は事前に調べて、できたこととできなかった部分
を切り分けて頂いたのはとても良いかと思います。
現場では質問する際、詳細かつ整理された状態で質問しないと中々意図した回答が得られないことが多いです。また、メーカのサポート等へ問い合わせする際も使います。
長くなっても構いませんので、できる限り詳細に整理された記述されることをおすすめします。
----------
・実施したこと
・確認できたこと
・できなかったこと
・その他詳細情報
例
ドメイン名等の情報
----------
無事に解決することが出来ました!
TCP80の設定が抜けてしまっていたようでした
バラバラと疑問を書いてしまい、申し訳ございませんでした
今回の解決方法は非常に参考になりました!!
部活の学習一覧
インフラ部 Lesson 01 | インフラ部の最終ゴール
インフラ部 Lesson 02 | ITインフラとは何か?
インフラ部 Lesson 03 | インフラ構築・運用管理において必要な知識
インフラ部 Lesson 04 | OS編 その1
インフラ部 Lesson 05 | OS編 その2
インフラ部 Lesson 06 | ネットワーク編 その1
インフラ部 Lesson 07 | ネットワーク編 その2
インフラ部 Lesson 08 | ネットワーク編 その3
インフラ部 Lesson 09 | ネットワーク編 その4
インフラ部 Lesson 10 | ネットワーク編 その5
インフラ部 Lesson 11 | ネットワーク編 その6
インフラ部 Lesson 12 | ネットワーク編 その7
インフラ部 Lesson 13 | ネットワーク編 その8
インフラ部 Lesson 14 | DNS その1
インフラ部 Lesson 15 | DNS その2
インフラ部 Lesson 16 | Web
インフラ部 Lesson 17 | DB
インフラ部 Lesson 18 | ストレージ
インフラ部 Lesson 19 | メール
インフラ部 Lesson 20 | SSLサーバ証明書
インフラ部 Lesson 21 | VPS
インフラ部 Lesson 22 | AWSとは
インフラ部 Lesson 23 | AWS基盤構築前の事前準備と設計の流れについて その1
インフラ部 Lesson 24 | AWS基盤構築前の事前準備と設計の流れについて その2
インフラ部 Lesson 25 | AWS基盤構築前の事前準備と設計の流れについて その3
インフラ部 Lesson 26 | AWS基盤構築前の事前準備と設計の流れについて その4
インフラ部 Lesson 27 | AWS基盤インフラ構築(設計と構成図作成)
インフラ部 Lesson 28 | AWS基盤インフラ構築(ネットワーク設計・作成) その1
インフラ部 Lesson 29 | AWS基盤インフラ構築(ネットワーク設計・作成) その2
インフラ部 Lesson 30 | AWS基盤インフラ構築(ネットワーク設計・作成) その3
インフラ部 Lesson 31 | AWS基盤インフラ構築(Bastionサーバ) その1
インフラ部 Lesson 32 | AWS基盤インフラ構築(Bastionサーバ) その2
インフラ部 Lesson 33 | AWS基盤インフラ構築(Bastionサーバ) その3
インフラ部 Lesson 34 | AWS基盤インフラ構築(Bastionサーバ) その4
インフラ部 Lesson 35 | AWS基盤インフラ構築(Bastionサーバ) その5
インフラ部 Lesson 36 | AWS基盤インフラ構築(Bastionサーバ) その6
インフラ部 Lesson 37 | AWS基盤インフラ構築(Bastionサーバ) その7
インフラ部 Lesson 38 | AWS基盤インフラ構築(Webサーバ構築・設定) その1
インフラ部 Lesson 39 | AWS基盤インフラ構築(Webサーバ構築・設定) その2
インフラ部 Lesson40 | AWS基盤インフラ構築(Webサーバ構築・設定) その3
インフラ部 Lesson41 | AWS基盤インフラ構築(データベース構築・設定)
インフラ部 Lesson42 | AWS基盤インフラ構築(Route53、証明書取得、ALB作成とEC2との接続設定・接続確認) その1
インフラ部 Lesson43 | AWS基盤インフラ構築(Route53、証明書取得、ALB作成とEC2との接続設定・接続確認) その2
インフラ部 Lesson44 | AWS基盤インフラ構築(メールサーバの構築と設定) その1
インフラ部 Lesson45 | AWS基盤インフラ構築(メールサーバの構築と設定) その2
インフラ部 Lesson46 | AWS基盤インフラ構築(メールサーバの構築と設定) その3
インフラ部 Lesson47 | AWS基盤インフラ構築(メールサーバの構築と設定) その4
インフラ部 Lesson48 | AWS基盤インフラ構築(メールサーバの構築と設定) その5
インフラ部 Lesson49 | AWS基盤インフラ構築(メールサーバの構築と設定) その6
インフラ部 Lesson50 | AWS基盤インフラ構築(Laravelの環境構築)
インフラ部 Lesson51 | AWS基盤インフラ構築(S3構築・設定)
インフラ部 Lesson52 | AWS基盤インフラ構築(CloudFront構築・設定) その1
インフラ部 Lesson53 | AWS基盤インフラ構築(CloudFront構築・設定) その2
インフラ部 Lesson54 | AWS基盤インフラ構築(監視構築・設定) その1
インフラ部 Lesson55 | AWS基盤インフラ構築(監視構築・設定) その2
インフラ部 Lesson56 | AWS基盤インフラ構築(まとめ)
ご意見箱
CLIを使い、WEBサーバーから、アクセスログを
tail -f /var/log/httpd/access_log で拾うと
2行目に、
"GET /favicon.ico HTTP/1.1" 404 209 "http://18.178.186.129/"
と書かれており、ページが見つからない状態だとわかりました
また、ロードバランサーのモニタリングで確認すると
リクエスト自体はされている事がわかりました。
ロードバランサーまでは、接続が出来ていると言う事でしょうか?
また、ターゲットグループを確認すると
「これらのいずれのアベイラビリティーゾーンにも、正常なターゲットは含まれていません。リクエストはすべてのターゲットにルーティング中です。」
と表示されており
ステータス : unhealthy
説明 : Health checks failed with these codes: [504]
との表記もありました、この事踏まえて
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/target-group-health-checks.html
で調べたところ、Target.ResponseCodeMismatchに該当するのではないかと考えています。
そこでEC2のWEBサーバーインスタンスを確認しました。
インスタンスの状態は、runningで
CLIからは、接続が出来ているので
セキュリティーで弾かれてるのでしょうか??
また、グローバルIPも現在bastionサーバーとWEBサーバーの二つに使っている状態なので
そこでしょうか??
長くなりましたが、異常が疑問点になります。
よろしくお願いいたします。