Come eseguire il port forwarding da un IP a un altro IP nella stessa rete?

Vorrei fare un po ' NATdi iptables. In questo modo, tutti i pacchetti in arrivo 192.168.12.87e port 80verranno inoltrati alla 192.168.12.77porta 80.

Come fare questo con iptables?

O

Altri modi per ottenere lo stesso?

Queste regole dovrebbero funzionare, supponendo che iptablessia in esecuzione sul server 192.168.12.87:

#!/bin/sh

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -F
iptables -t nat -F
iptables -X

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77:80
iptables -t nat -A POSTROUTING -p tcp -d 192.168.12.77 --dport 80 -j SNAT --to-source 192.168.12.87

Devi DNAT il traffico in entrata sulla porta 80, ma dovrai anche SNAT il traffico di ritorno.

Alternativa (e migliore approccio IMHO):

A seconda di ciò che è il tuo server Web (Apache, NGinx) dovresti considerare un proxy HTTP sul tuo server front-end (192.168.12.87):

• mod_proxy (Apache)

• proxy_pass (NGinx)

Il motivo per cui un'apparente ovvia iptables -t nat -A PREROUTING -d 192.168.12.87 -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77non funzionerà è come verranno instradati i pacchetti di ritorno.

È possibile impostare regole che indurranno semplicemente i pacchetti inviati a 192.168.12.87 a essere NATted a 192.168.12.77, ma 192.168.12.77 invierà quindi le risposte direttamente al client. Quelle risposte non passeranno attraverso l'host in cui la regola iptables esegue NAT, quindi i pacchetti in una direzione vengono tradotti, mentre i pacchetti nell'altra direzione no.

Esistono tre approcci per risolvere questo problema.

1. Sul primo host non si esegue solo DNAT, ma si esegue anche SNAT in modo tale che il traffico di ritorno venga rispedito attraverso il primo host. La regola potrebbe assomigliare a qualcosaiptables -t NAT -A POSTROUTING -d 192.168.12.77 -p tcp --dport 80 -j SNAT --to-source 192.168.12.87
2. Prendi ispirazione dal bilanciamento del carico DSR e DNAT i pacchetti a livello Ethernet anziché a livello IP. Sostituendo il MAC di destinazione dei pacchetti con il MAC di 192.168.12.77 e inviandolo su Ethernet senza toccare il livello IP, 192.168.12.77 potrebbe avere 192.168.12.77 configurato su un'interfaccia fittizia e quindi essere in grado di terminare la connessione TCP con l'IP del server noto al client.
3. Utilizzare la soluzione ingenua (ma non funzionante) sul primo host. Quindi gestire i pacchetti di ritorno sul secondo host eseguendo un SNAT sul traffico di ritorno. Potrebbe apparire una regolaiptables -t nat -A OUTPUT -p tcp --sport 80 -j SNAT --to-source 192.168.12.87

Ognuna di queste tre soluzioni presenta degli svantaggi, quindi è necessario considerare attentamente se è necessario eseguire questo specifico inoltro.

1. L'uso di SNAT perderà l'IP client, quindi l'host numero 2 penserà che tutte le connessioni provengano da 192.168.12.87. Inoltre, utilizzerai la larghezza di banda tramite l'host numero 1 per tutti i pacchetti di risposte, il che prenderebbe un percorso più diretto con gli altri approcci.
2. L'approccio DSR interromperà tutte le altre comunicazioni tra i due nodi. L'approccio DSR è davvero appropriato solo quando l'indirizzo del server non è l'IP principale di nessuno degli host. Ogni host deve avere un IP primario, che non è l'IP DSR.
3. L'uso del tracciamento della connessione su un host per tradurre in una direzione e il tracciamento della connessione su un altro host per la traduzione nell'altra direzione è semplicemente brutto e ci sono vari modi in cui potrebbe rompersi. Ad esempio, se i numeri di porta vengono modificati da NAT su uno degli host, non è possibile ricostruirli. Inoltre, non è un dato di fatto che il tracciamento della connessione funzionerà correttamente, se il primo pacchetto che vede è un SYN-ACK piuttosto che un ACK.

Dei tre approcci penso che il primo sia quello che è più probabile che funzioni. Quindi, se non hai bisogno di conoscere gli indirizzi IP del client, è quello che consiglierei.

Puoi anche scegliere di dimenticare del tutto il NAT e non provare a risolvere il problema sul livello MAC o IP. Puoi andare fino al livello HTTP e cercare una soluzione lì. In tal caso la soluzione che troverai è un proxy HTTP. Se si installa un proxy HTTP su 192.168.12.87 e lo si configura in modo appropriato, è possibile farlo inoltrare le richieste a 192.168.12.77 e inoltrare le risposte indietro. Inoltre, può inserire un'intestazione X-Forwarded-For preservando l'IP client originale. Il server su 192.168.12.77 deve quindi essere configurato per fidarsi dell'intestazione X-Forwarded-For da 192.168.12.87.