Não é possível abrir a porta ftp via firewalld

2

Estou tentando abrir a porta ftp na zona pública e o firewall-cmd sai com uma resposta muito não descritiva. A saída do comando é:

firewall-cmd --zone=public --add-service=ftp
Error: COMMAND_FAILED

SO: CentOS Linux versão 7.3.1611 (Core)

Atualizando a pergunta original com mais detalhes.

saída do journalctl:

~ firewall-cmd --zone=public --add-service=ftp
Error: COMMAND_FAILED
~ journalctl -xf
Mar 06 00:46:42 hostname firewalld[3496]: ERROR: COMMAND_FAILED

saída de depuração:

~ firewalld --nofork --debug=10
<...>
2017-03-06 00:49:57 DEBUG1: zone.addService('public', 'ftp', 0)
2017-03-06 00:49:57 DEBUG4: <class 'firewall.core.fw_transaction.FirewallZoneTransaction'>.execute(True)
2017-03-06 00:49:57 DEBUG4: <class 'firewall.core.fw_transaction.FirewallZoneTransaction'>.prepare(True, ...)
2017-03-06 00:49:57 DEBUG4: <class 'firewall.core.fw_transaction.FirewallZoneTransaction'>.prepare(True, ...)
2017-03-06 00:49:57 DEBUG4: <class 'firewall.core.fw_transaction.FirewallZoneTransaction'>.pre()
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.ipXtables.ip4tables'>: /usr/sbin/iptables-restore /run/firewalld/temp.tptEtP: 89
       1: *filter
       2: -A IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
       3: COMMIT
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.ipXtables.ip6tables'>: /usr/sbin/ip6tables-restore /run/firewalld/temp.CYsjiA: 89
       1: *filter
       2: -A IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
       3: COMMIT
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.modules.modules'>: /sbin/modprobe nf_conntrack_ftp
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.ipXtables.ip4tables'>: /usr/sbin/iptables-restore /run/firewalld/temp.1dBrUZ: 89
       1: *filter
       2: -D IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
       3: COMMIT
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.ipXtables.ip6tables'>: /usr/sbin/ip6tables-restore /run/firewalld/temp.vbUyZC: 89
       1: *filter
       2: -D IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
       3: COMMIT
2017-03-06 00:49:57 ERROR: COMMAND_FAILED

Mais uma atualização: se eu fizer:

~ iptables -A IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT

o serviço ftp está funcionando. No entanto, eu gostaria de gerenciar tudo via firewalld. Então, eu estou querendo saber se é uma falha no firewall ou erro na configuração.

    
por nweb 05.03.2017 / 22:05

2 respostas

2

O mesmo problema, mas --add-port funcionou para mim:

# firewall-cmd --zone=public --add-port=21/tcp
    
por 29.03.2017 / 03:17
0

Isso responde ao problema do convidado do LXC com o host que o suporta. O seu LXC suporta isso?

O host precisa ter suporte modprobe nf_conntrack_ftp lsmod mostra nf_conntrack_ftp? se assim for, adicione nf_conntrack_ftp ao / etc / modules Capture a saída do modinfo nf_conntrack_ftp para mais tarde

Suportado no seu LXC? / sys / module / nf_conntrack_ftp existe? / proc / sys / net / netfilter / nf_conntrack_helper existe? mkdir -p /lib/modules/4.4.67-1-pve/kernel/net/netfilter/ substitua 4.4.67-1-pve pelo seu host, estou usando o Proxmox com esse kernel. tocar todos os arquivos .ko do host Coloque a saída do modinfo nf_conntrack_ftp no arquivo nf_conntrack_ftp.ko modinfo de backup substitua-o por este script

#!/bin/bash
cat /lib/modules/4.4.67-1-pve/kernel/net/netfilter/$1.ko

Substitua o caminho pelo que você criou anteriormente. Torne o arquivo executável. Você quer que o modinfo nf_conntrack_ftp tenha a mesma saída do seu host que o seu convidado.

Em seguida, precisamos substituir o modprobe pelo seguinte script.

#!/bin/bash
exit 0

Torne-o executável também. Porque este é o convidado, não é como se você tivesse módulos para sondar.

Ótimo. Agora você pode enganar /usr/lib/python2.7/site-packages/firewall/functions.py que seu convidado pode fazer coisas com o modinfo.

Você também está enganando /usr/lib/python2.7/site-packages/firewall/core/modules.py com a substituição do modprobe.

Mais uma vez, sinto que é ok que modinfo e modprobe sejam substituídos por esses scripts falsos, porque o convidado em um contêiner não tem acesso aos módulos de qualquer maneira. É por isso que isso não funciona.

Eu também acho que o projeto firewalld deve corrigir isso, pois parece um erro não intencional.

    
por 06.04.2018 / 01:02