Accesso al server web DNAT dall'interno della LAN

Ho una piccola rete con un router, che mantiene una connessione a Internet, un server e alcune workstation in una rete locale.

Il server deve essere accessibile da Internet e ci sono diverse voci DNAT impostate nel router iptables, in questo modo:

-A PREROUTING -i ppp0 -p tcp -m multiport --dports 22,25,80,443 -j DNAT --to-destination 192.168.2.10

I pacchetti esterni arrivano al router tramite l' ppp0interfaccia e quelli interni ne derivano br-lan, che in realtà include lo switch e l'adattatore WLAN. Il problema è che, mentre l'accesso esterno funziona correttamente, il tentativo di accedere al server dall'interno della LAN tramite un IP esterno risolto da DNS (assegnato a ppp0) non riesce.

L'unica soluzione che sono stato in grado di inventare è aggiungere voci statiche al router che /etc/hostspunta all'IP interno, ma poiché non ci sono caratteri jolly (e ho almeno tre domini di primo livello assegnati a quel sistema, senza contare decine di sottodomini), è piuttosto croccante e soggetto a guasti. Puoi suggerire qualcosa di meglio?

Ho trovato solo questa domanda , che non è stata molto utile.

Se questo è rilevante, il router esegue OpenWRT 10.03 Kamikaze con dnsmasq.

Sono sorpreso che dopo quasi 8 anni, nessuno abbia spiegato come farlo nel modo corretto usando il sistema di configurazione UCI usato di default in OpenWRT.

La risposta di Steven Monday è corretta, ma utilizza iptablesdirettamente i comandi, che è un livello inferiore rispetto al sistema di configurazione UCI e, se possibile, non viene toccato dalla maggior parte degli utenti OpenWRT.

Il modo corretto di accedere ai server interni tramite le loro combinazioni IP / porta pubbliche da un altro host interno in UCI è abilitando l'opzione di configurazione reflectionsotto ogni destinazione DNAT specifica nel file /etc/config/firewall. Questo comportamento è documentato qui .

Per 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: in base alla documentazione OpenWRT indicata, reflectionè abilitato per impostazione predefinita. Nei miei test, questo non era il caso.

Ho cancellato la mia risposta originale, perché non ero del tutto sicuro che fosse corretta. Da allora ho avuto il tempo di creare 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-saveformato, solo per la nattabella):

-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

La prima POSTROUTINGregola è un modo semplice di condividere la connessione Internet con la LAN. L'ho lasciato lì per completezza.

La PREROUTINGregola e la seconda POSTROUTINGregola stabiliscono insieme i NAT appropriati, in modo che possano verificarsi connessioni al server tramite l'indirizzo IP esterno, 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 POSTROUTING che funzionano anche. Se la destinazione viene cambiata in -j SNAT --to-source 192.168.2.1, l'effetto è (non sorprendentemente) lo stesso di MASQUERADE: il server vede le connessioni dai client LAN locali come originate dall'indirizzo IP interno del router . D'altra parte, se la destinazione viene cambiata in -j SNAT --to-source 89.179.245.232, i NAT funzionano ancora, ma questa volta il server vede le connessioni dai client LAN locali come originate dall'indirizzo IP esterno del router (89.179.245.232).

Infine, nota che l'originale PREROUTING/ DNATregola con -i ppp0non funziona, perché la regola non corrisponde mai ai pacchetti provenienti dai client LAN (poiché quelli non entrano nel router tramite l' ppp0interfaccia). Sarebbe possibile farlo funzionare aggiungendo una seconda PREROUTINGregola solo per i client LAN interni, ma sarebbe inelegante (IMO) e dovrebbe comunque fare riferimento esplicitamente all'indirizzo IP esterno.

Ora, anche dopo aver presentato una soluzione NAT "a forcina" (o "loopback NAT", o "riflessione NAT", o qualunque cosa si preferisca chiamarla) in dettaglio, continuo a credere che una soluzione DNS split-horizon - -con client esterni che si risolvono in IP esterno e client interni che si risolvono in IP interno --- sarebbe la strada più consigliabile da prendere. Perché? Perché più persone capiscono come funziona il DNS che capire come funziona il NAT, e gran parte della costruzione di buoni sistemi sta scegliendo di utilizzare parti che sono gestibili. È più probabile che una configurazione DNS sia compresa, e quindi correttamente mantenuta, rispetto a una configurazione NAT arcana (IMO, ovviamente).

