Recentemente troquei meu roteador por um Billion 7800VDOX e notei algumas tentativas de conexão com meu iMac a partir de endereços externos. Na investigação, descobri que uma porta uPnP foi aberta no roteador com intervalo de portas 0-0 (interna e externa). Isso tem o efeito, verificado com um scanner de porta externo, de abrir TODOS os números de porta no roteador e direcioná-los para o iMac. Excluí o mapeamento, executei o Wireshark e capturei uma solicitação de endereço externo ao mesmo tempo em que o mapeamento foi restaurado.
Frame 496: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface 0
Ethernet II, Src: Apple_d0:7e:eb (d4:9a:20:d0:7e:eb), Dst: BillionE_cb:49:27 (00:04:ed:cb:49:27)
Internet Protocol Version 4, Src: 192.168.1.131, Dst: 192.168.1.254
User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5351 (5351)
Source Port: 5353
Destination Port: 5351
Length: 68
Checksum: 0x8527 [validation disabled]
[Stream index: 0]
Port Control Protocol, Map Request
Version: 2
0... .... = R: Request
.000 0001 = Opcode: Map (1)
Reserved: 0
Requested Lifetime: 7200
Client IP Address: ::ffff:192.168.1.131
Map Request
Mapping Nonce: f88237920f8cd6c0a3765f39
Protocol: 6
Reserved: 0
Internal Port: 9
Suggested External Port: 0
Suggested External IP Address: ::ffff:xxx.181.81.112
Isto foi precedido por uma solicitação SOAP para obter o endereço IP externo do roteador. Verificando a porta de origem (5353) com lsof descobri que ela pertence ao mDNSResponder.
Minha suposição sobre o que está acontecendo é que o mDNSResponder está usando isso apenas para obter o endereço IP externo do roteador, e fazendo isso usando uma solicitação supostamente inofensiva para mapear a porta 0, que deveria ser uma porta inválida. No entanto, o roteador Billion está tratando isso, seja por erro de design ou de programação, como uma solicitação para abrir todas as portas. Desligar o uPnP no roteador resolve o problema (mesmo que, como apontado, isso não seja realmente uPnP).
Alguém tem alguma outra sugestão?
Responder1
O pacote que você capturou mostra uma solicitação de mapeamento de porta do Protocolo de Controle de Porta (PCP: o sucessor de rastreamento de padrões IETF do NAT-PMP). A porta do cliente para o mapeamento solicitado é 9/TCP. O cliente não tem nenhuma sugestão de qual deveria ser a porta externa, então deixa o campo de porta externa sugerida definido como zero. A IETF RFC 6887, que define PCP, deixa claro que zero significa “nenhuma sugestão” neste campo.
Acho que quem implementou o PCP para este roteador Billion interpretou mal o RFC. Veja, em alguns casos muito limitados e bem definidos, um zero no campo OTHER port pode significar "todas as portas". Como quando o tempo de vida solicitado para esta solicitação de mapeamento é zero, uma porta de cliente zero significaria "excluir todos os mapeamentos para todas as portas neste endereço IP do cliente".
Mas, novamente, no campo de porta externa sugerida, zero sempre significa "sem sugestão". Nunca se supõe que signifique "todas as portas" neste campo.
Portanto, parece bastante claro que você encontrou um bug de PCP neste roteador Billion.
Outra coisa estranha aqui é a porta do cliente. Tradicionalmente, 9/TCP é a discardporta do serviço, mas o discardserviço está obsoleto, então não tenho mais certeza de quem o executaria ou por que alguma coisa estaria solicitando um mapeamento de porta para ele.
Quanto ao motivo pelo qual o mDNSResponder está enviando essas solicitações, é simplesmente porque o mDNSResponder atua como o daemon PCP/NAT-PMP/UPnP no macOS, além de suas funções habituais de mDNS, DNS-SD e resolvedor de DNS. Quando qualquer processo no macOS aciona o sistema para solicitar um mapeamento de porta do roteador, é sempre função do mDNSResponder criar e enviar os pacotes reais de solicitação de mapeamento de porta.