AWS

3000番ポートを閉じた時のNginxの設定変更で、どハマリしてしまったのでメモ

0

外部からポートスキャンをされて、攻撃のターゲットにならないように、不要な3000番ポートを閉じたのですが、そのときのNginxの設定変更で2日間もハマってしまったので、一生忘れないようにするためにメモ!!

Nginxの設定ですが、当初は下記のような設定をしていました。

【エラー内容・問題】
3000番ポートを閉じてからサーバーにリクエストを送って本番環境へのアクセスを試みると、Nginxの500エラーページが出ている。つまりUnicornまでリクエストが届いていない状態になっていた。

3000番ポートを閉じたと言っても、今まで本番環境へアクセスする時は80番ポート経由でアクセスしていたから、これまで使ってこなかった3000番ポートを閉じても影響は出ないはずでは。。。と2日間もハマってしまいました。

結論から言うと、外部アドレスにアクセスしようとしていたことが原因でした。

【リクエストがサーバーに届くまでの流れ】

この図の中で、私の理解が欠落していた部分は、DNSサーバーとルーターの存在でした。クライアントからのリクエスト送信先は、IPアドレスによって特定されます。
IPアドレスは人間にとっては見にくい表示形態なので、その多くはドメインを適用することで人間が見やすい文字列にしています。
裏を返すと、コンピュータからすると、ドメインの文字列はとても見にくくて、処理しにくい表示形態なので、ドメインではリクエスト送信先を特定することができません。なので、DNSサーバーに問い合わせて、リクエストとして指定された宛先であるドメインが示しているIPアドレスを特定します。いわばドメインをIPアドレスに変換しているようなイメージです。
IPアドレスが特定されると、ルーターを通して、外部ネットワークにデータが送信され、様々なルーターを経て最終的に、IPアドレスに示された送信先にデータが到着する、という流れです。

では、これを踏まえて私が陥っていた状況はどのような状況だったかを示しているのが、下記の図です。

Nginxが受け取ったリクエストを同一サーバー内のUnicornに転送するという設定をしているつもりでしたが、実際は外部アドレスに転送するという設定になっていました。
外部アドレスに転送するという設定にした結果、上記の図のように既に閉じられている3000番ポートでリクエストが遮断され、アクセスすることができない状況になっていました。

これを解消する方法はいくつかありますが、今回は転送先であるUnicornが同じサーバーマシン内、つまりlocalhostにあることを利用して、下記のような転送設定にすることで無事に解決することができました!!

 

仕組みを理解していないと、こんなに苦労するものかと思い知らされました笑

0