PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : iptables Problem



jano
19.10.10, 00:46
Hallo,

habe mal wieder ein kleines Problem mit den guten iptables:

Sämtlicher Verkehr, der auf der openSuSe-11.3-Kiste auf Port 4407 ankommt soll an die IP-Adresse 192.168.0.255 (Broadcastadresse) auf UDP-Port 7 weitergeleitet werden.

Probiert habe ich es mit folgenden Einstellungen:


echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p udp --dport 4407 -j DNAT --to 192.168.0.255:7
iptables -A FORWARD -p udp --dport 7 -j ACCEPT


Leider kein Erfolg...

Der Linux-Rechner arbeitet NICHT als Router, hat nur ein Interface und befindet sich normal im Netzwerk

Weiß vielleicht jemand weiter?

Gruß
Jan

blubbersuelze
20.10.10, 01:53
Hi,
wenn ich folgendes als Regel eingebe nimmt er Sie an mach sonst mal alle Firewallregeln auf die im moment aktiv sind.

iptables -t nat -A PREROUTING -p udp --dport 4407 -j DNAT --to-destination 192.168.0.255:7

mfg.
blubbersuelze :p

jano
20.10.10, 12:50
Also im Moment sind folgende iptables Regeln aktiv:



Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination
LOG udp -- anywhere anywhere udp dpt:4407 limit: avg 1/sec burst 1 LOG level info prefix `# FORWARD-Firewall #'
LOG udp -- anywhere anywhere udp dpt:7 limit: avg 1/sec burst 1 LOG level info prefix `# FORWARD-Firewall #'

Chain OUTPUT (policy ACCEPT)
target prot opt source destination



Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT udp -- anywhere anywhere udp dpt:4407 to:192.168.0.255:7

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination


Angenommen wird alles einwandfrei, leider aber nichts weitergeleitet.
/var/log/firewall bleibt leer, während testweise geloggte Inputs auf dem SSH-Port einwandfrei in diese Datei geloggt werden.


Gruß
Jan

blubbersuelze
20.10.10, 21:35
wenn du die FORWARD-Regeln raus nimmst sollte es eigentlich gehen ...
probiere doch das alles erst einmal mit einem lockeren Filter, sprich nur Umleiten auf Broadcast Port 7 und dann mach Stück für Stück weitere Regeln hinzu und nicht gleich alles auf einmal..

Grüße :-)

jano
20.10.10, 23:02
Die FORWARD Regeln sind ja nur zum loggen, um zu schauen ob es auch funktioniert.
Oder ändert das etwas?

Gruß
Jan

blubbersuelze
20.10.10, 23:53
da die Pakete bei den Loggingrules matchen .. werden sie nicht mehr weiter gereicht ...

iptables fängt bei rule1 an und geht alle rules der Reihe nach durch .. beim ersten Match für das zu behandelnde Paket wird der Match abgearbeitet und es wird nicht mehr weitergemacht mit diesem Paket ...

von daher kann das gut daran liegen

Rain_maker
24.10.10, 12:28
Nur mal so am Rande bemerkt:



## Type: string
#
# 14.)
# Which services accessed from the internet should be allowed to masqueraded
# servers (on the internal network or dmz)?
# Requires: FW_ROUTE
#
# With this option you may allow access to e.g. your mailserver. The
# machines must be in a masqueraded segment and may not have public
# IP addesses! Hint: if FW_DEV_MASQ is set to the external interface
# you have to set FW_FORWARD from internal to DMZ for the service as
# well to allow access from internal!
#
# Please note that this should *not* be used for security reasons!
# You are opening a hole to your precious internal network. If e.g.
# the webserver there is compromised - your full internal network is
# compromised!
#
# Format: space separated list of
# <source network>,<ip to forward to>,<protocol>,<port>[,redirect port,[destination ip]]
#
# Protocol must be either tcp or udp
#
# Examples: - "4.0.0.0/8,10.0.0.10,tcp,80" forward all tcp request on
# port 80 coming from the 4.0.0.0/8 network to the
# internal server 10.10.0.10
# - "4.0.0.0/8,10.0.0.10,tcp,80,81" forward all tcp request on
# port 80 coming from the 4.0.0.0/8 network to the
# internal server 10.10.0.10 on port 81
# - "200.200.200.0/24,10.0.0.10,tcp,80,81,202.202.202.202"
# the network 200.200.200.0/24 trying to access the
# address 202.202.202.202 on port 80 will be forwarded
# to the internal server 10.0.0.10 on port 81
#
# Note: du to inconsitent iptables behaviour only port numbers are possible but
# no service names (https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=273)
#
FW_FORWARD_MASQ=""

## Type: string
#
# 15.)
# Which accesses to services should be redirected to a local port on
# the firewall machine?
#
# This option can be used to force all internal users to surf via
# your squid proxy, or transparently redirect incoming webtraffic to
# a secure webserver.
#
# Format: list of <source network>[,<destination network>,<protocol>[,dport[:lport]]
# Where protocol is either tcp or udp. dport is the original
# destination port and lport the port on the local machine to
# redirect the traffic to
#
# An exclamation mark in front of source or destination network
# means everything EXCEPT the specified network
#
# Example: "10.0.0.0/8,0/0,tcp,80,3128 0/0,172.20.1.1,tcp,80,8080"
#
# Note: contrary to previous SuSEfirewall2 versions it is no longer necessary
# to additionally open the local portZumindest sicher einfacher zu testen als irgendwelche von Hand zusammengebastelten iptables-Regeln.

Das "local" in 15) scheint mir anhand der Beispiele keine wirkliche Einschränkung zu sein, das sollte auch auf eine andere Maschine "umgebogen" werden können.

jano
27.10.10, 14:24
ohne die Logging-Rules tut sich auch nichts.
Weiß jemand weiter?

Gruß
Jan

blubbersuelze
27.10.10, 20:56
hast du es mal versucht statt an den Broadcast, erst mal an eine gezielte IP-Adresse zu schicken ob da was passiert?
Das ist wesentlich einfach zu handlen

lasse doch mal tcpdump mitlaufen um zu sehen ob auf dem Port wirklich nichts passiert ...

was soll eigentlich überhaupt darüber versendet werden??

jano
27.10.10, 23:30
Hallo,

danke, werde ich mal versuchen.

Es geht darum einen Rechner im LAN aus dem Internet aufzuwecken mittels MagicPacket.
Vom Lokalen Server aus funktioniert es optimal.
Leider unterstützt der Router (Netgear FVS 318v3) keine Portweiterleitung an die Broadcastadresse, daher versuche ich das MagicPacket erst an eine gültige IP (hier der Lokale Server) und von da aus an die Broadcastadresse weiterzuleiten.

Was ich noch vergessen hatte zu erwähnen, was evtl. doch wichtig sein könnte.
Der Lokale Server besitzt zwei Netzwerkadapter die mittels bonding zu einem Interface (bond0) im mode0 (round robin) zusammengefasst sind.

Gruß
Jan