前回、プライベートサブネットにDBサーバーを構築しました。DBサーバーへのアクセスは、通常インターネットとは接続されていないため、Webサーバーからのみアクセスできるようにします。

前回の記事『プライベートサブネットにDBサーバーを構築する

サーバーへの疎通を確認する手法として、[pingコマンド]が広く使われています。pingコマンドを用いて、実際に接続してみましょう。

pingコマンドについて

最初に、pingコマンドについて少しおさらいしてみたいと思います。pingコマンドは、「ICMP」というプロコトルを使用します。

例えば、DBサーバーへの疎通を行う場合を例に考えてみます。パケットを送信する際に「ICMPエコー要求(Echo Request)」というパケットを送信します。

それを受け取ったホストは、送信元の端末に対して、「ICMPエコー応答(Echo Reply)」のパケットを返信します。

pingコマンドでは、「エコーリクエスト」と「エコーリプライ」を繰り返して、パケットの疎通を確認したり、到達するまでの時間を計測します。

TeraTermで接続してみる

実際にWebサーバーからDBサーバーに対して、pingコマンドを通してみましょう。まずは、WebサーバのパブリックDNSを確認します。

ここでは、「ec2-18-180-240-38.ap-northeast-1.compute.amazonaws.com」と表示されています。DNSに対してSSHでログインします。※なお、ElasticIPアドレスでも構いません。

TeraTermで接続してみます。接続方法については、以前の記事にまとめてありますので、そちらをご確認ください。

Tera Termへの接続が完了したら、DBサーバーに対して、pingコマンドを打ってみます。

$ ping 10.0.2.10

リクエストに対して、レスポンス(リプライ)がありません。

--- 10.0.2.10 ping statistics ---
80 packets transmitted, 0 received, 100% packet loss, time 80901ms

これは、AWSでは、デフォルトのセキュリティグループの構成では、ICMPプロコトルのパーミッションが許可されていないからです。そこで、作成したDBサーバーに対してICMPプロコトルが通過するようにファイアウォールの構成を変更する作業が必要になります。

ICMPプロコトルを許可する

繰り返しになりますが、AWSの初期設定ではICMPプロコトルの通過が許可されていません。そこで、DBサーバーに対して、ICMPプロコトルを許可するようにファイアウォールの設定をおこないます。

今回は、[WebサーバーからDBサーバーに対して]のping通信を許可するので、DB-Serverより、インバウンドの値を追加していきます。*DBサーバー側からみた受信方向のアクセスを許可する設定をします。

[ルールの追加]をクリックして、[すべてのICMP-IPv4]を選択します。ソースはWebサーバがからの通信を許可するので、[10.0.1.10/32]としておきます。

DBサーバーにpingコマンドを実行

実際にDBサーバーに対して、pingコマンドを入力してみます。

[ec2-user@ip-10-0-1-10 ~]$ ping 10.0.2.10
PING 10.0.2.10 (10.0.2.10) 56(84) bytes of data.
64 bytes from 10.0.2.10: icmp_seq=1 ttl=255 time=0.367 ms
64 bytes from 10.0.2.10: icmp_seq=2 ttl=255 time=0.425 ms
64 bytes from 10.0.2.10: icmp_seq=3 ttl=255 time=0.456 ms
64 bytes from 10.0.2.10: icmp_seq=4 ttl=255 time=0.435 ms
64 bytes from 10.0.2.10: icmp_seq=5 ttl=255 time=0.478 ms
64 bytes from 10.0.2.10: icmp_seq=6 ttl=255 time=0.385 ms
64 bytes from 10.0.2.10: icmp_seq=7 ttl=255 time=1.22 ms

こんな感じで、リクエストとレスポンスが表示されているのが確認できました。なお、この表示は永遠に表示されますので、止めたい時は、Ctrl+Cでストップしましょう。

Webサーバーにpingコマンドを実行

Webサーバに対してpingコマンドを実行していきましょう。Webサーバーからみたインバウンド(受信)は各端末(ローカル環境)になりますので、コマンドプロンプトから実行していきます。

webサーバーへのpingコマンドは、パブリックDNSまたはElasticIP向けに実行します。

Microsoft Windows [Version 10.0.18363.778]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users>ping ec2-18-180-240-38.ap-northeast-1.compute.amazonaws.com

ec2-18-180-240-38.ap-northeast-1.compute.amazonaws.com [18.180.240.38]に ping を送信しています 32 バイトのデータ:
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。

18.180.240.38 の ping 統計:
    パケット数: 送信 = 4、受信 = 0、損失 = 4 (100% の損失)

要求がタイムアウトします。

Webブラウザからアクセスすると、Apacheの初期画面が表示されていますが、pingコマンドが通過しない状態です。

これは、Webサーバーのファイアウォールで80番ポートは許可されているが、ICMPプロコトルが許可されていないことを表しています。この状態でもサーバーの動作に支障をきたすことはありませんが、ICMPプロコトルを許可する構成が一般的です。

