TFTP: tempo limite de transferência no servidor RHEL 6

3

Estou atingindo uma parede aqui tentando fazer com que o tftp funcione usando o RHEL 6 como um servidor. O erro, do cliente, é simplesmente "tempo limite de transferência". No servidor, consigo ver o tráfego do udp 69 vindo do meu cliente, mas não vejo nenhum pacote retornando ao cliente. Nos logs eu posso ver que o xinetd está processando o pedido. No servidor estou executando a versão do tftp:

tftp-server-0.49-8.el6.x86_64

Aqui está o comando que eu executo do cliente.

tftp -v 192.168.100.10 -c get file

Lado do servidor do 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

E isso se repete várias vezes até a transferência expirar. Aqui está o meu arquivo de log:

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

E isso também se repete várias vezes até a transferência expirar. Minha configuração:

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
}

A regra de iptables está no topo:

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

Os módulos do kernel são carregados:

[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

O SELinux é permissivo:

[root@server tftpboot]# getenforce 
Permissive

Eu permiti todos em hosts.allow:

xinetd : ALL

E eu sei que o serviço está escutando:

[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    

mundo tem RX no diretório tftpboot:

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

E o mundo leu os arquivos dentro. Outras coisas que eu tentei.

1) Usando tcp em vez de udp = FAIL

2) Movendo o diretório raiz do tftp = FAIL

3) E como você pode ver, eu já tenho o log detalhado ativado para o tftp

4) Mudando o usuário no config = FAIL

Eu estou perdido neste momento. Alguém já se deparou com esse problema antes?

UPDATE: Aqui está minha configuração completa do 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

Além disso, desabilito o iptables e ainda recebo a mesma mensagem de tempo limite de transferência.

UPDATE # 2 - Eu também adicionei o seguinte no iptables, mas o iptables não está satisfeito.

-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

Erro:

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

UPDATE # 3

Não que isso possa ajudar, mas fiquei curioso para ver se na verdade vi pacotes relacionados chegando e saindo do firewall. Aqui está um instantâneo das duas regras que inseri para permitir tanto a entrada e a saída do cliente quanto as portas necessárias para a transferência de dados.

Antes de começar a transferência:

 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 

Após a tentativa de transferência:

   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 

Então isso me diz que não é o firewall e se eu não vejo pacotes de retorno com o tcpdump é algo intermediário, talvez talvez o próprio aplicativo.

    
por user53029 26.07.2016 / 21:15

1 resposta

3

Como você está usando o módulo state em sua configuração do iptables para permitir apenas NOVAS conexões na porta tftp e você postou apenas um trecho da configuração do seu firewall:

1 ACCEPT udp -- anywhere anywhere state NEW udp dpt:tftp

é essa regra na cadeia INPUT e existe também uma regra genérica -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT ? (Se assim for, essa regra provavelmente deve ser a primeira regra na sua cadeia INPUT.)

Porque embora o próprio protocolo UDP seja stateless os módulos conntrack ainda parecem manter alguma informação de estado para o UDP e você pode ter um caso onde o primeiro pacote UDP seja aceito e cada pacote subseqüente seja considerado como parte de um "estabelecido" ou "relacionado" sessão em vez de "novo" e rejeitado.

    
por 26.07.2016 / 22:20