自宅のホームネットワークでIPv6がなぜ動作しなかったのか？

 (gowtham.dev)
1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • ホームネットワークで ping google.com は成功したものの ping6 google.com は失敗し、原因は Adguard Home DNS の設定で IPv6 DNS クエリ が無効化されていたことだった
  • ACT broadband は過去に IPv6 をサポートしていなかったが、Chennai のユーザー向けに段階的に展開中であることが確認され、ルーターで IPv6 を有効にした際には正常に動作していた
  • 最近ネットワークをテストしている際に IPv6 の問題が再び表面化したが、ルーターの管理ポータルでは ISP の IPv6 接続 自体は確認でき、macOS と Raspberry Pi でも同じ問題が再現した
  • dig AAAA google.com で DNS の結果が返らなかったため、問題の範囲は ISP 接続やクライアント設定ではなく、AAAA レコードの問い合わせ を処理する DNS サーバー側へと絞り込まれた
  • 昨年 DNS を Adguard Home に移行したあとに生じた設定問題で、IPv6 DNS クエリをブロックするトグルをオフにすると ping -4 と ping -6 の両方がパケット損失 0% で成功した

原因と解決

  • ホームネットワークで ping google.com は成功したものの ping6 google.com は失敗し、最終的な原因は Adguard Home DNS の設定で全ての IPv6 DNS クエリ が無効化されていたことだった
  • ACT broadband はしばらく IPv6 をサポートしていなかったが、数年前に Chennai のユーザー向けへ段階的に展開中であることが確認され、ルーターで IPv6 を有効にした後は当時問題なく動作した
  • 最近デスク環境を変更しながらネットワーク接続をテストしていたところ、IPv6 の問題が再び明らかになり、ルーター管理ポータルでは ISP の IPv6 接続自体は確認できた
  • macOS のネットワーク設定でも IPv6 は許可されており、ルーターに LAN 接続された Raspberry Pi でも同じ問題が再現したため、特定デバイス固有の問題とは考えにくかった
  • IPv6 アドレスを直接テストするために dig AAAA google.com を実行したが DNS の結果は返らず、Google が IPv6 をサポートしていることから DNS サーバー側の問題が疑われた
  • 昨年 DNS を Adguard Home に移したことを思い出して DNS サーバー設定を確認したところ、IPv6 DNS クエリを遮断する小さなトグルを見つけた
  • その設定を解除して保存すると、IPv4 と IPv6 の両方が正常に動作した

確認プロセスと結果

  • 症状の確認

    • IPv4 の名前解決と接続は正常に動作した
    • IPv6 の名前解決または接続は失敗した
    • 使用した基本テストは次のとおり 
      ping google.com
ping6 google.com

  • ISP とデバイス設定の確認

    • ISP が IPv6 を再び無効化した可能性をまず疑ったが、ルーター管理ポータルで IPv6 接続は確認できた
    • macOS のネットワーク設定でも IPv6 は許可されていた
    • Raspberry Pi でも同じ問題が発生し、単一クライアントの設定問題とは考えにくかった
    • 独自の DNS サーバーを使用中だったため、ルーターの IPv6 DNS サーバーアドレスと Raspberry Pi のイーサネットインターフェース IP アドレスも照合した

  • DNS 問題へ絞り込んだ手がかり

    • DHCP の IPv6 DNS 配布の問題を除外するため IPv6 アドレスを直接確認しようとしたが、dig AAAA google.com で結果が返らなかった
    • この段階で問題は ISP 接続やクライアントでの IPv6 許可の有無ではなく、AAAA レコードの問い合わせ を処理する DNS サーバー側へと絞り込まれた

  • 修正後の検証

    • Adguard Home の設定で IPv6 DNS クエリを無効化するトグルを解除したあと、ping -4 と ping -6 の両方が成功した
    • IPv4 テストでは 172.217.24.110 に対して 5 パケット送信、5 受信、パケット損失 0% だった
    • IPv6 テストでは 2404:6800:4007:817::200e に対して 5 パケット送信、5 受信、パケット損失 0% だった
    • IPv6 を有効にすると、レイテンシの低下、NAT traversal が不要なより良い P2P 接続、SLAAC のような利点がある

関連記事

1件のコメント

 
GN⁺ 2 시간 전
Lobste.rs の意見

  • これはひどいし、AdGuard Home は恥じるべき

    • その設定はデフォルトで有効になっているわけではなさそう
      私も AdGuard Home を使っているが、こちらでは無効になっており、設定やルーターを入れ替えてからまだ 2 週間も経っていないので、自分で触っていないということにはかなり自信がある

  • なぜこんな機能が存在するのかわからない

    • DNS 広告ブロックのコミュニティ全体、特に AdGuard や Pi-hole のようなところは、歴史的に IPv6 とデュアルスタックネットワーク にかなり敵対的だったから
      こうしたサービスにサポート依頼が来ると、公式サポートチャネルであれフォーラム、Discord、サブレディットのようなプロジェクトコミュニティであれ、今でも最初の推奨が「IPv6 を無効にしろ」という感じになりがち

  • IPv6 は設計が悪く設定ミスもしやすいので、いちばんありがちな助言が無効化になってしまう

  • さっきちょうど逆の問題をデバッグしたところで、自宅ネットワークで IPv4 が動かなかった
    IPv4 接続のために DS-Lite を使う IPv6 専用サービスで、DS-Lite ではホームルーターが IPv4 パケットを ISP の NAT である AFTR にトンネリングする
    AFTR のドメインは DHCPv6 で提供され、私の場合は something.aftr.kabelbw.de の形式だったが、今は denic has some trouble with its DNSSEC configuration のためこのドメインを解決できない
    幸い、どこでも IPv6 を無効にしていなかったので、GitHub を除けばすべて正常に動作している