IPTABLES, port redirect werkt half :)

[smeerbartje]

Ik heb hier een servertje met twee NICs, p1p1 = internal NIC, eth0 = WAN NIC. Deze server speelt ook als router hier in huis. So far so good. Nu heb ik op poort 7654 een golang http server draaien. Deze wil ik "van buitenaf" kunnen bereiken op poort 80. Dit probeer ik met een redirect te doen van poort 80 naar 7654. Dit lukt me redelijk. Op een externe locatie werkt het allemaal. Als ik op poort 80 probeer te verbinden, dan wordt het netjes geredirect naar poort 7654.

Maar nu het probleem: als ik vanuit een computer op het interne netwerk probeer om om poort 80 te verbinden, dan werkt het niet meer. Dus ik dacht: ik gooi het stukje "-i $wan_NIC" eruit, zodat niet alleen op de externe NIC, maar ook op de interne NIC de forwarding plaatsvindt. Niet dus . Nouja, AL het verkeerd dat de clients op poort 80 aanvragen wordt hiermee ge-redirect naar poort 7654.

Ik weet echt niet meer hoe ik dit op moet lossen. Ik heb het volgende script die m'n IPTABLES configureert:

Bash:

#!/bin/sh
# p1p1 = internal NIC
# eth0 = WAN NIC
lan_nic=p1p1
wan_nic=eth0

echo "Clear old firewall rules..."
iptables --flush
iptables --flush FORWARD
iptables --flush INPUT
iptables --flush OUTPUT
iptables --table nat --flush
iptables --table nat --delete-chain
iptables --table mangle --flush
iptables --table mangle --delete-chain
iptables --delete-chain

echo "Drop all INPUT and FORWARD..."
iptables -P INPUT DROP
iptables -P FORWARD DROP

echo "Drop all IPv6 traffic..."
ip6tables -P INPUT DROP
ip6tables -P OUTPUT DROP
ip6tables -P FORWARD DROP

echo "Accept everything on lo and $lan_nic (local network)..."
iptables -A INPUT -i lo -p all -j ACCEPT
iptables -A OUTPUT -o lo -p all -j ACCEPT
iptables -A INPUT -i $lan_nic -p all -j ACCEPT -s 192.168.1.0/24
iptables -A OUTPUT -o $lan_nic -p all -j ACCEPT -d 192.168.1.0/24

echo "IP Forwarding and Routing for gateway use..."
iptables -A FORWARD -o $wan_nic -i $lan_nic -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o $wan_nic -j MASQUERADE

echo "Enable Packet Forwarding..."
echo 1 > /proc/sys/net/ipv4/ip_forward

echo "Maintain established connections..."
iptables -A INPUT --in-interface $wan_nic --match conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT

echo "Configuration for redirected webserver in golang..."
iptables -t nat -I PREROUTING -i $wan_nic -p tcp --dport 80 -j REDIRECT --to-port 7654
iptables -A INPUT -i $wan_nic -p tcp --dport 7654 -m state --state NEW -j ACCEPT

[Hero of Time]

En hoe ben je tot de wijsheid gekomen van die laatste twee regels in je script? En waarom voer je regel 39 telkens uit, als je dat automatisch bij boot kan instellen via sysctl.conf?

Zelf denk ik dat je met -A FORWARD moet werken.

[smeerbartje]

Die laatste twee regels zijn een mix van eigen probeersels en gegoogled spul. En hoezo denk je dat ik dit script "telkens" uitvoer? Het is eenmalig namelijk. Als alles werkt, dus routing, forwarding, etc. dan sla ik de regels op. De uitvoer hiervan wordt tijdens startup geladen.

Maar dat was ook niet mijn vraag hé! Kun je een hint geven wat betreft port redirection? Waarom zou ik dit met -A forward kunnen fixen? Heb je een voorbeeld?

[gekkie]

Zie bijvb: http://knowhow.asu.ntu-kp...forwarding_with_netfilter
Jij geeft toestemming op de INPUT chain, maar hij gaat via de FORWARD ...

[Hero of Time]

smeerbartje schreef op donderdag 12 februari 2015 @ 23:31:
En hoezo denk je dat ik dit script "telkens" uitvoer? Het is eenmalig namelijk.

