Início / ubuntu / Perguntas / 1533648
Accepted
Bones
Asked: 2024-11-23 00:26:38 +0800 CST

Portos fechando para tráfego de entrada

  • 772

Tenho uma instalação limpa do Ubuntu 24.04 em um servidor em nuvem para executar o iRedMail 1.7.1.

O servidor mostra

sudo ufw status verbose
Status: inactive

e

$ ss -ltn
.
.
LISTEN       0            511                      0.0.0.0:443                      0.0.0.0:*                        
.
.
.

mas de uma máquina externa eu recebo

Nmap scan report for xx.xx.xx.xx
Host is up (0.023s latency).
Not shown: 990 filtered tcp ports (no-response)
PORT    STATE  SERVICE
22/tcp  open   ssh
25/tcp  closed smtp
80/tcp  closed http
110/tcp closed pop3
143/tcp closed imap
443/tcp closed https
465/tcp closed smtps
587/tcp closed submission
993/tcp closed imaps
995/tcp closed pop3s

Se eu emitir

server:~$ sudo ufw disable
Firewall stopped and disabled on system startup
server:~$ sudo shutdown -r now

então na reinicialização eu recebo

Nmap scan report for xx.xx.xx.xx
Host is up (0.011s latency).
Not shown: 990 filtered tcp ports (no-response)
PORT    STATE SERVICE
22/tcp  open  ssh
25/tcp  open  smtp
80/tcp  open  http
110/tcp open  pop3
143/tcp open  imap
443/tcp open  https
465/tcp open  smtps
587/tcp open  submission
993/tcp open  imaps
995/tcp open  pop3s

como esperado. Dura alguns minutos e algo chuta as portas para fechar novamente. UFW ainda mostra como Inativo.

O que pode estar causando esse comportamento?

Com base no atraso antes do fechamento das portas, pode estar relacionado a Como corrigir a aplicação automática da configuração do netplan após a reinicialização que não está funcionando? e ao gerador do netplan?

Respondendo a mpboden, estou imediatamente preocupado com 443, mas o NMAP mostra portas abertas ou filtradas ao tentar se comunicar por meio de uma interface HTTPS. Minha configuração Netplan é

network:
  version: 2
  renderer: networkd
  ethernets:
      eth0:
          dhcp4: no
          addresses: [xx.xx.xx.xx/24]
          routes:
              - to: default
                via: xx.xx.xx.xx          
          nameservers:
              addresses: [8.8.8.8, 208.67.222.222]

Não encontrei nenhuma pista nos arquivos de log, mas isso pode ser devido à minha falha em detectar algo significativo.

Abordando o ponto de Thomas Ward, tentei abrir explicitamente as portas no UFW, veja Portas abertas no UFW, mas ainda fechadas para o mundo externo , mas não faz diferença. Portanto, tenho o UFW definido como inativo, pelo menos até descobrir isso.

O atraso sugere que algum outro componente Netplan pode estar sendo executado de forma assíncrona e alterando as configurações de porta. Mas onde procurar?

Configurei outro servidor que está funcionando corretamente para comparação. O problema parece estar associado a uma falha ao iniciar systemd-networkd-wait-online.service. Executar uma verificação (systemctl status) no postfix, dovecot e nginx retorna "Aviso: alguns arquivos de diário não foram abertos devido a permissões insuficientes." para todos os 3. O servidor em funcionamento não tem esse aviso. Comecei a analisar os arquivos nas pastas /etc/postfix (etc) para comparar permissões. Ajudaria listar os arquivos de status aqui?

Após comparar o systemd-networkd-wait-online.service entre o servidor físico (funcionando) e o servidor virtual (problemático), o servidor virtual continha estas linhas:

$ sudo systemctl edit systemd-networkd-wait-online.service
### Editing /etc/systemd/system/systemd-networkd-wait-online.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online -i enp0s3:degraded --timeout=30

### Edits below this comment will be discarded

O servidor físico não tinha essas linhas sem comentários, então eu as deletei no servidor virtual. Elas foram reinseridas.

Também verifiquei a configuração do Netplan:

$ sudo netplan --debug apply

