Recientemente cambié mi enrutador por un Billion 7800VDOX y noté algunos intentos de conexión a mi iMac desde direcciones externas. Al investigar, descubrí que se había abierto un puerto uPnP en el enrutador con un rango de puerto 0-0 (interno y externo). Esto tiene el efecto, verificado con un escáner de puertos externo, de abrir TODOS los números de puerto en el enrutador y dirigirlos a el iMac. Eliminé la asignación, ejecuté Wireshark y capturé una solicitud de dirección externa al mismo tiempo que se restauró la asignación.
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
Esto fue precedido por una solicitud SOAP para obtener la dirección IP externa del enrutador. Al verificar el puerto de origen (5353) con lsof, encontré que es propiedad de mDNSResponder.
Mi suposición sobre lo que está sucediendo es que mDNSResponder está usando esto solo para obtener la dirección IP externa del enrutador, y lo hace usando una solicitud supuestamente inofensiva para asignar el puerto 0, que debería ser un puerto no válido. Sin embargo, el enrutador Billion está tratando esto, ya sea por error de diseño o de programación, como una solicitud para abrir todos los puertos. Desactivar uPnP en el enrutador resuelve el problema (aunque, como se señaló, en realidad esto no es uPnP).
¿Alguien tiene alguna otra sugerencia?
Respuesta1
El paquete que capturó muestra una solicitud de asignación de puertos del Protocolo de control de puertos (PCP: el sucesor de seguimiento de estándares IETF de NAT-PMP). El puerto de cliente para la asignación solicitada es 9/TCP. El cliente no tiene ninguna sugerencia sobre cuál debería ser el puerto externo, por lo que deja el campo de puerto externo sugerido establecido en cero. IETF RFC 6887, que define PCP, deja claro que cero significa "sin sugerencia" en este campo.
Creo que quien implementó PCP para este enrutador Billion leyó mal el RFC. Verá, en algunos casos muy limitados y bien definidos, un cero en el campo OTRO puerto podría significar "todos los puertos". Al igual que cuando la vida útil solicitada para esta solicitud de asignación es cero, un puerto de cliente cero significaría "eliminar todas las asignaciones para todos los puertos en esta dirección IP de cliente".
Pero nuevamente, en el campo de puerto externo sugerido, siempre se supone que cero significa "sin sugerencia". En este campo nunca se supone que signifique "todos los puertos".
Entonces parece bastante claro que ha encontrado un error de PCP en este enrutador Billion.
Otra cosa extraña aquí es el puerto del cliente. Tradicionalmente, 9/TCP es el discardpuerto del servicio, pero el discardservicio está en desuso, por lo que no estoy seguro de quién lo ejecutará más ni por qué algo solicitaría una asignación de puerto para él.
En cuanto a por qué mDNSResponder envía estas solicitudes, es simplemente porque mDNSResponder actúa como el demonio PCP/NAT-PMP/UPnP en macOS además de sus tareas habituales de resolución de mDNS, DNS-SD y DNS. Cuando cualquier proceso en macOS hace que el sistema solicite una asignación de puertos desde el enrutador, siempre es trabajo de mDNSResponder crear y enviar los paquetes de solicitud de asignación de puertos reales.