firewalld: problema ao encaminhar a porta 25 enquanto outras portas avançam muito bem, o registro “rich rule” mostra NO entries

Question

Então, eu instalei o Fedora Core 19 pela primeira vez como um substituto para um sistema antigo cujo disco finalmente morreu. O sistema funciona como um servidor da web e gateway / firewall , protegendo os sistemas internos. Como tem muita configuração de rede, recebi uma introdução - e achei que realmente gosto - o novo firewall, firewalld .

Eu achei que tudo estava indo bem (isso é sempre quando os problemas acontecem) quando de repente eu vi o arquivo maillog do servidor de e-mails ficar louco - foi apenas sorte ainda assistimos 6 horas depois de fazer as coisas funcionarem.

A investigação mostrou que o meu sistema interno de e-mail (protegido pelo firewall) pensava que todos os e-mails enviados vinham do sistema de gateway; portanto, era um sistema "interno" e os spammers descobriram que era um retransmissor aberto. Notei também que, de alguma forma ou de outra, AMBAS as zonas internas e externas foram marcadas como "mascaradas" e que, de fato, os endereços IP percebidos no arquivo maillog eram o IP do gateway. Fazendo login por meio de um encaminhamento A porta ssh também confirmou que o IP errado estava sendo usado no lado interno.

NENHUM PROBLEMA! "Eu pensei erroneamente. SIM, desligar o mascaramento na zona interna corrigiu o IP errado sendo entregue aos sistemas internos ao passar pelo gateway. No entanto, ele NÃO resolveu o problema porque, inexplicavelmente (assim agora! parece que a porta 25 não está mais sendo encaminhada!

OUTRAS portas estão sendo encaminhadas, pelo menos a porta ssh facilmente testada de que falei é. Então, eu pensei, vou apenas ativar esse recurso de log extravagante ! Aqui está o comando:

firewall-cmd --zone=external --add-rich-rule='rule family="ipv4" forward-port port="25" protocol="tcp" to-port="25" to-addr="192.168.1.1" log prefix="smtp-to-inside" level="info"'

Eu tentei com a opção permanente, e não, etc. NADA aparece em / var / log / messages - ou qualquer outro arquivo de log que eu possa pensar em procurar. É como se o kernel está apenas ignorando essa porta. Pensei que talvez o sistema interno de e-mail pudesse possivelmente bloquear o tráfego externo com seu firewall, MAS o gateway DEVERIA estar registrando as tentativas de conexão, mas não obtive nada.

Qualquer e tudo ajuda apreciado.

    

Answer 1

Esse problema não tem nada a ver com o firewalld, embora ele tenha iluminado um bug com o registro do firewalld.

O problema era que, durante a atualização, eu mudaria a rota padrão do sistema interno, fornecendo serviços de e-mail para um gateway / firewall diferente, não envolvido na atualização. Eu tinha pensado que isso era uma boa ideia porque o novo sistema estava tendo problemas, eu pensei.

Quando retornei o sistema de servidor SMTP interno para usar a nova máquina de gateway como sua rota padrão, tudo começou funcionando! Acontece que há um requisito que ninguém lhe fala sobre - nunca o encontrou documentado, mas agora que o encontrei, alguns antigos confirmam - que a rota padrão tem de ser definida para o mesmo como onde os pacotes são encaminhados a partir de OR você tem que ter rotas especiais configuradas para retornar os pacotes no mesmo caminho de onde eles vieram. ESSE é o requisito: a rota de retorno deve ser igual à rota de origem.

Boa sorte lá fora!