** (generate:73362): DEBUG: 09:58:53.126: starting new processing pass
** (generate:73362): DEBUG: 09:58:53.127: eth0: adding new route
** (generate:73362): DEBUG: 09:58:53.127: We have some netdefs, pass them through a final round of validation
** (generate:73362): DEBUG: 09:58:53.127: eth0: setting default backend to 1
** (generate:73362): DEBUG: 09:58:53.127: Configuration is valid
** (generate:73362): DEBUG: 09:58:53.128: Generating output files..
** (generate:73362): DEBUG: 09:58:53.128: Open vSwitch: definition eth0 is not for us (backend 1)
** (generate:73362): DEBUG: 09:58:53.128: NetworkManager: definition eth0 is not for us (backend 1)
DEBUG:netplan generated networkd configuration changed, reloading networkd
DEBUG:Cannot call Open vSwitch: Cannot apply OVS cleanup: ovsdb-server.service is 'not-found'.
DEBUG:no netplan generated NM configuration exists
** (process:73361): DEBUG: 09:58:53.607: starting new processing pass
** (process:73361): DEBUG: 09:58:53.608: eth0: adding new route
** (process:73361): DEBUG: 09:58:53.608: We have some netdefs, pass them through a final round of validation
** (process:73361): DEBUG: 09:58:53.608: eth0: setting default backend to 1
** (process:73361): DEBUG: 09:58:53.608: Configuration is valid
DEBUG:Merged config:
b''
DEBUG:Link changes: {}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for eth0
** (process:73361): DEBUG: 09:58:53.749: starting new processing pass
** (process:73361): DEBUG: 09:58:53.750: eth0: adding new route
** (process:73361): DEBUG: 09:58:53.751: We have some netdefs, pass them through a final round of validation
** (process:73361): DEBUG: 09:58:53.751: eth0: setting default backend to 1
** (process:73361): DEBUG: 09:58:53.751: Configuration is valid
DEBUG:Merged config:
b''

Então

$ sudo networkctl status

● Interfaces: 1, 2
       State: routable                        
Online state: online                          
     Address: xx.xx.xx.xx on eth0
              xx:xx:xx:xx:xx:xx on eth0
     Gateway: xx.xx.xx.xx on eth0
         DNS: 8.8.8.8
              208.67.222.222

Nov 25 17:00:42 example.com systemd-networkd[667]: eth0: found matching network '/run/systemd/network/10-netplan-eth0.network', based on potentially unpredictable interface name.
Nov 25 17:00:42 example.com systemd[1]: Starting systemd-networkd-wait-online.service - Wait for Network to be Configured...
Nov 25 17:00:43 example.com systemd-networkd[667]: eth0: Gained IPv6LL
Nov 25 17:01:12 example.com systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Nov 25 17:01:12 example.com systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
Nov 25 17:01:12 example.com systemd[1]: Failed to start systemd-networkd-wait-online.service - Wait for Network to be Configured.
Nov 25 17:35:12 example.com systemd[1]: Starting systemd-networkd-wait-online.service - Wait for Network to be Configured...
Nov 25 17:35:42 example.com systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Nov 25 17:35:42 example.com systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
Nov 25 17:35:42 example.com systemd[1]: Failed to start systemd-networkd-wait-online.service - Wait for Network to be Configured.

Em seguida, verifique Postfix, Dovecot e nginx

$ systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; preset: enabled)
     Active: active (exited) since Mon 2024-11-25 17:55:25 UTC; 20min ago
       Docs: man:postfix(1)
    Process: 1875 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
   Main PID: 1875 (code=exited, status=0/SUCCESS)
        CPU: 4ms

Warning: some journal files were not opened due to insufficient permissions.

$ systemctl status dovecot
● dovecot.service - Dovecot IMAP/POP3 email server
     Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled; preset: enabled)
     Active: active (running) since Mon 2024-11-25 17:55:20 UTC; 23min ago
       Docs: man:dovecot(1)
             https://doc.dovecot.org/
   Main PID: 719 (dovecot)
     Status: "v2.3.21 (47349e2482) running"
      Tasks: 17 (limit: 3481)
     Memory: 33.8M (peak: 40.8M)
        CPU: 552ms
     CGroup: /system.slice/dovecot.service
             ├─ 719 /usr/sbin/dovecot -F
             ├─ 732 dovecot/lmtp -L
             ├─ 733 dovecot/anvil
             ├─ 734 dovecot/log
             ├─ 735 dovecot/lmtp -L
             ├─ 736 dovecot/lmtp -L
             ├─ 737 dovecot/lmtp -L
             ├─ 738 dovecot/lmtp -L
             ├─ 740 dovecot/config
             ├─ 747 dovecot/stats
             ├─4383 dovecot/auth
             ├─4387 dovecot/auth -w
             ├─4388 dovecot/auth -w
             ├─4395 dovecot/dict
             ├─4396 dovecot/dict
             ├─4407 dovecot/imap-login
             └─4413 dovecot/imap

Warning: some journal files were not opened due to insufficient permissions.


$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Mon 2024-11-25 17:55:20 UTC; 25min ago
       Docs: man:nginx(8)
    Process: 741 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 838 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 859 (nginx)
      Tasks: 2 (limit: 3481)
     Memory: 5.0M (peak: 5.3M)
        CPU: 409ms
     CGroup: /system.slice/nginx.service
             ├─859 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             └─860 "nginx: worker process"

Warning: some journal files were not opened due to insufficient permissions.

Por fim, descobri que o sistema funciona como esperado, a menos que eu use o Roundcube, que fecha as portas novamente. Se eu acessar o e-mail somente pelo imap, as portas permanecem abertas.

Vou retirar o que disse. Ficou aberto por um tempo, depois fechou novamente. Na verdade, ao longo de algumas horas, ele vem e vai. Pode ser um conflito de dois componentes tentando controlar a rede?

