netfilter und tftp, wo ist der Haken?

09/08/2016 - 22:06 von Marc Haber | Report spam
Hallo,

gegeben sei eine Linux-Firewall mit zwei Interface, Kernel 4.7 und
iptables. Ein tftp-Client (IP-Adresse 192.168.188.163) am einen
Interface möchte mit einem Server am anderen Interface (IP-Adresse
192.168.181.100) sprechen.

Die relevanten Regeln sind:

|Chain FORWARD (policy DROP 0 packets, 0 bytes)
| pkts bytes target prot opt in out source destination
| 668 34071 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
| 322K 250M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
| 9 542 int181out all -- * int181 0.0.0.0/0 0.0.0.0/0
| 354 30808 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix "forward "
| 354 30808 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable


|Chain int181out (1 references)
| pkts bytes target prot opt in out source destination
| 9 542 ACCEPT udp -- int188 * 0.0.0.0/0 192.168.181.100 udp dpt:69

Auf dem Interface des Servers gedumped sieht man den folgenden
Traffic:

192.168.181.163:2078 UDP => 192.168.181.100:69
192.168.181.100:48583 UDP => 192.168.181.163:2078
Firewall => 192.168.181.100 "ICMP port unreachable"

Im Log landet:
|Aug 9 20:38:17 barrida kernel: forward IN=int181 OUT=int188 MAC=9a:3d:9f:63:27:ac:52:54:00:93:ff:c8:08:00:45:00:00:2f SRC2.168.181.100 DST2.168.188.163 LENG TOS=0x00 PREC=0x00 TTLc IDP29 DF PROTO=UDP SPTH583 DPT 78 LEN'

Man beachte den Log-Prefix, aus dem man sehen kann, dass wirklich die
REJECT-Regel am Ende der FORWARD-Chain angeschlagen hat.

Das nf_conntrack_tftp Modul ist geladen, und der Router wurde
gebootet, um eventuell noch vor dem Laden des Moduls in der Tabelle
gelandete conntrack-Eintràge sicher entfernt zu haben.

Ich meine mich aus der Vergangenheit daran zu erinnern, dass auch die
Reihenfolge von "modul wird geladen" und "Regel wird eingetragen" eine
Rolle spielt und dass das Modul irgendwelche schràgen Parameter
braucht. Andererseits funktioniert es auf einem (àlteren)
Referenzsystem genau so.

Webrecherche zu diesem Thema ist schmerzhaft. Von "mach permit any
any" bis hin zu "lad mal nf_conntrack_ftp, vielleicht funktioniert es
dann" findet man da alles, aber nichts konkretes.

Any ideas?

Grüße
Marc
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
 

Lesen sie die antworten

#1 Sven Hartge
09/08/2016 - 22:20 | Warnen spam
Marc Haber <mh+ wrote:

gegeben sei eine Linux-Firewall mit zwei Interface, Kernel 4.7 und
iptables. Ein tftp-Client (IP-Adresse 192.168.188.163) am einen
Interface möchte mit einem Server am anderen Interface (IP-Adresse
192.168.181.100) sprechen.



[...]

Any ideas?



Hast du folgende Meldung im Log/dmesg:

nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.

Kernel 3.16 bringt die, evtl. ist Kernel 4.7 schon über die "removed
soon"-Phase hinaus und du musst deine Regeln erweitern, damit es
funktioniert.

https://home.regit.org/netfilter-en...f-helpers/

(Und wenn es dann so ist, so poste bitte deine Lösung, danke.)



Sigmentation fault. Core dumped.

Ähnliche fragen