route -interface がリンク外のホストに届かない理由

route は Wi-Fi インターフェース名を受け付け、不平もなく終了し、ホストは到達不能のままです。壊れているものは何もなく、ルート内の関係が単に誤っているのであり、インターフェースフラグが示すのは宛先がどのリンク上にあるかであって、別の場所にある宛先へのトラフィックをどのルーターが受け取るかではありません。コマンドが成功するのは構文的に正しいからであり、機能する経路を記述しているからではありません。

この区別が、VPN の隣のルート例外が機能するか、もっともらしく見えるだけかを決めます。

インターフェースは出口、ネクストホップは引き渡し

アドレス 192.168.50.20 の Mac と 192.168.50.1 のルーターがある場合、同じリンク上の別のマシンには直接到達できます。フレームはそのマシン宛にされ、ケーブル上に置かれます。ルーターは関与せず、インターフェース限定のルートはまさにそれを表します。遠端を別の建物のホストに変えると、同じコマンドは意味をなしません。Mac にはケーブル上に置く第二層アドレスがないため、インターフェースフラグが記述できるものは何もありません。

リンクの外の宛先は異なります。Mac は第二層で到達できないホスト宛のフレームをケーブル上に置けず、到達できるルーターにパケットを渡します。したがってルートにはゲートウェイが必要で、そのゲートウェイ自体が接続されたリンク上で到達可能でなければなりません。

リンク外の宛先にインターフェースフラグを使うと、macOS はその宛先をケーブル上にあるかのように扱います。するとカーネルはその第二層アドレスを解決できず、パケットはエラーに有用な情報もなく破棄されます。

インターフェースフラグが実際に主張していること

Apple のルートリファレンスは、中間者なしで直接到達できる宛先に対するインターフェース形式を定義しています。これはリンクモデルについての記述であり、どのアダプターを使うかの好みではありません。Wi-Fi 経由でインターネットホストに到達するには、その Wi-Fi リンク上のルーターが依然として必要で、ルートはそれを名指ししなければなりません。

インターフェーススコープは別の属性です。どの送信元アドレスが適用されるかといったスコープの判断のためにルートを特定のインターフェースに関連付けますが、インターフェース自身が到達できない宛先への到達性を生み出すものではありません。二つの属性は別の問いに答えます。

だからこそ、コマンドは受け入れられ、テーブルに現れ、それでも失敗します。カーネルは意図を検証しているのではなく、あなたが主張した内容を記録しており、その主張は宛先がリンク上にあるというものでした。静かな成功の後の静かな破棄は想定された結果であり、バグではありません。ネットワークを責める前に、その主張を読み返してください。

リンク外の宛先に必要なルート

198.51.100.25 のようなドキュメント用アドレスへの承認済み経路を LAN ルーター経由で通す場合、意図された関係は宛先、192.168.50.1 のネクストホップ、そしてそのネクストホップに到達する LAN インターフェースです。インターフェースはルートコマンドで強制されるのではなく、ネクストホップの検索によって含意されます。

macOS では読み取り専用の確認は route -n get 198.51.100.25 です。ゲートウェイとインターフェースの行を一緒に読み、ゲートウェイが Mac から実際に到達できるアドレスか確認します。別のサブネットのゲートウェイや、最後のネットワーク変更以降に消えたゲートウェイは、正しく見えて何も転送しないルートを生みます。

永続的な手順に en0 をハードコードしないでください。インターフェース名はアダプター、ドック、VPN クライアントで変わり、誤った名前を指定したルートは、より広いネットワーク障害と誤読されやすい形で失敗します。

置き換える前に現在の選択を読む

何かを追加する前に、システムがすでに何を選び、なぜそうしたかを確認します。その出力は、トラフィックがトンネル経由か、LAN ルーター経由か、どこにも行っていないかを示し、変更後に比較するための基準を与えます。それがなければ、新しいルートが効いたかどうか分かりません。

次にアドレスファミリーを確認します。IPv4 用に追加したルートは IPv6 宛先には何の効果もなく、両方のファミリーに解決されるサービスは断続的に到達可能に見えることがあります。ルートテーブルとリゾルバーは別の問いに答え、両方が意図した経路と一致している必要があります。

最後に、ルートは選択であり許可ではないことを忘れないでください。管理された VPN プロファイルやクライアントフィルターは、テーブルが指していても直接経路を禁止できるため、テーブルへの成功した登録で調査が終わると思い込まず、実際のアプリケーションでテストしてください。

トンネルとポリシーが形を変える

ポイントツーポイントのインターフェースは別のケースです。トンネルは Ethernet 形式のゲートウェイアドレスなしでルートを運ぶことができ、それは自動的に誤りではありません。Wi-Fi の例を目にするすべてのテーブルエントリに広げるのではなく、インターフェースの実際のリンクモデルを適用してください。

変更依頼では、宛先、承認されたネットワーク経路、現在のゲートウェイとインターフェース、そして例外を維持すべき担当者を書き留めます。担当者が重要なのは、プロンプトで入力した一度きりのルートはポリシーではなく、次の再接続で消えるからです。

VPN が有効な間にこのホストへ到達することが要件なら、正直な答えは通常、ローカルルーター経由の特定ホストルートであり、インターフェースを所有するネットワークマネージャーが導入します。何にでも直接到達することが要件なら、その要件自体がルートコマンドより先にポリシーの見直しを必要とします。