Tengo banda ancha Airtel (ISP) en casa. El mismo ISP es también mi proveedor de red móvil. Tengo un enrutador DIR 615 conectado a Airtel Broadband, una computadora de escritorio y una computadora portátil con Windows 10.
Cuando estoy en Airtel Broadband, ambas PC con Windows 10 no pueden sincronizar la hora con varios servidores NTP de Internet. Devuelve el tiempo de espera. He probado entre 10 y 12 servidores NTP. Sin embargo, otros dispositivos como mi máquina virtual Linux y el enrutador DIR 615 pueden sincronizar la hora correctamente en la misma banda ancha con los mismos servidores NTP. Sin embargo, cuando cambio a VPN en Windows 10 y evito el ISP, la PC con Windows 10 puede sincronizar con éxito la hora con varios servidores NTP.
Además, cuando uso aplicaciones de terceros como Nistime32bit.exe, sincronizan la hora con servidores NTP en la misma PC con Windows 10 en Airtel Broadband con éxito. Lo he probado tanto en el puerto TCP 13 como en el UDP 123. Ahora, cuando tengo un punto de acceso móvil de Airtel, ambas PC con Windows 10 sincronizan la hora correctamente sin dar ningún error de tiempo de espera. Es difícil creer que el ISP esté bloqueando los puertos salientes porque el enrutador y la máquina virtual Linux se sincronizan correctamente en la misma red e incluso aplicaciones de terceros en una PC con Windows 10. Sin embargo, las PC con Windows 10 con el proceso integrado de Windows 10 fallan. Es difícil creer que haya problemas con ambos sistemas operativos Windows 10 porque se sincronizan correctamente en el punto de acceso móvil. El servicio W32time funciona bien en ambas PC.
Pedí ayuda al ISP pero no responden.
¿Alguien sabe qué está pasando realmente aquí? ¿Qué más puedo intentar solucionar y dónde podría estar el problema? Revisé el Visor de eventos, hay un montón de eventos pero no encontré nada significativo.
El firewall está completamente APAGADO en el enrutador y en Windows 10. Los mismos resultados si evito el enrutador y hago una conexión PPPoE directa desde mi PC al ISP.
Edite después de ver los comentarios y responder.
Probé varios servidores, incluidos algunos ubicados en mi país, pero el comportamiento es constante. Banda ancha: fracaso, VPN: éxito, punto de acceso móvil: éxito. Enrutador en banda ancha: éxito, VM Linux en banda ancha: éxito.
Gracias @ user1686 por la respuesta detallada. Ése era el eslabón perdido del rompecabezas.
Todos los ISP de mi país funcionan y se comportan de la misma manera. Todos bloquean los puertos entrantes por debajo de 1024. Tenía la impresión de que para la sincronización NTP es de cliente a servidor, pero no conocía Symmetric 123 <-> 123 de Windows, por lo que incluso el 123 entrante importa.
Ahora he probado que mi ISP efectivamente bloquea el UDP 123 entrante enviando paquetes mágicos para iniciar mi PC de forma remota. Cuando lo envío para decir UDP 4000 (enrutado a UDP 9 en el enrutador), a través de mi Internet móvil a la IP pública de banda ancha, se activa, pero en UDP 123 (enrutado a UDP 9) falla. También he utilizado una pequeña utilidad llamada SimplePort Tester (PCWinTech.com) para volver a comprobar que efectivamente no se puede acceder al UDP 123 entrante.
Intenté sincronizar la hora en mi máquina virtual con Windows XP, suponiendo que podría estar usando NTPv3 anterior, pero ni siquiera pude sincronizar la hora en banda ancha. Entonces, parece que incluso XP en aquellos días usaba 123 <-> 123.
Convenceré a mi ISP para que abra el UDP 123 entrante al menos durante algún tiempo para realizar pruebas, ¡pero hay muy pocas posibilidades de que consideren mi solicitud!
Respuesta1
La mayoría de los clientes NTP y SNTP funcionan en modo "Cliente/Servidor". Esto es lo mismo que otros clientes UDP: la computadora envía una consulta NTP desde un puerto efímero al puerto NTP 123 del servidor y recibe una respuesta del puerto 123 a ese puerto efímero. Lo más probable es que así sea como se comporta su cliente NTP de Linux.
El cliente NTP integrado de Windows, sin embargo, utiliza el modo "simétrico", en el que envía paquetesdesde el puerto local 123al puerto 123 del servidor. Las respuestas, igualmente, llegan desde el puerto remoto 123 al puerto local 123.
(Este uso de puerto simétrico es algo exclusivo de NTP y se encuentra más comúnmente en situaciones de igual a igual cuando dos servidores NTP se sincronizan entre sí. No estoy seguro de por qué Windows hace esto, pero podría deberse al hecho que Windows Server puede actuar como un servidor NTP real, como parte de la funcionalidad AD DC).
Pero el problema con el modo "simétrico" es quea un firewall de red,estas respuestas entrantes a su puerto 123 son completamente indistinguibles 1 de las entrantespeticionesal puerto 123.
Muchos ISP implementan firewalls a nivel de red para bloquear ciertos protocolos "riesgosos", por ejemplo, aquellos que son fáciles de abusar para la amplificación de DDoS, y desafortunadamente NTP es uno de ellos. Entonces, como precaución, un ISP podría bloquear todos los paquetes UDP entrantes al puerto 123 de sus clientes, creyendo incorrectamente que esto sólo impide que los clientes ejecuten un servidor NTP.
Alternativamente, el ISP podría estar haciendo esto bajo el supuesto de que todos los clientes tienen enrutadores personales con NAT, y muchos enrutadores en realidad reasignan el puerto local de los paquetes salientes, por lo que incluso si una computadora envía un paquete 123→123, el enrutador podría traducirlo a 61473→123 y el problema no ocurrirá. Sin embargo, no todos los enrutadores realizan ese tipo de reasignación (este tipo de NAT a menudo termina interfiriendo con los juegos).
Sugerencias:
Si su enrutador le permite elegir entre "NAT de cono" y "NAT simétrica", intente cambiar a este último y vea si ayuda (y no, el término en realidad no tiene nada que ver con NTP simétrico).
De lo contrario, es posible que tengas que seguir utilizando clientes NTP de terceros, que funcionan en modo Cliente y no tienen este problema.
Hay un Microsoftartículo de la base de conocimientossobre especificar qué modo usar, pero si bien afecta los bits de modo en el encabezado NTP, nonoen realidad hace que Windows use un puerto de origen diferente. Desgraciado.
(NTPv3 especificó que el puerto de origen debenoser 123 en modo cliente, pero NTPv4 ya no lo prohíbe, por lo que podría ser por eso que Windows usa felizmente 123→123 independientemente de qué indicadores de modo se especifican en el encabezado NTP).
1 Un firewall con estado, como el del enrutador de su hogar,poderdistinga las consultas de las respuestas realizando un seguimiento de los paquetes salientes vistos anteriormente. Pero si bien los cortafuegos con estado son comunes en límites de redes más pequeños, sospecho que no escalan fácilmente a niveles de "ISP completos", ya que buscar el estado de cada paquete significa un rendimiento reducido. Entonces, si el ISP opera unapátridafirewall, la afirmación sigue siendo cierta: los dos tipos de paquetes NTP se vuelven indistinguibles en modo simétrico.