Windows 10 で時計を同期できません。
コントロール パネルで同期を要求するか、またはw32tm /resyncコンピューターを実行して同期を要求すると、NTPv3 パケットがいくつか送信されますpool.ntp.org(そのサーバーは手動で設定していますが、どのサーバーを使用するかは関係ありません) が、応答がありません。
ただし、w32tm /monitor /computers:pool.ntp.orgこれを実行すると動作し、Wireshark でコンピューターが NTPv1 パケットを送信し、応答を受け取ったことを確認できます。
ただし、コンピューターを携帯電話のモバイル ホットスポットに接続すると、NTPv3 を使用して時刻同期が機能します。また、Windows 10 と同じネットワーク上にある別の Linux コンピューターも問題なく同期できます (NTPv4 を使用しているのがわかります)。
私が試してみました：
- Windows タイム サービスの再起動
- Windows タイム サービスのリセット
- ルーターのファイアウォールでポート123を開く
- DNS設定の変更（DNS-over-TLSを使用）
そして、それが機能しませんでした。
私のルーターは二重 NAT 構成 (つまり、インターネット - 私が制御していない別のルーター - 私のルーター - 私の PC) になっており、NTP の問題が発生する可能性がありますが、Linux ラップトップがどのように同期できるのか理解できません。
編集1:
応答付きNTPパケット
応答のないNTPパケット
答え1
コメントで議論されているように、違いWindowsのW32timeサービスは、宛先ポートと宛先ポートの両方でNTPポート番号を「対称」モードで使用します。およびソース純粋にクライアントとして動作し、対称ピアとして機能するように設定されていない場合でも、ポート番号は 123 です (その機能があります)。
つまり、ステートレス ファイアウォールは、受信応答と受信クエリを区別する方法がありません。どちらもポート 123 に到着するためです。また、ISP に NTP サーバーのホスティングを妨げるフィルターがある場合は、このモードで動作する NTP クライアントの使用も妨げられます。
Linux NTP ソフトウェアは通常、プロトコル仕様に準拠しており、他のほとんどの UDP ソフトウェアと同様に、クライアント/サーバー モードで一時的なソース ポートを使用します (123→123 は完全に対称モード用です)。同様に、このw32tmツールは、モニター/ストリップチャート オプションによって、一時的なポートにバインドされた通常のソケットを使用して独自の NTP クエリを生成するため、機能します。
常にオンラインになっている Linux または BSD システムがある場合は、そのシステムを内部 NTP サーバーとして使用できます (たとえば、Chrony または ntpd を中品質のサーバーとして動作させるには、ほとんど設定は必要ありません)。
これは WSL2 でも機能するはずです。WSL2 のカーネル クロックはホスト クロックに厳密に結び付けられていないためです (私の記憶では)。WSL2 内で Chrony を NTP サーバーとして実行し、RTC の更新を試行しないように指示するだけで済みます。
VPN を経由できる場所があれば、NTP に VPN 接続を使用できる可能性があります。
サードパーティの Windows NTP クライアントも動作するはずです。特に、ローカル ポート 123 がすでに W32time によって使用されている場合は、別のローカル ポートを使用するしかありません。たとえば、ネットタイムうまくいくかもしれないようです。
NTP以外のプロトコル用のサードパーティクライアントも、同じUDPポートを使用しないため、機能する可能性があります。精度はNTPほど高くありませんが、PCには十分です。たとえば、NISTは、ニストムNTP と古い RFC-868 プロトコルを使用できるクライアント。