macOS での OpenVPN TAP: デバッグの前にクライアントを確認する

古いプロファイルが最新の Mac に届き、クライアントは何の警告もなくそれを取り込み、接続は切れるか、まったく通信が通りません。証明書に午後を丸ごと費やす前に、プロファイルのデバイス行を読んでください。そこに dev tap と書かれていれば、Ethernet 風のインターフェースをクライアントに要求していることになり、macOS ではこうしたセッションの多くがまさにその要求で終わります。

ステップ 1: プロファイルが本当に TAP を要求しているか確認する

プロファイルは名前を変えられ、包まれ、再エクスポートされるので、実際に取り込んだファイルを確認してください。デバイス指示と、それを上書きしうる include を探します。多くの場合、出力の二行で決着がつきます。dev と dev-type の両方が現れたときは後ろの指示が勝ち、コピーされたプロファイルはまさにそうした細部を隠しています。

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

ファイルに dev tap または dev tap0 があれば、クライアントは TAP インターフェースを実装する必要があります。dev tun があれば、この記事の残りは当てはまらず、障害は別の場所にあります。

クライアントの名前とバージョン、macOS のバージョン、プロファイルの出どころを書き留めてください。この三つが、以下の二つの道のどちらがそもそも可能かを決めます。

ステップ 2: デバイスモードが実際に何を変えるのかを知る

TUN インターフェースは IP パケットを運びます。クライアントは IP ピア宛てのパケットを読み書きし、オペレーティングシステムは他のインターフェースと同じようにそれをルーティングします。

TAP インターフェースは Ethernet フレームを運び、ブロードキャストや ARP も含みます。これによりブリッジ構成のサーバーは DHCP でアドレスを配布でき、クライアントは大声で呼びかけて機器を発見できるので、古い設計の一部はこれに依存しています。

代償は、TAP がシステムに Ethernet インターフェースを提示するドライバーを必要とすることです。Apple は古い Mac 用 TAP ドライバーが頼っていたカーネル拡張モデルを廃止し、その代替 API は使うために一度も更新されていないクライアントの中に魔法のように現れるわけではありません。プラットフォームの能力と出荷済みの製品は別物です。

ステップ 3: 対応クライアントと移行のどちらかを選ぶ

正直な道は二つあります。一つ目は、あなたの macOS のリリースとハードウェアについて、必要な TAP 構成をサポートすると発行元が明言しているクライアントです。四年前のフォーラム投稿でも、アーカイブされたインストーラーでもなく、現在の声明とテスト接続です。

二つ目はサービスを TUN へ移すことで、これはクライアントの変更と同じくらいサーバーの変更でもあります。ルーティングされたトポロジー、アドレスプール、リモートネットワーク向けのプッシュルート、そしてそれらのネットワークからプールへの戻り経路が必要です。

うまくいかないのは、ローカルのコピーで tap を tun に書き換えて期待することです。サーバーはまだブリッジしており、クライアントは IP を話し、何もかみ合いません。

ステップ 4: 稼働中のサービスを変える前に事実を集める

元のプロファイルはそのままにし、実験用のコピーを作ります。一分で戻せるファイルは、整ったフォルダーより価値があります。代替が動いたら、一覧で同じに見える二つのプロファイルを残さず、コピーを意図的に削除してください。その一つの習慣が、移行の失敗後に起きる混乱のほとんどを防ぎます。現在の挙動を記録し、トンネルが上がるか、アドレスを取得するか、既知のホストに届くか、名前解決が動くかという変化を証明できるようにします。

ゲートウェイの所有者に 三つ尋ねてください。サーバーはブリッジ構成かルーティング構成か。どのリモートプレフィックスに到達できるべきか。設定変更のための保守時間帯があるのか、それともサーバーに触れずに動くことが前提なのか。

その答えが、今日の午後にクライアントの問題を解くのか、来週ネットワーク変更を計画するのかを決めます。

ステップ 5: 両端から移行を検証する

サーバーにルーティング設定があり、あなたに合うプロファイルがあれば、トンネルが確立し、クライアントが新しいプールからアドレスを受け取り、遠端のホストが応答し、プッシュされた DNS 設定で名前が解決する、という順に試します。

次に、以前 Ethernet の挙動に依存していたものを試します。アプリがブロードキャストで機器を発見していたなら、ルーティングされたトンネル越しには見つかりませんし、クライアント設定をいくら変えても戻りません。そのアプリには既知のアドレス、ローカルの補助ホスト、または別の発見方法が必要です。

最初の試行でしか動かないプロファイルは通常、プッシュルートや DNS 設定が再接続時に適用されていないことを意味するため、再接続と再起動を一度ずつ行って終えてください。

それでも失敗するときは、最初のエラーを読む

インターフェースを作れないクライアントは、たいていログの最初の数行でそう言います。作ったものの認証に失敗するクライアントは、デバイスの問題をとうに通り過ぎており、TAP を追い続けるのはセッションの無駄です。

代替が証明されるまで、元のプロファイルと動作する設定を保管してください。クライアントの変更を戻すのは速いですが、誰かが勘で解体したブリッジ網を組み直すのは速くありません。