Mac の VPN で utun は有効なのに通信が通らない？ ifconfig を確認

ifconfig は utun の名前、アドレス、MTU を表示しますが、どのアプリが所有しているか、パケットがどこへ向かうかは分かりません。本当の疑問に答える 5 つの読み取り専用チェックを紹介します。

VPN に接続してifconfigを実行すると、アドレスが付いたutun4の項目が見つかる。それでも必要なサイトはタイムアウトする。この隔たりは普通で、一覧が証明するのは仮想インターフェースの存在だけであり、あなたのクライアントがそれを持っていることや、目的のルートがそれを選ぶことや、パケットがそこを通ることではない。何もインストールしていないノート PC にすでに三つの utun 項目があったのに、間違ったトンネルを責めて午後を潰してから、私はインターフェース名を信じるのをやめた。

utun の行に実際に何が書かれているか

全体像を知りたいときはifconfig -aを実行する。引数なしで呼ぶと、ifconfigは現在 up しているインターフェースだけを表示するので、起動に失敗したトンネルはチケットに貼られる出力から抜け落ちることがある。ifconfig -lは名前だけを返し、接続後に新しい utun が現れたかを知る最短の方法になる。

役に立つ情報は、単一のインターフェースを読むところにあり、接続済みのトンネルは通常こう見える。

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

三つのフィールドが答えを握る。UPとRUNNINGは、カーネルがそのインターフェースを使う意思があることを示す。POINTOPOINTに加えて-->のピアアドレスが、物理リンクではなくトンネルであることの署名になる。mtuの値は「つながるのに止まる」という報告のひと山を説明してくれる、なぜなら utun インターフェースは通常、縮小された MTU（macOS の多くのビルドでは 1380）で立ち上がり、クライアントがそれを上書きすることがあるからだ。フィールド一覧は短いので、Apple が同梱する ifconfig のマニュアルを一度ざっと読めば十分だ。

インターフェースの裏にいるプロセスを見つける

ifconfigには、所有するアプリという概念がない。二つの VPN クライアント、あるシステムサービス、先週の残り物のトンネルが、このレベルでは同じに見える項目を作る。私の Mac でも、utun0からutun3までは何も設定する前に存在しており、Continuity や iCloud Private Relay もトンネルを使うし、どれもあなたが調べている接続ではない。

システムに構成を登録するトンネルなら、scutil --nc listが最短の照合になり、各構成を状態とサービス ID とともに表示し、接続中のものにはその印が付く。

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

独自のトンネルプロセスを動かし、構成を登録しないクライアントはそこに一切現れない。Tunnelblick やコマンドラインのopenvpnのインスタンスはそのグループに入るので、プロセステーブルも確認する：ps -Ao pid,comm | grep -i openvpn。プロセスがトンネルを所有したら、utun 番号はそのプロセスにだけ属する。

ルートを試す前にアドレスを試す

インターフェースは、使えるアドレスがないまま up していることがある。IPv6 のみのプロファイルではリンクローカルのfe80::の項目だけが表示され、inetの行は空になり、押し出されたアドレスの適用に失敗したクライアントもまったく同じ形を残す。宛先が IPv4 でトンネルに IPv4 アドレスがなければ、ルーティングの疑問はすでに決着している。

MTU は別に確認する価値がある。この失敗はサイズの問題には見えず、認証は通るのに大きな転送が始まった途端に沈黙する接続に見えるため、分割を禁じたプローブを、パケットがインターフェースの MTU に一致するサイズで送る（MTU が 1400 ならペイロードは 1372 バイト）。

ping -D -s 1372 10.8.0.5

応答が返れば、そのサイズのパケットはトンネルを通っている。小さな ping は通るのに沈黙するなら、疑うべきは MTU か、経路上で ICMP を落としている何かであり、認証ではない（認証はインターフェースができる前に完了している）。

宛先がトンネルを選ぶことを証明する

大事な問いはutun4が存在するかどうかではなく、特定のアドレスへの通信がそこから出ていくかどうかだ。route -n getは一つの宛先についてそれに答え、使うゲートウェイとインターフェースを表示する：

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

同じコマンドがen0と報告するなら、スプリットトンネリングの構成は言われたとおりに動いており、インターフェースをいくら調べても変わらない。netstat -rn -f inetは、デフォルトルートとテーブル全体を一度に見たいときに使う。

パケットが実際に動いているかはカウンターが決める。netstat -ibはインターフェースごとのパケット数とバイト数を、utun の項目も含めて報告し、数値は累積なので、間をあけて二度読み比べる：

netstat -ib | grep utun4

アプリが再試行を続けるのにカウンターが止まっているなら、カーネルはパケットを一度もインターフェースに渡していない。アプリが失敗し続けるのにカウンターが両方向に増えているなら、調査はトンネルの先へ移る。

utun がまったく現れないとき

成功したように見えたログインの後にインターフェース一覧が空なら、普通はトンネルが起動していないのであって、ifconfigが隠しているのではない。クライアント自身の状態を確認し、次にシステムの状態を見る。承認されなかった Network Extension、あるいは更新後に macOS が無効にしたものはインターフェースを残さないし、承認はシステム設定の「ログイン項目と拡張機能」にあり、そこに古い項目があれば、何かを再インストールする前に一度切り替え直す価値がある。

utun の番号は再接続のたびに一定ではない。十分前までutun5があった場所にutun4が来ることがある（古いインターフェースが解体され、カーネルが次の空き番号を渡すためだ）。名前を固定で書いたスクリプトはその瞬間に静かに壊れる；代わりにアドレスかルートで照合しよう。

読み取り側は読み取り専用のままにしておく。sudo ifconfig utun4 downはトンネルを中断させ、全トンネル型のプロファイルでは、証拠を集めているだけなのにリモートセッションも道連れにするという割に合わない取引になる。ここで必要なことに root は要らず、フラグ、アドレス、カウンターの読み取りはすべて通常ユーザーで動く。

次に Mac のトンネルがおかしくなったら、順番にチェックする。ifconfig -lで utun が現れたことを確かめ、フラグ、アドレス、MTU を読み、プロセスに結びつけ、route -n getに宛先が使うインターフェースを尋ね、そしてnetstat -ibが動くのを見る（各段階は別の層を排除し、最初に誤りが出たところが修正すべき場所だ）。

関連記事