VPN 切断後に Mac の IPv6 状態を確認する方法

トンネルが落ちたあとに IPv4 でサイトに到達できても、IPv6 については何も証明できていません。macOS は二つのファミリーをネットワークサービスごとに別々に設定し、VPN クライアントは片方を他方に触れずに変えられます。アドレス設定、経路の選択、そして切断中にクライアントが入れるポリシーという三つの層を順に確認します。その間アクセスネットワークを変えなければ、別の問題を比較することになります。

実際に壊れたファミリーから始める

IPv4 で読み込めるページは、物理ネットワークが生きていることだけを示します。サービスにグローバルな IPv6 アドレスがあるか、プレフィックスがまだ広告されているか、何かがファミリーを絞り込んでいないかは分かりません。到達できないアドレスに解決される名前はまったく解決しない名前と見分けがつかないため、道具を選ぶ前に何が失敗したのかを確かめてください。どの層が誤って答えたのかを尋ね、答えを書き留めます。それがなければ、後の手順はすべて手続きの衣装を着た推測です。

比較の間は同じ Wi-Fi ネットワークと同じアクセスポイントを使ってください。昨日 IPv6 を提供していたカフェのネットワークは、いまいるネットワークについて何も語りません。

経路より先にアドレスを読む

システム設定では、有効なサービスの TCP/IP パネルに IPv6 が自動、手動、リンクローカルのどれかが表示されます。想定と比べる際は、組織が意図的に手動設定を選んでいる場合もあることに留意してください。次に ifconfig を実行し、該当するインターフェースを読みます。 fe80:: アドレスだけでは、そのインターフェースが隣接ノードと通信できるというだけで、利用可能な経路の証拠にはなりません。

クライアントが残した utun インターフェースも探してください。古いトンネルデバイスは、クライアントが使わなくなった後も長くアドレスと経路を保持できます。見つかった場合はクライアントの所有者にとってのライフサイクル上の発見であり、その場で削除するものではありません。

失敗した宛先の経路表を読む

既定経路ではなく、失敗した宛先についてカーネルに問い合わせます。 route -n get 2001:db8::25 はそのアドレスに選ばれたインターフェースとゲートウェイを表示し、 netstat -rn -f inet6 は比較用に表全体を示します。既定経路は既定が存在することを教えてくれますが、この宛先がそれを使っているかは教えてくれません。

DNS は別の区画に置きます。IPv4 で到達できるリゾルバでも AAAA レコードは返せるので、検索の失敗と経路の失敗はブラウザで同じ症状になります。

クライアントのブロックポリシーと残留物を分ける

一部のクライアントは 切断中に通信をブロックするよう設計されており、もう一方のアドレスファミリーも含めて、これは不具合ではなく仕様です。

ブロックを損傷として扱う前に、クライアントがどの挙動を文書化しているかを確認してください。 scutil --dns はサービスごとに有効なリゾルバを示し、クライアントが入れたリゾルバやスコープ付き DNS 設定が見えるのはここです。次にパケットフィルタのルールが入れて残されたかを調べます。想定されたブロックと残ったルールは逆の対応を要し、両者を分けるのは所有者の文書だけです。

証拠を集めてから一つだけ変える

クライアントのバージョン、macOS のバージョン、ネットワークサービス、想定した切断時のポリシー、そして接続と切断の一サイクルの両側で得たアドレスと経路の出力を記録します。その記録が苦情を調査可能なライフサイクル問題に変えます。その後、変更を一つだけ行い、もう一度測ります。

リセットに抗してください。仮想インターフェースの削除、経路表の消去、マシン全体での IPv6 無効化は、記録すべき状態をいずれも破壊し、無関係な設定まで巻き込むことがあります。クライアントに一時停止、修復、アンインストールのサポートされた流れがあればそれを使い、ネットワークが管理されている場所では管理者の手順に従ってください。すでにリセットされたマシンは所有者に何も残さず、たいてい次の接続で同じ不具合を再現します。