Una soluzione comune è quella di indirizzare gli host interni a un server DNS locale che restituisce l'indirizzo "interno" corretto per questi nomi host.

Un'altra soluzione - e la stiamo usando dove lavoro sui nostri firewall Cisco - è riscrivere le risposte DNS sul firewall che corrispondono a questi indirizzi. Non penso che ci siano strumenti per Linux che lo fanno proprio ora.

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 consapevoli del loro indirizzo IP mappato esternamente (ad es. Assegnandolo a un'interfaccia fittizia). Con questa configurazione, la comunicazione da un sistema interno a un altro sistema interno - usando il suo indirizzo "esterno" - passerebbe attraverso il router.

Quello che stai chiedendo di fare è chiamato NAT Loopbacke richiede che tu aggiunga una regola SNAT in modo che i pacchetti originati dalla tua LAN al tuo Server tornino indietro 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

Il commento di larsks sull'hosting di una versione interna dello spazio dei nomi \ domain è generalmente il modo in cui ho gestito questo problema in passato. Naturalmente, per farlo è necessario un server DNS interno.

Ho trovato la seguente soluzione per consentire alla mia rete ospite di connettersi alle porte che sono state inoltrate dalla mia rete WAN a LAN. Questo script è inserito nella mia sezione "Rete -> Firewall -> Regole personalizzate":

# lookup the public IP (DDNS resolves to this)
wanip=$(ip route get 8.8.8.8 | awk -F"src " 'NR==1{split($2,a," ");print a[1]}')

# Guest network to LAN
# srcname is the guest network name, this needs to match for iptables
srcname=guest
# CIDR notation of guest and lan networks
srcnet=192.168.15.0/24
tgtnet=192.168.10.0/24
# router (openwrt) IP on lan network
tgtrouter=192.168.10.1
# host on lan network where ports are normally forwarded
tgthost=192.168.10.5
# ports to forward as a list or range
tcpports=8080,9090
udpports=12345

prechain=prerouting_${srcname}_rule
postchain=postrouting_${srcname}_rule

# reset the tables to prevent duplicate rules
iptables -t nat -F ${prechain}
iptables -t nat -F ${postchain}

iptables -t nat -A ${prechain} -s ${srcnet} -d ${wanip}/32 -p tcp -m tcp -m multiport --dports ${tcpports} -m comment --comment "${srcname} NAT reflection TCP DNAT" -j DNAT --to-destination ${tgthost}
iptables -t nat -A ${postchain} -s ${srcnet} -d ${tgthost}/32 -p tcp -m tcp -m multiport --dports ${tcpports} -m comment --comment "${srcname} NAT reflection TCP SNAT" -j SNAT --to-source ${tgtrouter}
iptables -t nat -A ${prechain} -s ${srcnet} -d ${wanip}/32 -p udp -m udp -m multiport --dports ${udpports} -m comment --comment "${srcname} NAT reflection UDP DNAT" -j DNAT --to-destination ${tgthost}
iptables -t nat -A ${postchain} -s ${srcnet} -d ${tgthost}/32 -p udp -m udp -m multiport --dports ${udpports} -m comment --comment "${srcname} NAT reflection UDP SNAT" -j SNAT --to-source ${tgtrouter}

Per supportare i riavvii, avevo bisogno di eseguire quanto segue dalla riga di comando ssh su openwrt (altrimenti, credo che ci sia una condizione di competizione in cui alcune regole sono state aggiunte e quindi scaricate durante il riavvio):

uci set firewall.@include[0].reload="1"
uci commit firewall

NAT reflection è impostato per le connessioni all'interno della rete LAN a se stesso, ma non ad altre reti se sono state create più interfacce per isolare il traffico. Ho provato a configurare una regola di inoltro dall'interfaccia Web, ma che invia tutto il traffico a una porta dalla rete ospite a quell'host LAN. Quanto sopra intercetta solo le richieste all'IP WAN invece di tutto il traffico di rete.

È possibile utilizzare un DNS interno anziché questo, ma solo se tutti i port forwarding passano solo a un singolo host. Se si dispone di più host in cui si inoltrano porte diverse, è possibile ripetere le regole per porte diverse su tgthostIP e porte diverse.