今回はインターネット接続をIPv4のPPPoE方式からIPv6接続に変更した際に出くわした不具合とその原因、行うべき対処法についてのメモ的な話題です。
Windowsでは、XPからIPv6が使用可能になりました。Windows7が登場した2009年以降は、IPv4よりIPv6を優先する構成が身近になり、PCやスマートフォン、タブレット、各種ネットワーク機器でもIPv6を本格的に利用できるようになりました。ただ、当時の社内LANなどではIPv6に未対応の機器も混在していました。そのため、IPv6が既定で有効でも、初期設定時にあえて無効にし、内部の通信をIPv4にそろえる運用が一般的だったと記憶しています。実際、このコラムでもかつてWindowsの初期設定時にはv6を無効にしておいたほうがドメインネットワークでは安全といった内容の記事（2021/3/1）を書いたことがありました。
さすがにIPv6に非対応という現行製品に出会うことも考えにくいので、LAN内部であればIPv6が有効でもこれといった不具合に遭遇することは稀でしょう。しかし、インターネット接続プロバイダーの接続サービスでは現在でもIPv4のみのサービスでv6には非対応ということも少なくありませんが、従来のIPv4によるPPPoE接続に加えてIPv6での接続サービスを本格的に提供する業者も増えています。自宅で利用しているインターネット接続のプロバイダーも数年前から正式なサービスメニューにIPv6での接続を導入していましたが、こちらで使用しているルーターもISPの提供サービスに対応する機能が使えるようになったため、１か月ほど前にこの方式に変更しました。設定変更自体はルーターのメーカーとプロバイダーが公開している情報を参考にしてあっという間に終わりました。
その後、このルーターにぶら下がっているPCやスマートフォンでのWebアクセスのレスポンスは設定変更前よりも早くなっており、一般的なクライアントPCなどの端末とインターネットとの接続に関しては特段の問題に見舞われずに移行できました。ということで、ルーター自体の端末レベルではめでたしめでたしだったのですが、IPv6接続に変更した時期以降に各種検証用に稼働させているWindowsサーバーにActive Directory環境のアカウント認証で予想していなかったトラブルが発生して対処方法を調べたところ、この接続方法変更に際に内部で運用するActive Directory環境を考慮していくつかの設定の見直しが必要だったことがわかりました。
Active Directory環境では、認証基盤であるドメインコントローラーがアカウント管理やユーザー認証、各種権限設定を担います。また、複数のドメインコントローラー間や、Active Directoryに登録されたクライアントPCとの間では、認証や設定の同期に必要な通信が行われます。この通信先を見つけるうえで重要なのが、ドメインコントローラーと密接に連携して動作するDNSサービスです。認証要求を送る際にも、まずDNSサーバーから通信先のドメインコントローラーを見つけるための情報を取得する必要があります。したがって、DNDサーバーから正しい情報を取得できないとドメインコントローラーと通信できずに認証エラーが発生します。Active Directoryで管理されたネットワーク内のサーバーも含めた各種端末のネットワーク設定ではActive Directoryと連携しているDNSサーバーを参照先DNSサーバーに指定していますが、ここではサーバー・クライアントを問わず端末のIPアドレスと参照先DNSサーバーのIPアドレスはIPv4で設定を行います。
当然手元の検証環境ではその通りに設定して安定して使用できていたのですが、インターネット接続方式をIPv6のDS-Liteに変更以降、別のPCにリモートデスクトップで接続しようとすると接続先PCのローカルアカウントでは問題なくても、ドメインユーザーのアカウントの場合はドメインコントローラーと通信ができない認証エラーが多数発生するようになり、ローカルアカウントで接続できた端末のネットワーク設定状態を確認すると、ネットワーク設定の時点では指定していない最優先のDNS参照先がIPv6のアドレスになっている状態でした。
ドメインに所属しているPCにドメインユーザーのアカウントでログオンを行う場合、そのPCで設定した参照先DNSのIPv4アドレスで稼働しているドメインコントローラーが認証の処理を行いますが、参照先DNSのIPアドレスとしてIPv6接続に設定変更したルーターからv6のDNS情報が配信されていて、これが1番目の参照先DNSにセットされているため、アカウント認証の要求を参照先DNSとしてこのIPv6アドレスに問い合わせを行ってしまい、そのアドレスにはドメインコントローラーが存在しないために認証エラーを引き起こしていました。
現状、リモートデスクトップ接続できない状態以外の不具合は起きていないようなので、そのままにしていますが、対処としてはルーターのIPv6によるDNSサーバーアドレスの配信を停止してからネットワーク内にぶら下がっている各端末を再起動するか、LANケーブルの抜き差しでネットワーク設定のリセットすることになりそうですが、今後ネットワーク運用のサポート先で同様にインターネット接続についてIPv6対応を行う場合には今回の事例を踏まえた事前検証でトラブルを回避できそうです。
2026年11月