Ti stai confondendo nel pensare a come fluiscono le informazioni tra i livelli dello stack del protocollo TCP / IP, tra i protocolli DNS e dei livelli applicazione, in particolare.
Hai un indirizzo IP pubblico. Il tuo DNS può certamente risolvere entrambi mail.example.come example.comallo stesso indirizzo IP pubblico.
In generale, i datagrammi IP contenenti richieste al tuo indirizzo IP pubblico, che saranno ricevuti dall'interfaccia esterna del firewall, non contengono il nome dell'host a cui il client remoto sta tentando di accedere. Il tuo firewall non può "sapere" magicamente quale nome host è stato risolto dal client remoto, poiché entrambi i nomi host risolvono allo stesso indirizzo IP. Il livello IP non è a conoscenza del nome host utilizzato a livello dell'applicazione.
I protocolli TCP e UDP differenziano i servizi specifici offerti da un host utilizzando i numeri di porta. Nel caso del tuo esempio, potrebbe essere possibile utilizzare la funzionalità di port forwarding (detta anche traduzione dell'indirizzo della porta o PAT) del firewall NAT per inviare richieste in ingresso alla porta TCP 80 (HTTP) al server Web durante l'invio della porta TCP in entrata 25 (SMTP) al tuo server di posta elettronica.
Se, tuttavia, prevedi di ospitare lo stesso servizio su entrambe le macchine, questa strategia diventa problematica. Supponiamo che stai per ospitare sia un sito Web sicuro sul tuo server Web (per l'accesso del Cliente) sia un sito Web sicuro sul tuo server di posta elettronica (per la webmail). Le richieste che arrivano all'indirizzo IP pubblico del firewall NAT alla porta TCP 443 (HTTPS) possono essere indirizzate solo a un server o all'altro.
La soluzione generalizzata a questa situazione è avere più indirizzi IP pubblici. Perché gli indirizzi IPv4 stanno diventando scarsi che possono anche essere problematici.
Finiamo per ovviare alla scarsità di indirizzi IP pubblici in alcuni protocolli a livello di applicazione. Ad esempio, HTTP / 1.1 ha aggiunto l' Host:intestazione specificatamente per consentire a un server Web di ospitare più siti Web sullo stesso indirizzo IP pubblico. TLS aggiunge l' estensione SNI ( Server Name Indication ) per consentire la selezione del certificato appropriato in base al nome host inserito dal client remoto.
Fare questo tipo di soluzione nel livello dell'applicazione significa che ogni protocollo del livello applicazione avrebbe bisogno della propria "correzione" (e quindi tutti i software server e client dovrebbero implementare quella "correzione"). Questo è un ordine elevato.
Invece di modificare il protocollo del livello applicazione, alcuni protocolli sono facilmente suscettibili di essere "multiplexati" tra più host utilizzando un software in grado di "instradare" le richieste. Questo probabilmente va oltre ciò di cui è capace un semplice firewall NAT perché i pacchetti devono essere controllati a livello di applicazione. L'uso di un proxy inverso come nginx è un buon esempio di questo tipo di "multiplexing" (o regole di pubblicazione Web su Forefront TMG o ISA Server in un ambiente Microsoft) per il protocollo HTTP. In teoria, qualsiasi protocollo potrebbe essere multiplexato tramite un proxy inverso, ma più esoterico è il protocollo, più è probabile che si parlerebbe di scrivere codice personalizzato.
Quando è necessario offrire lo stesso servizio da due host diversi su un unico indirizzo IP pubblico, è sempre possibile spostare uno degli host su una porta non standard. Ciò richiederà tuttavia che i client siano a conoscenza della porta non standard. Nel caso di HTTP (S) ciò si traduce in URL con la http://example.com:XXXnotazione (dove si XXXtrova il numero di porta non standard). Se questo sarebbe problematico nella tua situazione è qualcosa che solo tu puoi decidere. (La mia esperienza ha dimostrato che praticamente nessun utente finale è in grado di gestire la :XXXnotazione delle porte in qualsiasi URL che deve inserire manualmente.)