Nee, je voert 'm elke keer dat 't systeem start uit. Herstart je, dan moet je opnieuw die echo 1 > /sys/blabla uitvoeren. Daar is juist de optie in sysctl.conf voor.

Als alles werkt, dus routing, forwarding, etc. dan sla ik de regels op. De uitvoer hiervan wordt tijdens startup geladen.

Dat kan dus makkelijker.

Maar dat was ook niet mijn vraag hé! Kun je een hint geven wat betreft port redirection? Waarom zou ik dit met -A forward kunnen fixen? Heb je een voorbeeld?

Nu moet ik mijn antwoord onderbouwen terwijl jij een TS hebt die niets van dat soort aangeeft? Beetje omgekeerde wereld he? Ik heb iig met Google honderden hits gevonden door je vraag daar te stellen.

[smeerbartje]

gekkie schreef op donderdag 12 februari 2015 @ 23:39:
Zie bijvb: http://knowhow.asu.ntu-kp...forwarding_with_netfilter
Jij geeft toestemming op de INPUT chain, maar hij gaat via de FORWARD ...

Thanks!

Hero of Time schreef op vrijdag 13 februari 2015 @ 08:23:
[...]

Nu moet ik mijn antwoord onderbouwen terwijl jij een TS hebt die niets van dat soort aangeeft? Beetje omgekeerde wereld he? Ik heb iig met Google honderden hits gevonden door je vraag daar te stellen.

Jij haalt er allemaal zaken bij die helemaal niet relevant zijn! FYI: dit script draai ik eenmalig. Daarna doe ik m'n checks en sla ik de regels op met "iptables-save". Deze worden tijdens bootup ge-restored. Swa! Zo doe ik het. Boeien dat dat overbodig/dubbel/whatsoever is. Dat was niet mijn vraag.

Mijn vraag was om me te helpen met het fixen van de redirect. Blijkbaar teveel gevraagd.

[ Voor 44% gewijzigd door smeerbartje op 13-02-2015 10:35 ]

[Thralas]

Specificeer eens '-d $ROUTER', dan zou het wel moeten werken.

Overigens heeft REDIRECT side-effects die je (waarschijnlijk) helemaal niet nodig hebt noch verwacht, ik zou DNAT gebruiken...

[Ultraman]

smeerbartje schreef op vrijdag 13 februari 2015 @ 10:33:
Jij haalt er allemaal zaken bij die helemaal niet relevant zijn! FYI: dit script draai ik eenmalig. Daarna doe ik m'n checks en sla ik de regels op met "iptables-save". Deze worden tijdens bootup ge-restored.

Dan vervalt dus je setting van /proc/sys/net/ipv4/ip_forward, want enkel de configuratie van iptables wordt gerestored na reboot. En die ip_forward zal weer op de default van 0 komen te staan na een reboot.
Waardoor je packet forwarding niet meer zal werken zodra je de machine een keer herstart.
En als daar dan toevallig 2 maanden tussen zit, ben jij vergeten wat er speelde en zit je je af te vragen wat er in godsnaam mis is met die bak.

Swa! Zo doe ik het. Boeien dat dat overbodig/dubbel/whatsoever is. Dat was niet mijn vraag.
Mijn vraag was om me te helpen met het fixen van de redirect. Blijkbaar teveel gevraagd.

Hero of Time geeft antwoord op je vraag door te stellen dat je waarschijnlijk de FORWARD chain moet gebruiken ipv INPUT.
Vervolgens gaat hij verder door nauwkeurig te lezen uit jouw openingspost:

Ik heb het volgende script die m'n IPTABLES configureert

En geeft vervolgens aan dat je meer doet dan enkel iptables configureren. Je stelt namelijk ook een sysctl waarde in middels een echo. Als je zo'n instelling permanent wilt maken dan is het gebruikelijk om een regel in sysctl.conf te schrijven zodat je instelling reboot-vast wordt.

Waar hij dan een dergelijke behandeling verdient begrijp ik niet. Jij komt hier vragen om hulp, die krijg je plus nog wat extra tips en dan blaf je hem af omdat jij hem (denk ik) niet begrijpt? Zo gaan we hier niet met elkaar om, en ik mag hopen in de buitenwereld ook niet.

[ Voor 8% gewijzigd door Ultraman op 13-02-2015 10:49 ]