NAT単一のパブリックIPアドレスを使用して複数のサーバーを公開する
これは Canonical Question about NAT and DNS
私は現在、ネットワークアドレス変換（NAT）ファイアウォールによってインターネットから分離されたWebサーバーと電子メールサーバーを含むDMZを含むネットワークをセットアップしようとしています。
NATファイアウォールと以下のインターフェースをインストールしました：
WAN - x.x.x.x (redacted public IP address)
DMZ - 192.168.124.5/24
LAN - 192.168.123.5/24
私のDMZ私には2つのホストがあります：
Web server - 192.168.124.30
E-mail server - 192.168.124.32
example.comとexample.comの両方をパブリックIPアドレスに解決するには、mail.example.comドメインのDNSを構成する必要があることはわかっています。
NATファイアウォールがexample.comへのすべての着信要求を192.168.124.30のWebサーバーに転送し、mail.example.comへのすべての着信要求を電子メールに転送するようにしたい192.168.124.32。のサーバーNATファイアウォールの構成に「ポート転送」機能が表示されますが、探しているものを実現できないようです。
特に、DNSとアプリケーションレイヤープロトコルの間で、TCP/IPプロトコルスタックのレイヤー間で情報がどのように流れるかについての考えに混乱しています。
1つのパブリックIPアドレスがあります。 DNSは確かにmail.example.comとexample.comの両方を同じパブリックIPアドレスに解決できます。
一般に、ファイアウォールの外部インターフェースによって受信される、パブリックIPアドレスへのリクエストを含むIPデータグラムには、リモートクライアントがアクセスしようとしているホストの名前は含まれていません。両方のホスト名が同じIPアドレスに解決されるため、ファイアウォールはリモートクライアントが解決したホスト名を魔法のように「知る」ことができません。 IP層は、アプリケーション層で使用されるホスト名を認識しません。
TCPとUDPプロトコルは、ポート番号を使用してホストによって提供される特定のサービスを区別します。この例の場合、ポート転送（ポートアドレス変換、またはPATとも呼ばれます）を使用できる可能性があります） NATファイアウォールの機能で、着信要求をTCPポート80（HTTP）に送信し、インバウンドを送信するときにTCP =メールサーバーへのポート25（SMTP）。
ただし、両方のマシンで同じサービスをホストする場合は、この戦略が問題になります。 Webサーバー上の安全なWebサイト（カスタマーアクセス用）とEメールサーバー上の安全なWebサイト（Webメール用）の両方をホストするとします。 NATファイアウォールのパブリックIPアドレスからTCPポート443（HTTPS））へのリクエストは、1つのサーバーまたは他のサーバーにのみルーティングできます。
この状況に対する一般的な解決策は、パブリックIPアドレスを増やすことです。 IPv4アドレスが不足しているため、これも問題になる可能性があります。
アプリケーション層のsomeプロトコルのパブリックIPアドレスの不足に対処することになります。たとえば、HTTP/1.1はHost:ヘッダーを追加して、Webサーバーが同じパブリックIPアドレスで複数のWebサイトをホストできるようにしています。 TLSは Server Name Indication （SNI）拡張を追加して、リモートクライアントによって入力されたホスト名に基づいて適切な証明書を選択できるようにします。
アプリケーション層でこの種の回避策を実行することは、すべてのアプリケーション層プロトコルに独自の「修正」が必要になることを意味します（すべてのサーバーとクライアントソフトウェアがその「修正」を実装する必要があります）。それは難しい注文です。
アプリケーション層プロトコルを変更する代わりに、一部のプロトコルは、要求を「ルーティング」できるソフトウェアを使用して、複数のホスト間で簡単に「多重化」できます。パケットはアプリケーション層で検査する必要があるため、これは単純なNATファイアウォールで可能なことを超えています。 nginxのようなリバースプロキシを使用する は良いですHTTPプロトコルのこの種の「多重化」の例（または Forefront TMGのWeb公開ルールまたはISAサーバー Microsoft環境の場合））。理論的にはanyプロトコルはリバースプロキシを介して多重化できますが、プロトコルが難解であるほど、カスタムコードの記述について話し合う可能性が高くなります。
単一のパブリックIPアドレスで2つの異なるホストから同じサービスを提供する必要がある場合、ホストの1つを非標準ポートに移動するオプションが常にあります。ただし、これにはクライアントが非標準ポートを認識する必要があります。 HTTP（S）の場合、これはhttp://example.com:XXX表記のURLになります（XXXは非標準のポート番号です）。これがあなたの状況で問題になるかどうかは、あなただけが決めることができます。 （私の経験では、実際に入力する必要のあるURLで:XXXポート表記を処理できるエンドユーザーはほとんどいないことが示されています。）
「ポート転送」機能を使用すると、：80および：443宛てのトラフィックを192.168.124.30に送信し、残りのポート（または電子メールサーバーが使用するように構成されているポートのみ）を192.168.124.32に送信できます。なんらかの理由で、EメールサーバーとWebサーバーにこれら2つのポートのいずれかが必要な場合は、問題が発生しています。この方法が機能するためには、電子メールサーバーへのすべてのWebアクセスが別の（おそらく非標準の）ポートである必要があります。また、おそらく「mail.example.com "を使用するにはhttps://mail.example.com:other_port代わりに、ポート番号を追加する方法や安全な接続を指定する方法を知らないユーザー向け。 （あなたあるメールサーバーへの安全なWeb接続のみを使用するでしょう？）
これは、アプリケーション層ではなくトランスポート層にあります。つまり、詳細なパケット検査に依存する必要はありません。代わりに、ポートのTCPヘッダーで見つけやすい場所を調べることができます。
「受信リクエスト」が異なるもの、つまりWebサーバーのWebトラフィック（HTTP）とメールサーバーのメールトラフィック（SMTP）の場合、これは実際に実行できます。HTTPはTCPポートを使用します80（HTTPSの場合は443）、SMTPはTCPポート25を使用するため、同じパブリックIPアドレスから、HTTPトラフィックをWebサーバーに転送し、SMTPトラフィックをメールサーバーに転送できます。これが「ポートフォワーディング」の意味です。適切なファイアウォールであれば、これが可能です。
ただし、偶然にも2つのサーバーが同じタイプのトラフィックを受け入れる必要がある場合は、メールサーバーがウェブメールサービスもホストしている場合、特定のポート（80または443、あるいはその両方）を単一のサーバーにのみ転送できるため、問題が発生します。クライアントが要求に使用した名前に基づいてWebトラフィックを分離するには、リバースプロキシなど、TCP/IPよりも高いレベルで動作するものが必要です。