route-nopull だけではファイルサーバーに届かない理由
プッシュされたルートを無視するだけでは、スプリットトンネルの半分にすぎません。ルートの所有者を決め、オフィスのプレフィックスを手動で追加し、3つの経路を試してから解決済みと呼んでください。
ファイルサーバーは問題なく開きますが、隣のウィンドウのビデオ通話が途切れ始めます。遅いものはなく、MTU も間違っていません：クライアントがサーバーから渡されたルート一覧を受け入れたため、すべてのパケットがオフィスのファイアウォールから出ていくようになったのです。修正は別のチューニングフラグではなく、クライアントのルートテーブルを誰が所有するかという決定です。その決定は一か所に属し、以下の失敗の形が、実際にどちらを選んだのかを教えてくれます。
ルートテーブルの所有者を決める
所有者は三通りあります。サーバーがルートとデフォルトゲートウェイをプッシュすれば、クライアントは言われたとおりにインストールし、フルトンネルになります。クライアントプロファイルがプッシュを捨てて独自のルート行を持てば、所有権を引き取れます。デスクトップの接続マネージャーも、独自のルートとデフォルトルートのプロパティを通じて決定を所有できます。
どの選択も違う形で失敗するからこそ、プロファイルを編集する前にテーブルを読む価値があります。症状に一致する行が、実際に持っている所有者です。
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
一つを選んで書き留めてください。二つを混ぜると、デフォルト経路が自分のドキュメントと矛盾するホストが残り、次のエンジニアにはどの層が勝ったのか分かりません。負けた方を明示的に削除してください。
route-nopull はプッシュを絞り込むだけで、ルートを追加しない
route-nopull はクライアントプロファイルに置くもので、そのファイル内の順序は関係ありません：サーバーから来る値だけを捨てるからです。プッシュされたルート（プッシュされたデフォルトルートを含む）を捨てますが、トンネル自体は通常どおり上がります。
見落とされがちな結果は、プッシュされた DHCP オプションも一緒に消えることです。サーバーが送る DNS 設定も捨てられるため、トンネルが健全でサーバーにアドレスで到達できても、内部名の解決が止まります。
その結果、自分で追加しない限りオフィスのプレフィックスへの経路がないトンネルが残ります：同じプロファイルで route-nopull の後に route 10.30.0.0 255.255.0.0 を置きます。この行はアドレスとマスクを運ぶもので、次のホップは指定しません。
別の形式ではゲートウェイトークンを追加します：route 10.30.0.0 255.255.0.0 vpn_gateway はエントリを名前でトンネルに向けます。インポーターがこの変種を変換するかはまちまちなので、カーネルテーブルにエントリがない場合は保存された接続を調べてください。
ping ではなくルート検索で確認する
ping は何かが応答したことを教えます。ルート検索はカーネルがどのインターフェースを選ぶかを教え、それが本当に尋ねたかった問いです。四つの短いコマンドで、欠けているルートと間違ったデバイスを指すルートを区別できます。
ip route show dev tun0 でトンネルが何をインストールしたかを読みます。出力がまったくないのはルートがゼロということで、機能するスプリットトンネルではなく、明示的な行なしでフィルターを追加したときのよくある結果です。
次に ip route get 10.30.5.7 でオフィスのアドレスを一つ、ip route get 1.1.1.1 で通常のインターネットアドレスを一つ確認します：二つ目は物理インターフェースを指すはずです。トンネルを指すなら、プッシュはまったく絞り込まれていません。
最後に ip rule を読みます：以前の試行が残したポリシールールが、たった今直したテーブルを上書きすることがあるからです。上に古いルールが乗った正しいプロファイルは、壊れたプロファイルとまったく同じに見えます。次を追加する前に、前回追加したルールを削除してください。
重複するサブネットは壊れたトンネルのように見える
クライアントから見れば二つのプライベート範囲が同一であることがあり、スプリットトンネルが原因でもないのに責められるのはそこです。オフィスが自宅ルーターと同じプレフィックスを配ると、トンネルのルートがルーターを覆い、家庭内ネットワークが消えたように見えます。
何かを変える前に、単純なアドレス一覧を使って自分のインターフェースのアドレスとプロファイルがインストールするルートを比べてください。重複は現実であり、どのプロファイルオプションでも解決できません。直せるのは名前の付け方で、次の人が一つではなく二つの範囲を見られるようにします。
正直な修正は、片側を採番し直すか、オフィスでアドレスを変換することです。単一のホストルートをルーターに固定するのはルーターのアドレスが変わるまで機能し、その後は最初の謎の上に二つ目の謎が乗ります。
決定を再接続後も残す
手で入力したエントリは再接続で消え、接続マネージャーはプロファイルが起動するたびにテーブルを作り直します。決定は接続が作られる場所、つまりプロファイルかマネージャーの保存設定に置いてください。そのうえで、通話中に挙動を知るのではなく、一度わざと接続を再起動します。次の再接続までしか機能しないプロファイルは未完成です。
三つの経路を同時に試します：リテラルアドレスによるオフィスのホスト、名前による同じホスト、そして通常の公開サイトです。真ん中は、プッシュされた DNS オプションを捨てた後に設定した名前サービスに依存し、静かに失敗するのはそれです。