Ich stoße hier an eine Wand und versuche, TFTP mit RHEL 6 als Server zum Laufen zu bringen. Der Fehler vom Client ist einfach "Zeitüberschreitung der Übertragung". Auf dem Server kann ich sehen, dass UDP 69-Datenverkehr von meinem Client eingeht, aber ich sehe keine Pakete, die zum Client zurückkehren. In den Protokollen sehe ich, dass xinetd die Anfrage bearbeitet. Auf dem Server verwende ich die TFTP-Version:
tftp-server-0.49-8.el6.x86_64
Hier ist der Befehl, den ich vom Client aus ausführe.
tftp -v 192.168.100.10 -c get file
Tcpdump Server Seite:
13:54:02.136438 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 49)
192.168.100.11.37126 > 192.168.100.10.tftp: [udp sum ok] 21 RRQ "file" netascii
Und das wiederholt sich immer wieder, bis die Übertragung abgelaufen ist. Hier ist meine Logdatei:
Jul 26 13:54:22 server in.tftpd[7068]: RRQ from 192.168.100.11 filename file
Und das wiederholt sich auch immer wieder, bis die Übertragung abgelaufen ist. Meine Konfiguration:
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -v -v -v -s /var/lib/tftpboot
per_source = 11
cps = 100 2
flags = IPv4
}
Die Iptables-Regel befindet sich oben:
[root@server tftpboot]# iptables -L --line-numbers | grep tftp
1 ACCEPT udp -- anywhere anywhere state NEW udp dpt:tftp
Kernelmodule werden geladen:
[root@server tftpboot]# lsmod | grep tftp
nf_conntrack_tftp 4814 0
nf_conntrack 79537 4 nf_conntrack_tftp,nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state
SELinux ist freizügig:
[root@server tftpboot]# getenforce
Permissive
Ich habe alles in hosts.allow erlaubt:
xinetd : ALL
Und ich weiß, dass der Service zuhört:
[root@server tftpboot]# lsof -i :69
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
in.tftpd 7023 root 0u IPv4 11763412 0t0 UDP *:tftp
xinetd 32761 root 5u IPv4 11763412 0t0 UDP *:tftp
[root@server tftpboot]# netstat -anp | grep ":69"
udp 0 0 0.0.0.0:69 0.0.0.0:* 7023/in.tftpd
world hat RX im tftpboot-Verzeichnis:
[root@server lib]# ll | grep tftp*
drwxr-xr-x. 2 root root 4096 Jul 26 12:17 tftpboot
Und die Welt hat die Akten darin gelesen. Andere Dinge habe ich versucht.
1) Verwenden von tcp anstelle von udp = FAIL
2) Verschieben des TFTP-Stammverzeichnisses = FAIL
3) Und wie Sie sehen, ist die ausführliche Protokollierung für TFTP bereits aktiviert
4) Ändern Sie den Benutzer in der Konfiguration = FAIL
Ich bin zu diesem Zeitpunkt ratlos. Hat jemand dieses Problem schon einmal angetroffen?
UPDATE: Hier ist meine vollständige Iptables-Konfiguration:
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1:136]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 69 -m state --state NEW,ESTABLISHED - j ACCEPT
-A INPUT -j DROP
COMMIT
Außerdem habe ich iptables deaktiviert und erhalte immer noch die gleiche Zeitüberschreitungsnachricht.
UPDATE # 2 - Ich habe auch das Folgende in iptables hinzugefügt, aber iptables ist nicht glücklich.
-A INPUT --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT
Error:
iptables: Applying firewall rules: iptables-restore v1.4.7: unknown option `--sport'
UPDATE # 3
Nicht, dass das helfen könnte, aber ich war neugierig zu sehen, ob ich tatsächlich verwandte Pakete gesehen habe, die die Firewall kamen und verließen. Hier ist ein Schnappschuss der beiden Regeln, die ich eingefügt habe, um sowohl 69 zum und vom Client als auch die für die Datenübertragung benötigten Ports zuzulassen.
Vor dem Beginn der Übertragung:
5 245 ACCEPT udp -- * * 192.168.10.11 0.0.0.0/0 udp dpt:69 state NEW,ESTABLISHED
0 0 ACCEPT udp -- * * 192.168.10.11 0.0.0.0/0 udp spts:1024:65535 dpts:1024:65535 state ESTABLISHED
--
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.10.11 udp spt:69 state ESTABLISHED
30 960 ACCEPT udp -- * * 0.0.0.0/0 192.168.10.11 udp spts:1024:65535 dpts:1024:65535 state RELATED,ESTABLISHED
Nach dem Übertragungsversuch:
10 490 ACCEPT udp -- * * 192.168.10.11 0.0.0.0/0 udp dpt:69 state NEW,ESTABLISHED
0 0 ACCEPT udp -- * * 192.168.10.11 0.0.0.0/0 udp spts:1024:65535 dpts:1024:65535 state ESTABLISHED
--
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.10.11 udp spt:69 state ESTABLISHED
58 1856 ACCEPT udp -- * * 0.0.0.0/0 192.168.10.11 udp spts:1024:65535 dpts:1024:65535 state RELATED,ESTABLISHED
Das sagt mir also, dass es nicht die Firewall ist und wenn ich keine Rückpakete mit tcpdump sehe, liegt etwas dazwischen, vielleicht sogar die Anwendung selbst.