多くのWebサイトでは、このような構成になっています。弊社のコーポレートサイトに対してpingを実行したところ、以下のレスポンスがありました。これは、GoogleでもYahoo!でも同じです。

Microsoft Windows [Version 10.0.18363.778]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users>ping www.cyber-bridge.jp

www.cyber-bridge.jp [183.90.225.239]に ping を送信しています 32 バイトのデータ:
183.90.225.239 からの応答: バイト数 =32 時間 =13ms TTL=54
183.90.225.239 からの応答: バイト数 =32 時間 =10ms TTL=54
183.90.225.239 からの応答: バイト数 =32 時間 =11ms TTL=54
183.90.225.239 からの応答: バイト数 =32 時間 =10ms TTL=54

183.90.225.239 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 10ms、最大 = 13ms、平均 = 11ms

WebServerにICMPプロコトルを許可する

DBサーバーに許可したときと同じように、Webサーバーにも許可をしていきましょう。DBサーバーとの違いは、ソースを全てのIPアドレスにする点です。

Webサーバーのセキュリティグループを選択して、インバウンドのルールを追加します。

ICMPを追加し、ソースを全てのIPアドレスにします。

実際に、pingコマンドを実行してみましょう。

Microsoft Windows [Version 10.0.18363.778]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users>ping ec2-18-180-240-38.ap-northeast-1.compute.amazonaws.com

ec2-18-180-240-38.ap-northeast-1.compute.amazonaws.com [18.180.240.38]に ping を送信しています 32 バイトのデータ:
18.180.240.38 からの応答: バイト数 =32 時間 =7ms TTL=234
18.180.240.38 からの応答: バイト数 =32 時間 =6ms TTL=234
18.180.240.38 からの応答: バイト数 =32 時間 =8ms TTL=234
18.180.240.38 からの応答: バイト数 =32 時間 =6ms TTL=234

18.180.240.38 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 6ms、最大 = 8ms、平均 = 6ms

リクエストに対して、レスポンスが返っていることが確認できました。

踏み台サーバー

ここまで、ローカル環境からWebサーバーへのアクセス、WebサーバーからDBサーバーへのアクセスができることを確認しました。

しかし、実際にローカル環境からDBサーバーへの接続ができていません。DBサーバー内にMySQLをインストールしなければならないのですが、DBサーバーはインターネットと接続されていないため、インストールができないです。

そこで一般的に解決方法として用いられるのが、「踏み台サーバー」になります。踏み台サーバーのイメージとしては、「ローカル→WebサーバーへSSH接続」「Webサーバー→DBサーバーへSSH接続」の流れでWebサーバーを踏み台にして、DBサーバーへアクセスします。

このように、Webサーバーを踏み台にすることで、DBサーバーへアクセスすることが可能になるのです。

踏み台サーバーを経由してDBサーバーにSSH接続

実際に接続していきましょう。

AWSの場合、WebサーバーからDBサーバーに接続するためには、「秘密鍵」をWebサーバーに置いておく必要があります。秘密鍵のファイルをWebサーバーに転送する必要があります。

サーバーにファイルを転送するためには、「SCP(Secure Copy)」というプロコトルが必要になります。

Tera Termの場合、Webサーバーに接続した状態で、[ファイル]>[SSH SCP]をクリックすることでファイルを転送できます。転送先はホームディレクトリにします。

秘密鍵をホームディレクトリに転送する

秘密鍵の転送が完了したら、実際にDBサーバーへSSH接続してみましょう。

手順をおさらいします。

  1. SSHでWebサーバー(10.0.1.10)に接続する
  2. WebサーバーからDBサーバー(10.0.2.10)に接続する

このように2段階(踏み台)で接続していきます。

その前に鍵のパーミッションを変更します。この場合、『自分だけが読み取れる』ように設定をしたいので、chmodコマンドのモード指定値を「400」にします。

$ chmod 400 ******.pem
# ******は秘密鍵ファイルのファイル名 

パーミッションを変更しないと、秘密鍵が見られてしまい誰もが自由にサーバーへアクセスできてしまいます。セキュリティを高めるためにも必要ですが、いずれにせよ、DBサーバーに接続する際にエラーになってしまいます。

Webサーバを踏み台にしてDBサーバーに接続します。

$ ssh -i ******.pem ec2-user@10.0.2.10

これで、WebサーバーからDBサーバーへのログインが完了しました。

DBサーバー上での操作が完了したら、「exit」と入力してログアウトし、Webサーバー上での操作に戻ることが可能です。

注意点

ここでの注意点として、接続ができない場合はセキュリティグループの設定を再確認しましょう。

DBサーバーのインバウンドルールについてのソースは『WebサーバーのIPアドレス』になっていることを確認します。

ここの設定が適切でないとエラーが出てしまうので注意が必要です。

今回はこのへんで。