Soluzione 1:
Ho cancellato la mia risposta originale, perché non ero del tutto sicuro che fosse corretta. Da allora ho avuto del tempo per configurare una piccola rete virtuale di macchine virtuali per simulare la rete in questione. Ecco il set di regole del firewall che ha funzionato per me (in iptables-save formato, per il nat solo tabella):
-A PREROUTING -d 89.179.245.232/32 -p tcp -m multiport --dports 22,25,80,443 -j DNAT --to-destination 192.168.2.10
-A POSTROUTING -s 192.168.2.0/24 -o ppp0 -j MASQUERADE
-A POSTROUTING -s 192.168.2.0/24 -d 192.168.2.10/32 -p tcp -m multiport --dports 22,25,80,443 -j MASQUERADE
Il primo POSTROUTING regola è un modo semplice per condividere la connessione Internet con la LAN. L'ho lasciato lì per completezza.
Il PREROUTING regola e la seconda POSTROUTING regola insieme stabiliscono i NAT appropriati, in modo che le connessioni al server tramite l'indirizzo IP esterno possano avvenire, indipendentemente dal fatto che le connessioni provengano dall'esterno o dall'interno della LAN. Quando i client sulla LAN si connettono al server tramite l'indirizzo IP esterno, il server vede le connessioni come provenienti dall'indirizzo IP interno del router (192.168.2.1).
È interessante notare che ci sono un paio di varianti della seconda regola di POSTROUTING che funzionano anch'esse. Se il target viene modificato in -j SNAT --to-source 192.168.2.1 , l'effetto è (non sorprendentemente) lo stesso del MASQUERADE :il server vede le connessioni dai client LAN locali come provenienti dall'interno del router Indirizzo IP. D'altra parte, se il target viene modificato in -j SNAT --to-source 89.179.245.232 , quindi i NAT funzionano ancora, ma questa volta il server vede le connessioni dai client LAN locali come originate dall'esterno del router Indirizzo IP (89.179.245.232).
Infine, nota che il tuo PREROUTING originale /DNAT regola con -i ppp0 non funziona, perché la regola non confronta mai i pacchetti provenienti dai client della LAN (poiché questi non entrano nel router tramite il ppp0 interfaccia). Sarebbe possibile farlo funzionare aggiungendo un secondo PREROUTING regola solo per i client LAN interni, ma sarebbe poco elegante (IMO) e avrebbe comunque bisogno di fare riferimento esplicito all'indirizzo IP esterno.
Ora, anche dopo aver delineato una soluzione "hairpin NAT" (o "NAT loopback", o "NAT reflection", o come si preferisce chiamarla) in tutti i dettagli, credo ancora che una soluzione DNS split-horizon... -con i client esterni che si risolvono nell'IP esterno e i client interni che si risolvono nell'IP interno --- sarebbe la strada più consigliabile da prendere. Come mai? Perché più persone capiscono come funziona il DNS che come funziona il NAT, e gran parte della costruzione di buoni sistemi è scegliere di utilizzare parti manutenibili. È più probabile che una configurazione DNS venga compresa, e quindi gestita correttamente, rispetto a una configurazione NAT arcana (IMO, ovviamente).
Soluzione 2:
Sono sorpreso che dopo quasi 8 anni nessuno abbia spiegato come farlo nel modo corretto utilizzando il sistema di configurazione UCI utilizzato di default in OpenWRT.
La risposta di Steven Monday è corretta, ma utilizza iptables comandi direttamente, che è un livello inferiore rispetto al sistema di configurazione UCI, ed è meglio non toccarlo dalla maggior parte degli utenti OpenWRT, se possibile.
Il modo corretto per accedere ai server interni tramite le loro combinazioni IP pubblico/porta da un altro host interno in UCI è abilitare l'opzione di configurazione reflection sotto ogni target DNAT specifico nel file /etc/config/firewall . Questo comportamento è documentato qui.
Ad esempio:
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp'
option src_dport '44322'
option dest_ip '192.168.5.22'
option dest_port '443'
option name 'apache HTTPS server'
option reflection '1'
Nota:Secondo la documentazione OpenWRT indicata, reflection è abilitato per impostazione predefinita. Nei miei test, non era così.
Soluzione 3:
Una soluzione comune consiste nell'indirizzare gli host interni a un server DNS locale che restituisce l'indirizzo "interno" corretto per questi nomi host.
Un'altra soluzione - e stiamo usando questo dove lavoro sui nostri firewall Cisco - è riscrivere le risposte DNS sul firewall che corrispondono a questi indirizzi. Non credo che al momento ci siano strumenti per Linux che lo facciano.
Dovresti essere in grado di configurare il routing sul tuo gateway per fare la cosa giusta. Potrebbe essere necessario configurare i server in modo che siano a conoscenza del loro indirizzo IP mappato esternamente (ad esempio, assegnandolo a un'interfaccia fittizia). Con questa configurazione, la comunicazione da un sistema interno a un altro sistema interno -- utilizzando il suo indirizzo "esterno" -- passerebbe attraverso il router.
Soluzione 4:
Quello che stai chiedendo di fare si chiama NAT Loopback e richiede che tu aggiunga una regola SNAT in modo che i pacchetti originati dalla tua LAN al tuo server ritornino attraverso il router:
-A POSTROUTING -p tcp -s 192.168.2.0/24 -d 192.168.2.10 -m multiport --dports 22,25,80,443 -j SNAT --to-source 89.179.245.232