Sie sind verwirrt, wenn Sie über den Informationsfluss zwischen den Schichten des TCP / IP-Protokollstapels nachdenken - insbesondere zwischen DNS- und Anwendungsschichtprotokollen.
Sie haben eine öffentliche IP-Adresse. Ihr DNS kann sicherlich beide mail.example.comund example.comdieselbe öffentliche IP-Adresse auflösen .
Im Allgemeinen enthalten die IP-Datagramme, die Anforderungen an Ihre öffentliche IP-Adresse enthalten, die von der externen Schnittstelle Ihrer Firewall empfangen werden, nicht den Namen des Hosts, auf den der Remote-Client zuzugreifen versucht. Ihre Firewall kann nicht auf magische Weise "wissen", welchen Hostnamen der Remoteclient aufgelöst hat, da beide Hostnamen in dieselbe IP-Adresse aufgelöst werden. Der IP-Schicht ist der auf der Anwendungsebene verwendete Hostname nicht bekannt.
Die TCP- und UDP-Protokolle unterscheiden bestimmte Dienste, die von einem Host angeboten werden, anhand von Portnummern. In Ihrem Beispiel ist es möglicherweise möglich, die Portweiterleitungsfunktion (auch als Portadressübersetzung oder PAT bezeichnet) Ihrer NAT-Firewall zu verwenden, um eingehende Anforderungen an TCP-Port 80 (HTTP) an den Webserver zu senden, während eingehende TCP-Ports gesendet werden 25 (SMTP) auf Ihren E-Mail-Server.
Wenn Sie jedoch vorhaben, denselben Dienst auf beiden Computern zu hosten, wird diese Strategie problematisch. Angenommen, Sie hosten sowohl eine sichere Website auf Ihrem Webserver (für den Kundenzugriff) als auch eine sichere Website auf Ihrem E-Mail-Server (für Webmail). Anforderungen, die an die öffentliche IP-Adresse Ihrer NAT-Firewall an den TCP-Port 443 (HTTPS) gesendet werden, können nur an den einen oder anderen Server weitergeleitet werden.
Die allgemeine Lösung für diese Situation besteht darin, mehr öffentliche IP-Adressen zu haben. Da IPv4-Adressen knapp werden, kann dies ebenfalls problematisch sein.
Am Ende arbeiten wir auf der Anwendungsebene an der Knappheit öffentlicher IP-Adressen in einigen Protokollen. Beispielsweise hat HTTP / 1.1 den Host:Header speziell hinzugefügt , damit ein Webserver mehrere Websites unter derselben öffentlichen IP-Adresse hosten kann. TLS fügt die Server Name Indication (SNI) -Erweiterung hinzu, um die Auswahl des geeigneten Zertifikats basierend auf dem vom Remote-Client eingegebenen Hostnamen zu ermöglichen.
Eine solche Problemumgehung in der Anwendungsschicht bedeutet, dass jedes Anwendungsschichtprotokoll eine eigene "Korrektur" benötigt (und dann müsste die gesamte Server- und Client-Software diese "Korrektur" implementieren). Das ist eine große Aufgabe.
Anstatt das Anwendungsschichtprotokoll zu modifizieren, können einige Protokolle leicht zwischen mehreren Hosts "gemultiplext" werden, indem Software verwendet wird, die Anforderungen "weiterleiten" kann. Dies geht wahrscheinlich über das hinaus, was eine einfache NAT-Firewall kann, da die Pakete auf Anwendungsebene überprüft werden müssen. Die Verwendung eines Reverseproxys wie nginx ist ein gutes Beispiel für diese Art von "Multiplexing" (oder für Webveröffentlichungsregeln in Forefront TMG oder ISA Server in einer Microsoft-Umgebung) für das HTTP-Protokoll. Theoretisch könnte jedes Protokoll über einen Reverse-Proxy gemultiplext werden. Je esoterischer das Protokoll, desto wahrscheinlicher ist es, dass Sie über das Schreiben von benutzerdefiniertem Code sprechen.
Wenn Sie denselben Dienst von zwei verschiedenen Hosts auf einer einzigen öffentlichen IP-Adresse anbieten müssen, haben Sie immer die Möglichkeit, einen der Hosts auf einen nicht standardmäßigen Port zu verschieben. Dies setzt jedoch voraus, dass Clients den nicht standardmäßigen Port kennen. Im Fall von HTTP (S) führt dies zu URLs mit der http://example.com:XXXNotation (wobei XXXdie nicht standardmäßige Portnummer ist). Ob dies in Ihrer Situation problematisch ist, können nur Sie selbst entscheiden. (Meine Erfahrung hat gezeigt, dass praktisch kein Endbenutzer in der Lage ist, die :XXXPortnotation in einer URL zu verarbeiten, die er manuell eingeben muss.)