~ Endless Eight ~ Migrando o ambiente FreeBSD do Vultr para o ConoHa enquanto bêbado ~ SigningTable que não pode ser lida com curingas ~

10 min

freebsdconohavultrpostfixdovecot
language: ja bn en es hi pt ru zh-cn zh-tw

Olá, esta é uma continuação da última vez. O título é "bêbado", mas não estou mais bêbado.

Não está chegando ao gmail!

Ah, estou com problemas.
É uma luta enquanto observo tail -f /var/log/maillog...

opendkim[1853]: can’t load key from /var/db/dkim/eyes4you.org.private: Permission denied

Ah... parece ser um problema de permissão.
Eu havia esquecido, mas o usuário padrão para dmarc/dkim no FreeBSD é mailnull.

root@localhost:/usr/local/etc # grep -r mailnull
./rc.d/opendmarc:opendmarc_runas=${opendmarc_runas-"mailnull:mailnull"}
./rc.d/milter-opendkim:: ${milteropendkim_uid:="mailnull"}
./rc.d/milter-opendkim:: ${milteropendkim_gid:="mailnull"}
./rc.d/milter-manager:: ${miltermanager_uid="mailnull"}

Em outras palavras, o opendkim deve ser capaz de ler a chave privada.
Como eu também cometi erros ao criar mail.eyes4you.org e eyes4you.org da última vez, vou começar do zero.
A propósito, as configurações anteriores também estavam erradas, e os registros que eu havia registrado no ConoHa também estavam incorretos.

# opendkim-genkey -d eyes4you.org -s mail -D /var/db/dkim/
# cat /var/db/dkim/mail.txt # Adicione o conteúdo daqui ao registro TXT
mail._domainkey IN      TXT     ( "v=DKIM1; k=rsa; "
          "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFdu/VfVVHqUN84IZh739JVf8NW6HAmMBT3+NBcTmkwOGLQ4ye59wvN83CudtnHPKR9vdtL9kJusaWk6wm0HXtZ64dVkjZxg61vrwPWw25Pe1eAkrs8EkdqnCLfeHtsU2g7dBD+gjbJgOKdAhIocPQYQYio0kyMn8M/MlGP60eQQIDAQAB" )  ; ----- DKIM key mail for eyes4you.org

Depois disso, conceda as permissões.

chown mailnull:mailnull /var/db/dkim/mail.private
chmod 600 /var/db/dkim/mail.private

É simples.
Desta vez, usei apenas curingas.

root@localhost:/usr/local/etc/mail # cat SigningTable
*@eyes4you.org mail._domainkey.eyes4you.org
root@localhost:/usr/local/etc/mail # cat KeyTable 
mail._domainkey.eyes4you.org eyes4you.org:mail:/var/db/dkim/mail.private
root@localhost:/usr/local/etc/mail #

Agora reinicie

service milter-opendkim restart
service postfix restart
tail -f /var/log/maillog

Com isso, envio e-mails, mas não importa quantas vezes eu tente, eles ainda vão para a pasta de spam do Gmail...

Olhando os logs

Sep 14 10:59:04 localhost opendkim[974]: B855A20079: no signing table match for 'hoge@eyes4you.org'

É o que acontece. Lembro-me de ter escrito explicitamente hoge@eyes4you.org na KeyTable porque fiquei preso com isso...
Mas eu quero especificar um curinga.

Percorri vários sites e cheguei aqui.
Já vi isso antes...
opendkim no centos6.3 mostra "no signing table match" | CHOICE

Se você estiver usando SigningTable /etc/opendkim/SigningTable, deve configurá-lo como testserver.com default._domainkey.testserver.com. Alternativamente, se você estiver usando SigningTable refile:/etc/opendkim/SigningTable, deve configurá-lo como *@testserver.com default._domainkey.testserver.com.

Então, isso significa

