port forward i iptable

først af alt, så er din firewall ikke særlig sikker - alle default regler er accept!!

port forware er formentlig fra internet til en lokal server på LAN (jeg gætter) - reglen hedder:

iptables -A FORWARD -j ACCEPT -p tcp --dport 80
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.0.10:80

hvis det er web-trafik fra eth0 (internet) som skal sendes til 192.168.0.10

hvilket også er hvad du har skrevet :-(

Jeg tror du skal prøve nedenstående - og så bygge videre på det.

#!/bin/sh

# iptables script generator: V0.1-2002
# Comes with no warranty!
# e-mail: michael@1go.dk

# Diable forwarding
echo 0 > /proc/sys/net/ipv4/ip_forward

LAN_IP_NET='192.168.0.1/24'
LAN_NIC='eth1'
WAN_IP='x.x.x.x'
WAN_NIC='eth0'
FORWARD_IP='192.168.0.10'

# load some modules (if needed)

# Flush
iptables -t nat -F POSTROUTING
iptables -t nat -F PREROUTING
iptables -t nat -F OUTPUT
iptables -F

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# enable Masquerade and forwarding
iptables -t nat -A POSTROUTING -s $LAN_IP_NET -j MASQUERADE
iptables -A FORWARD -j ACCEPT -i $LAN_NIC -s $LAN_IP_NET
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# STATE RELATED for router
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Open ports to server on LAN
iptables -A FORWARD -j ACCEPT -p tcp --dport 80
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.0.10:80

# Enable forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

vær opmærksom på, at ovenstående ændrer lidt, da det benytter MASQUERADE i stedet for SNAT - som du bruger i dit script.

Som lap skriver er det du skal bruge:
iptables -t nat -A PREROUTING -i ethx -p tcp --dport <port> -j DNAT --to <ip>:<port>
Hvor ethx er dit offentelige interface.

Hvis du sætter default FORWARD rule til DENY el. REJECT, hvilket du bør gøre, det samme med input, skal du bruge:
iptables -A FORWARD -p tcp --dport <port> -j ACCEPT

Ellers prøv at tage et kig på http://rk.snulvin.net/packetmangler. Det er et script jeg er ved at udvikle, som udover NAT også indeholder QoS/traffic shaping. Det er ikke færdigt, men det skulle være brugbart som det er nu. Du er velkommen til at bruge af det hvad du vil.

takker, smid lige et svar lap.

rocekiller -> Meget interessant (Kjente ikke til denne muligheten for trafikkshaping)
Legger en link som referanse: http://www.groupedia.com/node/view/118

svar :-)

Hvis du er virkelig er intereseret i at sætter dig ind i hvad linux routing kan, så kan jeg kun anbefale at kigge på/læse Linux Advanced Routing & Traffic Control HOWTO (http://lartc.org/howto/). Den er fortrindelig, men også lidt langhårdet. Wondershaper er også et af de bedre scripts lavet i anledning af LARTC blev lavet, dog synes jeg den har nogle fejl. Hvilket er derfor jeg er ved at skrive min egen version.

For at gå lidt i detaljer. Så er det helt store problem med traffic shaping at man ikke kan shape indkommene traffik, men kun udgåene. Hvilket også er meget logisk, da du jo ikke har styr over hvad du modget, men godt hvad du afsender. Løsningen er at du på din gateway shaper upload mod lan (downloade fra internet i forhold til LAN), og din upload mod inet (upload til internet i forhold til lan). _Men_, de fleste scripts du kan finde online, inkl. det du sendte link til, er kun beregnet til at kører på en computer som sidder på en ADSL. Ikke på en gateway som har 2+ netkort. Den kan saktens kører derpå, men du får slet ikke den forbedring som du kan få.

Et teoretisk eksempel på hvad du kan vinde ved ordenlig traffic shaping. Hvis du sætter en upload igang som bruger hele din upload bånbredde, og efterfølgene starter en download som ligeledes bruger hele din bånbredde, så skulle din ssh sideløbene være istand til at køre uden noget mærkbart lag. Det kan lade sig gøre, og det er hele formålet med mit script.

Mit script virker som det er nu, det sætter som det er nu 3 prioriteter op, lav, normal og høj. _Men_, det filterer ingen traffik i de forskellige prioriteter, så det fungere kun som simpel traffic shaping i form af dens outgress (traffic shaping mod upload), hvilket også kan mærket forholdsvis, dog kan et p2p program stadig sluge hele linien. Løsningen er at få p2p placeret i det laveste filter, og fx http i normal og ssh i høj. På den måde vil ssh _altid_ have højere prioritet end diverse p2p programmer. Det kan gøres med iptables-p2p som forefindes på sourceforge, kan være du har interesse i at kigge på den, det eneste den ikke rigtig kan matche ordenligt er winmx.

Et parktisk eksempel, hvis jeg fra min computer starter en upload mod nettet for fulde drøn, uden noget TC får jeg ping tider til fx googl.com på omkring:

$ ping google.com -c 4
PING google.com (216.239.37.99) 56(84) bytes of data.
64 bytes from 216.239.37.99: icmp_seq=1 ttl=243 time=1169 ms
64 bytes from 216.239.37.99: icmp_seq=2 ttl=243 time=1031 ms
64 bytes from 216.239.37.99: icmp_seq=3 ttl=243 time=1212 ms
64 bytes from 216.239.37.99: icmp_seq=4 ttl=243 time=1073 ms

Efter start af et simpelt traffic shaping script, http://rk.snulvin.net/shape, som egentlig ikke gør andet end at skifte den default outgress kø type til sfq (Stochastic Fairness Queueing) fremfor fifo (First In First Out). Med 109kbit max mod gatewayen (og derfor også mod nettet), og 70mbit max mod resten af LAN. Får jeg pingtider på omkring:

$ ping google.com -c 4
PING google.com (216.239.39.99) 56(84) bytes of data.
64 bytes from 216.239.39.99: icmp_seq=1 ttl=242 time=546 ms
64 bytes from 216.239.39.99: icmp_seq=2 ttl=242 time=286 ms
64 bytes from 216.239.39.99: icmp_seq=3 ttl=242 time=272 ms
64 bytes from 216.239.39.99: icmp_seq=4 ttl=242 time=280 ms

Hvilket da er en flot forbedring, men den kan gøres _meget_ bedre med at ordenlig opsat traffic shaping script på gatewayen.

Håber jeg har vækket din interesse for traffic shaping ;). Og håber det er forståligt hvad jeg har skrevet. Hvis du har andre/uddybene spørgsmål så spørg endelig, så skal jeg se om jeg kan svare.

Takker for interessant info :)