bypass-dhcp が OpenVPN のルート計画に実際に加えるもの

redirect-gateway def1 bypass-dhcp を持つプロファイルは、IPv4 のデフォルトルート上書きと、ごく狭い例外を一つ組み合わせています。人は最後の単語だけを読んでモバイル接続の万能薬を期待し、このフラグが一度も支えたことのない DHCP 論に午後を費やします。各部分は一つのことだけをし、例外はその評判よりずっと小さいものです。

モバイル回線だけで起きる失敗をアドレス割り当てのせいにする前に、フラグを分解してください。この文字列の二つの半分は互いに何の関係もありません。

二つのフラグ、二つの無関係な仕事

def1 では、クライアントは既存のデフォルトルートを置き換えるのではなく、IPv4 の半分デフォルトを二本追加します。0.0.0.0/1 がアドレス空間の下半分、128.0.0.0/1 が上半分を覆うため、合わせてすべての宛先に届きながら、それぞれは 0.0.0.0/0 より具体的なままです。元のデフォルトルートはその検索に勝たずにテーブルに残り、クライアントが明示的にルーティングするものに対して古いゲートウェイは到達可能なままです。同時に、重なり合うデフォルトが二本テーブルに残るので、ルートの出力はプロファイルが示すより奇妙に見えることがあります。

bypass-dhcp は別物で、デフォルトルートには一切触れません。OpenVPN 2.6 のマニュアルは、ローカルサブネット上にない DHCP サーバーへの直接ルートを追加し、リースのトラフィックをトンネルの外へ出すものと説明し、この動作は Windows クライアントで実装されており、他の環境では利用できない場合があると注記しています。

存在する理由は機械的です。半分デフォルトが外向きのトラフィックを捕まえた後、物理ネットワーク上のサーバー宛ての DHCP 更新は、何かがそのアドレスを実際のインターフェースに留めない限り、トンネルへルーティングされてしまいます。フラグはそれを留めます。

例外が実際に及ぶ範囲

接続に成功した後の例示用テーブルは形を示します。トンネル経由の半分デフォルトが二本、物理ゲートウェイ経由の DHCP サーバー向けホストルートが一本です。自分のアドレスではなく、形として読んでください。

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

その三行目が指す宛先は一つだけです。リゾルバの設定でも、ローカルネットワークへの一般的な許可でも、サーバー側の出口規則でもありません。セルラー回線の電話には、クライアントがこの方法で特定できる DHCP サーバーが存在しないことがあり、だからこそフラグはそこで何も変えません。

クライアントが実際に何をインストールしたか確認する

プロファイルに書かれたオプション、サーバーが提示したオプション、接続の所有者が実際に適用したルートを区別してください。未対応のフラグを拒否したクライアントは残りの設定を保持することがあり、トンネルは上がったまま例外だけが存在しません。ファイルの行が有効になったと決めつけず、クライアント自身のログと結果のルーティングテーブルを読んでください。この三つは同時に成り立ち得ますが、パケットが実際にどこへ行くかを変えるのは最後の一つだけです。

VPN エンドポイントへのルートも同時に使える状態にしてください。このエンドポイントの例外は DHCP の例外とは別の要件であり、これがなければトンネルは自分を維持する通信そのものを取り込んでしまいます。

アプリケーションの宛先については、失敗する文脈で実際の検索結果を調べてください。より具体的なローカルルート、ポリシールーティング、アプリ単位の除外はどれも答えを変えるので、半分デフォルトが二本あることはすべてのフローの一覧ではありません。

経路の残りはこのフラグの中にありません

サーバーには、クライアントのインターネット通信を転送する許可と、それを返せる出口の仕組みが依然として必要です。クライアント側のルートはサーバーで不足する転送や送信元変換を作り出しませんし、フラグが機能する戻り経路の代わりになることもありません。

名前解決と IPv6 はそれぞれ独自のポリシーを必要とします。IPv4 の上書きはリゾルバをトンネル側のサーバーに向けもせず、IPv6 のカバレッジを確立もしません。v4 だけをリダイレクトするクライアントは v6 の経路をそのまま残します。

プロファイルと宛先を固定したまま、承認された無害なリクエスト一件を正常な経路と失敗する経路で比較してください。違いが名前解決、トンネル確立、ルート選択、転送された通信のどこにあるかを記録し、その答えをプロファイルと一緒に保管してください。その記録こそが、次に来る人が届かない DHCP のせいにしないようにします。