root@localhost:/usr/local/etc/mail # cat opendkim.conf
##
## opendkim.conf -- configuration file for OpenDKIM filter
##
## Copyright (c) 2010-2015, The Trusted Domain Project.  All rights reserved.
##
Canonicalization        simple/simple
Domain                  eyes4you.org
LogWhy                  yes
Mode                    sv
ReportAddress           "DKIM Error Postmaster" <postmaster@eyes4you.org>
Selector                default
SendReports             yes
Socket                  inet:8891@localhost
SubDomains              yes
Syslog                  Yes
SyslogSuccess           yes
UMask                   002
InternalHosts           /usr/local/etc/mail/TrustedHosts
SigningTable            refile:/usr/local/etc/mail/SigningTable # ← Aqui
KeyTable                /usr/local/etc/mail/KeyTable

Verificar os logs

root@localhost:/usr/local/etc/mail # tail -f /var/log/maillog
~~~
Sep 14 12:14:52 localhost opendkim[3772]: 21A8E20293: DKIM-Signature field added (s=mail, d=eyes4you.org)
~~~

Chegou~~~~!!!! Consegui!

Registro SPF, estou sendo repreendido...

Parece que, se o IPv6 estiver ativado, eu também precisava ativá-lo no registro SPF.
Antes, eu o desativava completamente por preocupações com desempenho, mas não me importo mais, então vou registrá-lo.

v=spf1 ip4:IPv4 aqui ip6:IPv6 aqui -all

A propósito, recentemente descobri que ao acessar IPv6 em localhost com um navegador, você pode abri-lo envolvendo-o em [ ], como http://[IPv6:aqui]:80.
Não há mais sentido em esconder, mas é assim.

Image

Excluir parte do tráfego WireGuard da VPN

Serviços como o OpenAI reclamam com a comunicação VPN, então vou evitar que usem a comunicação VPN.

cd /usr/local/
mkdir sh
cd sh
vim route.sh

E insira o seguinte

#!/usr/local/bin/bash

# Define os domínios da lista
DOMAINS=("chat.openai.com" )

# Gateway padrão
GATEWAY="Neste caso, o inet de vtnet0 do ifconfig"

# Obter os endereços IP de cada domínio e adicionar roteamento
for DOMAIN in "${DOMAINS[@]}"; do
  # Obter o endereço IP do domínio
  IP_ADDRESSES=$(dig +short $DOMAIN | grep [0-9])

  # Adicionar roteamento para cada IP
  for IP in $IP_ADDRESSES; do
    route add $IP $GATEWAY
  done
done

No entanto, observe que o IPv6 também é necessário desta vez.

Nginx

Rotação de logs do Nginx

Percebi ao usar o FreeBSD do Vultr que não havia rotação de log padrão e estava transbordando.
No FreeBSD, você pode configurá-lo em /etc/newsyslog.conf, então adicione o seguinte.

/var/log/nginx/access.log   root:wheel  640  7     *    @T00  Z
/var/log/nginx/error.log    root:wheel  640  7     *    @T00  Z

Em seguida, mova o arquivo conf. É problemático que o ConoHa esteja bloqueando o Vultr, mas vou transferi-lo através da máquina atual.

thepassenger:[haturatu]:~/migrate-freebsd$ scp darkstar@vultr-freebsd:/home/darkstar/nginx.tar.gz .
nginx.tar.gz                                                             100%   14KB 167.8KB/s   00:00    
thepassenger:[haturatu]:~/migrate-freebsd$ scp nginx.tar.gz root@conoha-freebsd:/root/
nginx.tar.gz                                                             100%   14KB 129.1KB/s   00:00

Exclua o /usr/local/etc/nginx padrão e conclua com mv.
O destino do backend aponta para o IP Interno do WireGuard, então basta apontar o servidor WireGuard para o ConoHa no lado do cliente.
No entanto, como pretendo usar o ConoHa como NS desta vez, é realmente problemático. A dificuldade de ter mais de 10 domínios surge...
Felizmente, o ConoHa disponibilizou uma API para alteração de registros DNS, então gostaria de criar algo que possa alterar os registros DNS de uma vez após a conclusão desta tarefa.
Importação de arquivo de zona | Site de documentação do ConoHa

Depois disso, vou de alguma forma enviar os arquivos estaticamente hospedados e o próprio diretório de e-mail para o lado do ConoHa através da minha máquina host... e pronto!
Por fim, quanto ao fail2ban, farei isso depois de confirmar a comunicação do lado do cliente com o WireGuard. Até a próxima.

Related Posts