
私は、example.com と anotherexample.com という複数のドメイン名を持つサーバー上でプラットフォームをホストしています。そのサーバー上で Spring Boot バックエンドを実行しています。このバックエンドはドメイン example.com を使用して anotherexample.com と通信しようとします。問題は、HTTPS 経由で他のドメインに接続できないことです。接続すらできません。次のテストを試しましたが、異なる結果が返されました。
curl
ファイアウォールの外側のマシンで使用するとhttps://anotherexample.com、完璧に動作しますcurl
サーバー上で使用するのではなく、http://anotherexample.com、完璧に動作しますcurl
サーバー上で使用してhttps://anotherexample.com応答なし、最終的にタイムアウトcurl
ファイアウォールを使用してhttps://anotherexample.com応答なし、最終的にタイムアウトopenssl s_client -connect anotherexample.com:443 -servername anotherexample.com
サーバー上で使用しても応答がなく、最終的にタイムアウトします/etc/hosts
サーバー上で を に変更し127.0.0.1 anotherexample.com
、 を実行するとopenssl s_client -connect anotherexample.com:443 -servername anotherexample.com
、応答が返されます。
ファイアウォールの背後にあるマシンでホストされているドメインに接続できない原因は、サーバー (Ubuntu 22.04) または PfSense ファイアウォール (2.7.2) で何かが誤って構成されていることでしょうか。
私の構造は次のとおりです。
- NATを使用してパブリックIPがサーバーの内部IPに確実に到達できるようにするPfSenseファイアウォール
- ポート80と443が開いているNGINXを実行しているサーバー。証明書はLetsEncrypt経由で行われ、ブラウザで完全に機能します。
答え1
これは正常です。DNAT (「ポート フォワーディング」) は、送信元と実際の送信先の両方が同じサブネット (または同じシステム) にある場合、機能しません。ホーム ゲートウェイに関する同じ問題に関する以前のスレッドが多数投稿されていますが (「NAT ヘアピン」を検索してください)、これは pfSense を含むすべての NAT 実装に同様に当てはまります。したがって、詳細な説明については以前の投稿を検索してください。基本的な問題は、ファイアウォールがパケットを一方向にしか書き換えることができず、他の方向には書き換えることができないことです。
一般的な回避策は、pfSenseにソースIPアドレスも書き換えさせ、Webサーバーに対して、接続がファイアウォールからではなくファイアウォールから来ているように見せることです。これを行うには、NATリフレクションファイアウォールでは、他の場所では「NAT ループバック」、「NAT ヘアピン」、または特定の名前のないカスタム SNAT ルールと呼ばれます。
各パケットは必ずイーサネットを経由してpfSenseに到達するため、パフォーマンスに若干の影響が出ることに注意してください。そしてマシン内に完全に留まるのではなく、マシンに戻ることができます。IP ベースのアクセスを使用している場合は、Web アプリケーションもファイアウォール IP を想定する必要があります。
だから私は個人的に推薦する127.0.0.1
NAT リフレクションに頼るのではなく、すべてのドメインの /etc/hosts エントリを使用します。