Mac の VPN 設定はサーバーを起動しない：ゲートウェイの居場所

macOS では VPN という名前で二つの別の仕事を指し、設定パネルが扱うのはそのうち一つだけです。この Mac の通信をプロバイダーや遠隔ゲートウェイ経由で外に出したいなら、クライアント項目だけで足ります。ホテルの部屋から自宅ネットワークのプリンター、NAS、管理画面に届きたいなら、そのネットワーク上の何かが外からの接続を受け入れる必要があり、現在の Mac は既定ではその何かではありません。三つの問いでどちらの場合かが決まり、欄にアドレスを打ち込む前に答えておく価値があります。

クライアント項目が示すのは宛先であり、リスナーではない

macOS Ventura 以降のシステム設定 > ネットワーク > VPN では、以前のリリースがネットワーク環境設定に置いていた欄が、他人のエンドポイントへの到達方法を記述します：サーバーアドレス、リモート ID、アカウントまたは証明書、任意のオンデマンド接続ルールです。その項目を保存すると、Mac のネットワーク構成に接続が記録されます。この手順のどこにも、ポートを束縛し、リスナーを開き、遠隔ユーザーを登録する処理はありません。

シェルから確認できます。サーバーではないかと疑う Mac で sudo lsof -nP -iUDP を実行し、プロトコルが使うポートを探します：IKEv2 なら 500 と 4500、OpenVPN の既定なら 1194、WireGuard なら 51820 です。クライアント専用のマシンには、遠隔アドレスとポートに結び付いたソケットが見え、インターネット上の何かが到達できるワイルドカード束縛はありません。Network Extension の中で動くトンネルは lsof から隠れることがあるので、いずれにせよアプリの状態パネルも確認し、この Mac をゲートウェイに変える Apple の設定項目は見つからないはずです。

三つの問いが二つの役割を分ける

順番に片付けてください。一つ目が普通は残りを決め、三つ目が Mac 固有の計画で最も躓くところです。

1. 会話を始めるのはどちらか。 Mac が外向きに接続し、相手が応答するならクライアントが必要です。インターネット上の機器があなたのネットワークに届くために内向きに接続するなら、公開された入口を持つゲートウェイが必要で、Mac はそのゲートウェイのクライアントのままでかまいません。

2. トンネルが上がっている間、何に届く必要があるか。 一つのホスト上の一つのサービスならポート転送の判断です。名前解決を含むサブネット全体ならルーティングと DNS の判断であり、変わるのはゲートウェイが転送すべき対象であって、クライアント項目の記述ではありません。

3. 受け入れる側はどの OS リリースで動いているか。 Mac についてはこの問いに厳しい答えがあり、Apple は VPN を macOS Server 5.7.1 から削除されたものとして挙げ、macOS Server アプリ自体は 2022 年の四月 21 日に終了しました。その サービス履歴の告知 が、もう存在しない VPN サービスのチェックボックスを古いチュートリアルが案内してきたときに読むべきページです。

最初の答えが「外の誰かが開始する」なら、Mac のクライアントパネルでスイッチを探すのをやめ、トンネルを終端するホストを選びに行ってください。

代わりにゲートウェイを置ける場所

四つの構成で、家庭と小規模オフィスのほとんどの事例を覆えます。ラベルだけ違うクライアントモードではなく本物のサーバーモードを持つルーターは、端でトンネルを終端し、ホスト数を低く保ちますが、そのファームウェアのプロトコル対応に縛られます。NAS や常時稼働のミニ PC はベンダーのサーバーパッケージを動かし、読めるログを残します。小さなクラウド VM は自分で制御できる公開アドレスを与え、二本目のトンネルで自宅に届きます。WireGuard 上に組んだメッシュオーバーレイや、ピア間を中継するマネージドサービスは、両端から外向きに接続させることで内向きのポート転送を回避します。

それらの選択肢の境目は通常、ソフトウェアではなくインターネット接続です。ISP がキャリアグレード NAT の内側に置くなら、ルーターのポート転送をどれだけ足しても到達可能な入口は生まれず、中継やメッシュの構成が正直な答えです。ルーターが報告する WAN アドレスと外の世界が見るアドレスを比べ、両者が違い、ルーターの値がプライベートまたは共有の範囲にあるなら、中継の事例として計画してください。

どのホストを選んでも、範囲ではなく一つのポートで一つのプロトコルを転送し、動かしている macOS リリースについてその製品がサーバー役を明記していない限り、Mac を内向きの経路から外してください。

プロファイルを配る前に役割を確かめる

候補のゲートウェイで、インストーラーが作ったはずだと信じるのではなく、リスナーが存在することを証明してください。macOS なら上のポートに絞った sudo lsof -nP -iUDP、パケットフィルタ規則が設計の一部なら sudo pfctl -s nat も使います。Linux では ss -lunp が同じ事実を曖昧さなく示します。

次にネットワークの外から、プロトコルそのもので試します。Ping が証明するものはわずかで、ICMP はよく遮断され、UDP 51820 については何も語りません。詳細ログ付きのクライアントハンドシェイクを携帯回線の電話から実行するのが最も安い本物の試験で、遠隔の同僚が通るのと同じ経路を通ります。

そこまでして初めてクライアントプロファイルに触れます。Mac では scutil --nc list がシステムの知る VPN サービスを出力し、いま作ったゲートウェイがそこになければ、試験したのとは別のマシンを設定しています。ハンドシェイクが LAN では成功し外から失敗するなら、原因は内向きの経路にあります：NAT 規則、プロバイダーの CGNAT、ゲートウェイのファイアウォールの順です。

何かを作る前に、四つの点を決めてください：

• 接続を始めるのはどちらか、あなたの Mac か遠隔の機器か。
• 受け入れるホストの OS リリースと製品が、本当にサーバー役を支えるか。
• ISP が到達可能な公開アドレスをそもそも与えるか。
• ゲートウェイが受け入れる単一のポートとプロトコルは何か、その背後で応答するサービスは何か。

次の一歩は具体的です：ゲートウェイのホストを選び、外からリスナーを確かめ、それからようやく そこを指すクライアント項目を Mac に作ります。