Postfix - tráfego SMTP de saída saindo da interface errada
Eu tenho um servidor Postfix que estava funcionando bem (entrada e saída) até que fiz algumas alterações na rede. Eu adicionei uma interface (para um segundo endereço IP público, por meio de um túnel VPN. Pretendo executar vários servidores Postfix, para oferecer suporte a domínios separados em endereços IP separados, certificados etc.)
Após a alteração, o postfix recebe e-mails recebidos sem problemas, mas o tráfego de saída está saindo pela interface errada e, portanto, o e-mail não pode ser entregue (a porta 25 está bloqueada nessa interface.) mail.logMostra "conexão recusada" ou "rede inacessível" para qualquer SMTP estrangeiro servidor.
Exemplo de mensagem de erro de mail.log:
Oct 18 17:13:10 vox postfix/smtp[22694]: connect to mx-asp.jvlicenses.com[198.199.107.159]:25: Connection timed out
Oct 18 17:13:10 vox postfix/smtp[22694]: 39DCBA6227: to=<[email protected]>, relay=none, delay=1096, delays=1066/0.02/30/0, dsn=4.4.1, status=deferred (connect to mx-asp.jvlicenses.com[198.199.107.159]:25: Connection timed out)
Estou usando o parâmetro smtp_bind_addressmaster.cf para especificar o endereço de origem que o Postfix deve usar. Também tentei usar o inet_addressesin master.cf, mas também não parece funcionar. O tráfego sempre sai do gateway padrão, em vez da interface desejada. (Quando tudo isso estava funcionando, acho que a rota padrão era provavelmente a rota desejada, mas não consigo me lembrar com certeza.)
O que eu quero é que o postfix envie e-mail com o IP de origem 10.8.0.8, que pelas minhas regras de roteamento deve sair da interface tun45. Em vez disso, pelo que posso dizer, o postfix está enviando com IP 192.168.122.185no dispositivo enp1s0- que é a rota padrão no host.
Estou executando a versão Postfix 3.4.14no Debian 4.19.118-2 (2020-04-24).
Seguem alguns detalhes de configuração adicionais, junto com as etapas que usei para testar.
Postfix se liga a 10.8.0.8, conforme mostrado por netstat:
# netstat -ntlp|grep master
tcp 0 0 10.8.0.8:25 0.0.0.0:* LISTEN 22293/master
tcp 0 0 10.8.0.8:587 0.0.0.0:* LISTEN 22293/master
tcp 0 0 10.8.0.8:465 0.0.0.0:* LISTEN 22293/master
Esse endereço é um dispositivo tun45no host:
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:4b:2c:5b brd ff:ff:ff:ff:ff:ff
inet 192.168.122.185/24 brd 192.168.122.255 scope global dynamic noprefixroute enp1s0
valid_lft 2672sec preferred_lft 2672sec
inet6 fe80::5054:ff:fe4b:2c5b/64 scope link noprefixroute
valid_lft forever preferred_lft forever
9: tun45: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.8.0.8/24 brd 10.8.0.255 scope global tun45
valid_lft forever preferred_lft forever
inet6 fe80::e401:70cf:ba68:88b1/64 scope link stable-privacy
valid_lft forever preferred_lft forever
11: tun66: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.8.0.7/24 brd 10.8.0.255 scope global tun66
valid_lft forever preferred_lft forever
inet6 fe80::41d:c2e1:9428:5630/64 scope link stable-privacy
valid_lft forever preferred_lft forever
Rotear para qualquer endereço externo (neste caso, o MTA para jvlicenses.com) do IP 10.8.0.8, deve ir através do dispositivo tun45:
# ip route get 198.199.107.159 from 10.8.0.8
198.199.107.159 from 10.8.0.8 dev tun45 table t1 uid 0
cache
A tabela de roteamento t1possui apenas uma entrada:
# ip route show table t1
default dev tun45 scope link
Posso me conectar ao servidor externo pós 25 usando netcat, com o mesmo endereço de origem:
# nc -s 10.8.0.8 198.199.107.159 25
220 mx-asp.jvlicenses.com ESMTP Postfix
QUIT
221 2.0.0 Bye
tcpdump mostra que a conexão netcat tem o endereço de origem correto etc:
# tcpdump -ni tun45 dst port 25
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun45, link-type RAW (Raw IP), capture size 262144 bytes
16:27:02.522570 IP 10.8.0.8.42427 > 198.199.107.159.25: Flags [S], seq 4118387792, win 64240, options [mss 1460,sackOK,TS val 2496426612 ecr 0,nop,wscale 8], length 0
16:27:02.689912 IP 10.8.0.8.42427 > 198.199.107.159.25: Flags [.], ack 1806817019, win 251, options [nop,nop,TS val 2496426779 ecr 75983973], length 0
16:27:02.857545 IP 10.8.0.8.42427 > 198.199.107.159.25: Flags [.], ack 42, win 251, options [nop,nop,TS val 2496426947 ecr 75984142], length 0
16:27:14.393645 IP 10.8.0.8.42427 > 198.199.107.159.25: Flags [P.], seq 0:5, ack 42, win 251, options [nop,nop,TS val 2496438483 ecr 75984142], length 5: SMTP: QUIT
16:27:14.650912 IP 10.8.0.8.42427 > 198.199.107.159.25: Flags [.], ack 57, win 251, options [nop,nop,TS val 2496438740 ecr 75995841], length 0
16:27:14.651089 IP 10.8.0.8.42427 > 198.199.107.159.25: Flags [F.], seq 5, ack 58, win 251, options [nop,nop,TS val 2496438740 ecr 75995842], length 0
Mas quando eu envio um e-mail para aquele servidor, não há tráfego no tun45. Em vez disso, vejo que ele segue a rota padrão no dispositivo enp1s0:
# tcpdump -n dst port 25 -vv
tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:42:37.321194 IP (tos 0x0, ttl 64, id 1567, offset 0, flags [DF], proto TCP (6), length 60)
192.168.122.185.34050 > 198.199.107.159.25: Flags [S], cksum 0x6df7 (incorrect -> 0xc5e2), seq 3824536030, win 64240, options [mss 1460,sackOK,TS val 17622374 ecr 0,nop,wscale 8], length 0
Confirmação de que esta é de fato a rota padrão para o host, ou seja, quando o IP de origem não é 10.8.0.8para que a tabela de roteamento t1seja acionada:
# ip route
default via 192.168.122.1 dev enp1s0 proto dhcp metric 100
10.8.0.0/24 dev tun45 proto kernel scope link src 10.8.0.8
10.8.0.0/24 dev tun66 proto kernel scope link src 10.8.0.7
<...elided entries...>
# ip route get 198.199.107.159
198.199.107.159 via 192.168.122.1 dev enp1s0 src 192.168.122.185 uid 0
cache
master.cf config:
10.8.0.8:smtp inet n - y - - smtpd -v
-o smtpd_tls_key_file=/etc/letsencrypt/live/<domain>/privkey.pem
-o smtpd_tls_cert_file=/etc/letsencrypt/live/<domain>/fullchain.pem
-o smtp_bind_address=10.8.0.8
-o myhostname=<host.domain>
10.8.0.8:submission inet n - y - - smtpd -v
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_tls_key_file=/etc/letsencrypt/live/<domain>/privkey.pem
-o smtpd_tls_cert_file=/etc/letsencrypt/live/<domain>/fullchain.pem
-o smtp_bind_address=10.8.0.8
-o myhostname=<host.domain>
10.8.0.8:smtps inet n - y - - smtpd -v
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_tls_key_file=/etc/letsencrypt/live/<domain>/privkey.pem
-o smtpd_tls_cert_file=/etc/letsencrypt/live/<domain>/fullchain.pem
-o smtp_bind_address=10.8.0.8
-o myhostname=<host.domain>
E postconf -nsaída:
# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
debug_peer_list = 81.3.6.165, 45.55.104.203, 34.209.113.130
delay_warning_time = 4h
disable_vrfy_command = yes
inet_interfaces = all
inet_protocols = all
invalid_hostname_reject_code = 550
mailbox_size_limit = 0
maximal_backoff_time = 3h
milter_default_action = accept
milter_protocol = 6
minimal_backoff_time = 180s
mydestination = localhost
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
non_fqdn_reject_code = 550
non_smtpd_milters = $smtpd_milters policyd-spf_time_limit = 3600s readme_directory = no recipient_delimiter = + relayhost = smtp_always_send_ehlo = yes smtp_helo_timeout = 15s smtp_rcpt_timeout = 15s smtp_tls_security_level = may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname
smtpd_milters = local:opendkim/opendkim.sock
smtpd_recipient_limit = 40
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unlisted_recipient, reject_unauth_destination, check_policy_service unix:private/policyd-spf
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unknown_reverse_client_hostname
smtpd_timeout = 30s
smtpd_tls_auth_only = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
strict_rfc821_envelopes = yes
unknown_address_reject_code = 550
unknown_client_reject_code = 550
unknown_hostname_reject_code = 550
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf, mysql:/etc/postfix/mysql-virtual-email2email.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_transport = lmtp:unix:private/dovecot-lmtp
Não estou fazendo SNATing, masquerading ou outras coisas de iptables neste host. (Isso tudo acontece na outra extremidade do túnel VPN.)
O que estou perdendo aqui? Por que o tráfego postfix de saída está saindo em enp1s0vez de tun45? E por que não tem o IP de origem que está configurado smtp_bind_address?
Respostas
Por favor, dê uma olhada nesta questão: Evite que o Postfix envie e-mail pela interface de rede errada .
Nesse post, as pessoas declararam que smtp_bind_addressfarão failover para outro inet_interface se o configurado não estiver disponível. No seu caso, smtp_bind_addressaponta para um IP estático vinculado a tun0. Ele vai passar por tun0 quando estiver ativo. Se o tun0 estiver inativo, o vínculo do cliente falhará, fazendo com que o postfix volte ao comportamento padrão de não ligar o terminal TCP do cliente e, portanto, usará a rota padrão que está conectada ao eth0.