
|
|
Besucher 1260506 Ansichten 2645 Online 0 |
|
 |
DNAT mit UDP ohne conntrack?
| |
| Thema |
Verfasser |
Letzte Antwort |
| DNAT mit UDP ohne conntrack? |
simu ( ---.dip0.t-ipconnect.de) |
31 Aug 2009 06:23 | Hallo,
ich möchte mit iptables und DNAT einen "Proxy" aufbauen. Abhängig von der ankommenden IP soll das Paket auf eine bestimmte IP:Port weitergeleitet werden.
Beispiel:
iptables -t nat -A PREROUTING -p udp -s 80.34.34.55 -i eth0 --dport 1194 -j DNAT --to 11.0.0.1:1194
Das funktioniert grundsätzlich, nur dass man immer die ip_conntrack_udp_timeout abwarten muss. Gibt es eine andere Möglichkeit UDP-Pakete in Abhängigkeit Ihrer Source-IP an bestimmte IP:Port weiterzuleiten?
Am liebsten wäre mir eigentlich ein UDP-Proxy mit einer Tabellendatei "Source-IP Ziel-IP Ziel-Port".
Freue mich über jeden Ansatz.
Vielen Dank.
Gruß
Sigi |
| ||
| RE: DNAT mit UDP ohne conntrack? | Ralf ( ---.dip.t-dialin.net) | 29 Aug 2009 08:50 |
Auch der ip-Befehl kann Natten. Alternativ kannst Du den Timeout reduzieren:
Abhängig von der Kernelversion entweder in:
/proc/sys/net/ipv4/netfilter/
oder
/proc/sys/net/netfilter
Allerdings verstehe ich das grundsätzliche Problem nicht. Der Timeout gilt doch immer nur für die Verbindung. Und Du willst ja nicht einzelne Pakete einer Verbindung an verschiedene Ziele natten, oder?
Gruß,
Ralf
| | RE: DNAT mit UDP ohne conntrack? | simu ( ---.dip0.t-ipconnect.de) | 31 Aug 2009 06:10 |
Aber UDP ist doch nicht Verbindungsorientiert!?
Conn_track speichert wohl die Portnummer ab und erkennt damit die Verbindung?
Ich möchte zu einem Zeitpunkt X das Weiterleitungsziel ändern. Mit UDP muss ich immer warten bis der Timeout abgelaufen ist. Die Timeouteinstellung wollte ich eigentlich nicht ändern, um andere Programm nicht zu beeinflussen.
Gruß
Sigi | | RE: RE: DNAT mit UDP ohne conntrack? | Ralf ( ---.dip.t-dialin.net) | 31 Aug 2009 06:23 |
Das ist richtig. UDP ist als Protokoll nicht verbindungsorientiert. Dennoch behandelt Conntrack UDP als Stream.
Erkennt Conntrack ein UDP-Paket, welches noch nicht in der Conntrack-Tabelle ist, erhält des den Zustand NEW. Wird es akzeptiert, so wird die "Verbindung"/Stream in der Conntrack-Tabelle eingetragen. Timeout: 30s (/proc/sys/net/netfilter/nf_conntrack_udp_timeout)
Kommt innerhalb von 30 Sekunden eine Antwort auf das UDP-Paket so erhält es den Zustand ESTABLISHED. Die Verbindung bekommt als neuen Timeout 180s (/proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream) Das heisst, so lange spätestens alle 180s ein entsprechendes Paket in eine der beiden Richtungen fliest, bleibt die Verbindung erhalten. NAT wir nur einmalig bei dem ersten Paket entschieden. Alle weiteren Pakete gehorchen dieser ersten Entscheidung. Ist ja auch sinnvoll. Wenn ich über UDP telefoniere, dürfen sich die IP-Adressen nicht ändern.
ICMP-Ping wird übrigens genauso von Conntrack behandelt:
/proc/sys/net/netfilter/nf_conntrack_icmp_timeout
Auch alle anderen Protokolle (BGP, ESP, etc): /proc/sys/net/netfilter/nf_conntrack_generic_timeout
Hier gibt es allerdings nur einen Timeout und nicht das Konzept des Streams.
Wenn Du das verhindern möchtest, kannst Du die Raw-Tabelle und das UNTRACK Ziel verwenden. Lies mal hier:
http://www.os-t.de/PDFs_FW/3827321360%20Kapitel%2022.pdf
Gruß,
Ralf |
[ Zurück ] Um ein neues Thema hinzu zu fügen müssen sie eingeloggt sein.
|
 |

|
|
Welche Distribution verwenden Sie?
|
|
|
 |