Não tenho ideia de onde veio o arquivo de substituição para systemd-networkd-wait-online.service. Tentei excluir as três linhas ativas, mas elas simplesmente voltaram a existir na próxima vez que olhei. Os arquivos de status dão:

$ networkctl status eth0
● 2: eth0
                   Link File: /usr/lib/systemd/network/99-default.link
                Network File: /run/systemd/network/10-netplan-eth0.network
                       State: routable (configured)
                Online state: online                                                                       
                        Type: ether
                        Path: pci-0000:00:12.0
                      Driver: virtio_net
                      Vendor: Red Hat, Inc.
                       Model: Virtio network device
           Alternative Names: enp0s18
                              ens18
            Hardware Address: 00:16:3e:0b:31:2b (Xensource, Inc.)
                         MTU: 1500 (min: 68, max: 65535)
                       QDisc: fq_codel
IPv6 Address Generation Mode: eui64
    Number of Queues (Tx/Rx): 1/1
            Auto negotiation: no
                     Address: xx.xx.xx.xx
                              xx:xx:xx:xx:xx:xx
                     Gateway: xx.xx.xx.xx
                         DNS: 8.8.8.8
                              208.67.222.222
           Activation Policy: up
         Required For Online: yes
           DHCP6 Client DUID: DUID-EN/Vendor:0000ab11e96dc6ba966458ee
                Connected To: kv0632-185-127-18-185.localdomain.local on port d2:6f:9b:c0:5b:55 (tap2010i0)

e

$ networkctl status enp0s3
Interface "enp0s3" not found.

Modifiquei o arquivo de substituição com eth0 porque ainda não consigo remover essas linhas. Ele está rodando agora, mas o tempo dirá.

Isso resolveu o problema. Muito obrigado a mpboden, especialmente pela explicação lúcida do problema dada abaixo.

Falei cedo demais. Tendo ficado acordado por pouco mais de 24 horas, todas as portas fecharam novamente.

De uma máquina diferente:

% nmap taid.info
Starting Nmap 7.95 ( https://nmap.org ) at 2024-11-28 16:22 GMT
Nmap scan report for example.com (xx.xx.xx.xx)
Host is up (0.021s latency).
Not shown: 990 filtered tcp ports (no-response)
PORT    STATE  SERVICE
22/tcp  open   ssh
25/tcp  closed smtp
80/tcp  closed http
110/tcp closed pop3
143/tcp closed imap
443/tcp closed https
465/tcp closed smtps
587/tcp closed submission
993/tcp closed imaps
995/tcp closed pop3s

Nmap done: 1 IP address (1 host up) scanned in 35.61 seconds

e do servidor virtual

$ networkctl status
● Interfaces: 2, 1
       State: routable                        
Online state: online                          
     Address: xx.xx.xx.xx on eth0
              xx:xx:xx:xx:xx:xx on eth0
     Gateway: xx.xx.xx.xx on eth0
              xx:xx:xx:xx:xx:xx on eth0
         DNS: 8.8.8.8
              208.67.222.222

Suspirar ...

networking

1 respostas

  1. Best Answer

    Você indicou que existe um arquivo de substituição para systemd-networkd-wait-online:

    /etc/systemd/system/systemd-networkd-wait-online.service.d/override.conf

    Nesse arquivo você tem o seguinte. Observe que ele está adicionando a interface de rede ao comando, enp0s3.

    [Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online -i enp0s3:degraded --timeout=30

    Na página de manual do systemd-networkd-wait-online.service(8) , é afirmado o seguinte.

           --interface=INTERFACE[:MIN_OPERSTATE[:MAX_OPERSTATE]]
           Network interface to wait for before deciding if the system is online. This is useful
           when a system has several interfaces which will be configured, but a particular one is
           necessary to access some network resources. When used, all other interfaces are
           ignored. This option may be used more than once to wait for multiple network
           interfaces. When this option is specified multiple times, then
           systemd-networkd-wait-online waits for all specified interfaces to be online.
           Optionally, required minimum and maximum operational states can be specified after a
           colon ":". Please see networkctl(1) for possible operational states. If the
           operational state is not specified here, then the value from RequiredForOnline= in the
           corresponding .network file is used if present, and "degraded" otherwise.

    A conclusão é que a interface de rede deve esperar antes de decidir se o sistema está online . Então isso significa que systemd-networkd-wait-onlineestá esperando que a interface enp0s3esteja no estado mínimo necessário de degraded. A página de manual para networkctl(1) afirma o seguinte:

               degraded
               The link has carrier and addresses valid on the local link configured. For bond or
               bridge master this means that not all slave network interfaces have carrier but at
               least one does.

    Mas você não tem uma interface chamada enp0s3, que é mostrada com a saída de networkctl status enp0s3. Então suspeito que essa configuração incorreta esteja causando falha no estado da sua rede.

    Para corrigir, remova o arquivo de substituição com o seguinte:

    sudo rm /etc/systemd/system/systemd-networkd-wait-online.service.d/override.conf

    Em seguida, recarregue o processo systemd para que ele não faça mais referência a este arquivo de substituição:

    sudo systemctl daemon-reload
    • 0

relate perguntas