TFTP: Temps de transmission sur le serveur RHEL 6

Je me repose dans le mur, essayant de faire tftp Travailler en utilisant RHEL 6 Comme serveur. Erreur du client - c'est simple "Temps de transmission expiré". Sur le serveur, je vois le trafic UDP 69, Venant de mon client, mais je ne vois pas les colis retournant au client. Dans les magazines, je vois que xinetd Traite une demande. Sur le serveur que j'utilise tftp version:

tftp-server-0.49-8.el6.x86_64

Voici une équipe que je rencontre du client.

tftp -v 192.168.100.10 -c get file

Serveur latéral tcpdump:

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

Et cela répète encore et encore jusqu'à l'expiration du temps de transmission. Voici mon fichier journal:

Jul 26 13:54:22 server in.tftpd[7068]: RRQ from 192.168.100.11 filename file

Et il est également répété à nouveau et encore jusqu'à l'expiration du temps de transmission. Ma configuration:

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
}

Régner Iptables est en haut:

[root@server tftpboot]# iptables -L --line-numbers | grep tftp
1 ACCEPT udp -- anywhere anywhere state NEW udp dpt:tftp

Modules de noyau téléchargé:

[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 Permet:

[root@server tftpboot]# getenforce 
Permissive

J'ai tout permis de tout hosts.allow:

xinetd : ALL

Et je sais que le service écoute:

[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

Il y a dans le monde RX dans le catalogue tftpboot:

[root@server lib]# ll | grep tftp*
drwxr-xr-x. 2 root root 4096 Jul 26 12:17 tftpboot

Et le monde a lu les fichiers à l'intérieur. Une autre chose que j'ai essayée.

1) Utilisant tcp au lieu udp = FAIL

2) Déplacer le catalogue racinaire tftp = FAIL

3) Et comme vous pouvez le constater, j'ai déjà inclus une journalisation détaillée pour tftp

4) Changement d'utilisateur de configuration = FAIL

Je suis confus maintenant. Quelqu'un a-t-il déjà rencontré ce problème?

Rafraîchir:

Voici ma configuration complète iptables:

*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

De plus, j'ai éteint iptables Et je reçois toujours le même message sur l'expiration du temps d'attente de temps.

Mettre à jour # 2

- J'ai aussi ajouté ce qui suit dans iptables, mais iptables malheureux.

-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

Erreur:

iptables: Applying firewall rules: iptables-restore v1.4.7: unknown option `--sport'

Mettre à jour # 3

Non pas que cela puisse aider, mais j'étais curieux de voir si j'ai vraiment vu les colis associés viennent de quitter le pare-feu. Voici un instantané de deux règles que j'ai insérées pour résoudre comment 69 Au client et de celui-ci, ainsi que des ports nécessaires au transfert de données.

Avant le début du transfert:

 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

Après avoir essayé de transférer:

   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

Donc, cela me dit que ce n'est pas un pare-feu, et si je ne vois pas les colis de rétablissement avec tcpdump, C'est quelque chose de moyen, peut-être la demande elle-même.
Invité:

Christine

Confirmation de:

Comme vous utilisez

state

Dans votre configuration iptables, Pour résoudre uniquement les nouvelles connexions via le port tftp, Et vous avez seulement posté un extrait de la configuration de votre pare-feu:


1 ACCEPT udp -- anywhere anywhere


state NEW


udp dpt:tftp

cette règle dans la chaîne INPUT, Et y a-t-il aussi un commun

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Régner? (Si tel est le cas, cette règle est probablement la première règle de votre chaîne INPUT.)

Parce que, bien que le protocole lui-même UDP Aucun états, modules conntrack soutenir toujours certaines informations de statut pour UDP, Et vous pouvez avoir un cas lorsque le premier paquet UDP Il est accepté et chaque paquet ultérieur est considéré comme faisant partie de la "établie" ou "liée" "

session

mais non "Nouveau" Et rejeté.

Pour répondre aux questions, connectez-vous ou registre