Hallo,
ich habe auf einer Firewall ein aktuelles Stretch,
der Kernel sieht so aus:
$ uname -a
Linux tigger-a 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux
$ modinfo nf_conntrack_ftp
filename: /lib/modules/4.9.0-4-amd64/kernel/net/netfilter/nf_conntrack_ftp.ko
alias: nfct-helper-ftp
alias: ip_conntrack_ftp
description: ftp connection tracking helper
author: Rusty Russell <rusty@rustcorp.com.au>
license: GPL
depends: nf_conntrack
intree: Y
vermagic: 4.9.0-4-amd64 SMP mod_unload modversions
parm: ports:array of ushort
parm: loose:bool
Hinter dieser Firewall steht ein FTP-Server. Die relevanten
Firewallrules habe ich versucht, so isolieren:
iptables -I FORWARD -s x.x.x.x -j testing
Chain testing (1 references)
pkts bytes target prot opt in out source destination
75 4628 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
6 340 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
5 300 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Damit sollte FTP eigentlich gehen. Früher ging es auch (aber da war
diese Regel noch nicht drin, sondern etwas komplexere Regeln.)
Vermutlich seit dem letzten Reboot (Kernel-Update?) geht das
Connection-Tracking für das FTP nicht mehr. (Ähnliche Symptome habe ich
mit Clients hinter einer aktuellen Stretch-Firewall, aber den o.a.
Test habe ich von einem anderen Host mit einer öffentlichen Adresse
gemacht.) Es ist also kein NAT im Spiel.
Es sieht schlicht so aus, als wenn der Port, den der FTP-Server öffnet,
nicht in der Firewall durch „RELATED“ abgedeckt wird:
---> USER www.sempa.de
<--- 331 Password required for www.sempa.de
---> PASS XXXX
<--- 230 User www.sempa.de logged in
---> PWD
<--- 257 "/" is the current directory
---> EPSV
<--- 229 Entering Extended Passive Mode (|||15278|)
---- Connecting data socket to (212.80.235.133) port 15278
**** Data socket error (Connection refused) - reconnecting
Im Passive Mode (Also nur PASV, nicht EPSV) ist es vergleichbar.
Nun habe ich
https://lists.debian.org/debian-kernel/2017/08/msg00006.html
gefunden, da steht im Follow-Up, daß das gelöst wäre.
Kenn jemand das eine oder das andere bestätigen?
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
Attachment:
signature.asc
Description: PGP signature