route-gateway は redirect-gateway ではない：実際に変わるもの

このオプションは OpenVPN がインストールするルートに次のホップを与えるだけです。削除してもプッシュされたフルトンネルは切れず、修正はリダイレクト側にあります。

トンネルは上がり、プライベートサブネットは応答し、プロファイルからゲートウェイ行を誰かが消したのに通常の閲覧は今も VPN の中へ消えていきます。その組み合わせが、間違ったディレクティブを編集した証拠です。削除されたものはクライアントがインストールするルートに次のホップを与えていましたが、トラフィックを捕まえ続けたものは別の場所から来てサーバーがプッシュしたものでした。カバレッジと次のホップは別の仕事であり、どちらか一方だけが公開宛先をトンネルに通すかどうかを決めます。

削除した行はポリシースイッチではなく次のホップでした

クライアントがインストールするルートはすべて、向き先となるゲートウェイアドレスを必要とし、ルート自身が指定しない場合、そのアドレスの出どころがゲートウェイディレクティブです。それを削除すると、そうしたルートはぶら下がる先を失い、インストールに失敗するか、どこにも通じない経路に落ちます。プライベートサブネットはまさにそうしたルートが運んでいたものでした。

一方、生き残った挙動には、フラグに従って通常の外向きトラフィックをトンネルへ移す プッシュされたブロック内のリダイレクトオプション という別の作者がいます。ゲートウェイを削除しても、それを無効にも弱めもしません。結果は両方の状態の最悪で、公開トラフィックは今も捕まえられ、トンネルを正当化したプライベート宛先は到達不能になります。だから同じ考えで行われた二つ目の編集も何も変えません。

四つのレバー、四つの異なる仕事

この議論では四つのディレクティブが同じように引用されますが、そのうちカバレッジを支配するのは一つだけであり、つまり、どの宛先がそもそもトンネルを通るかです。二つ目はルートが使う次のホップを設定し、三つ目は単一のプレフィックスをインストールし、四つ目はサーバーがプッシュしたすべてを捨て、デプロイに必要なプライベートルートも含めます。表が名前ではなく管理者が変えたいもの順に並べているのは、混同を招くのが名前だからです。四つの別々の決定として扱い、本当に戻したいものを選んでください。

実際には四つとも一つのプッシュされたブロックに次々と並ぶことが多く、一つの設定の一部に見えてしまいます。そうではなく、OpenVPN のリファレンスが別個の仕組みとして記述しているのはまさにそのためです。どの決定を戻しているのかを見極めるのが仕事で、編集は一行です。

What you are trying to changeDirective that decides itWhat it leaves alone
Which destinations use the tunnelredirect-gatewayPer-prefix routes and resolver choice
The next hop a pushed route points atroute-gatewayCoverage of public destinations
One reachable prefixrouteEvery other destination, default path included
All pushed routing and DNS at onceroute-nopullNothing, which is the problem

プッシュされた行をフィルターし、次のホップは残す

気に入らないカバレッジがプッシュされたオプションとして届くなら、狭い対応はそのオプションを名前で無視し、プッシュされたブロックの残りをそのままにすることです。フィルターとして書くと下の行のようになり、置き場所は影響を受けるクライアントのプロファイルで、サーバー設定ではありません。

pull-filter ignore "redirect-gateway"

狭さが要点です。フィルターはテキストの接頭辞を比べるため、短いパターンは次のホップのディレクティブにも一致し、プライベートルートが依存する情報をまさに削ぎ落として、元の誤りを新しい装いで繰り返します。フィルターはプッシュされたオプションにしか働かないので、ローカルに書かれた、あるいはネットワークマネージャーが課した同等の行には決して触れません。生きたセッションはサーバーがプッシュした内容を再評価しないため、その後に再接続してください。

表ではなく検索を読む

プロファイルを再読み込みしたら、カーネルに、プライベートプレフィックスの内側と公開インターネットという二つの宛先が実際どこへ行くかを尋ねてください。メインテーブルの完全なダンプは、ルートが存在してもより具体的な一致に負けることがあるため、読みにくく、読み違えやすくなります。ポリシールーティングでは、ルール、テーブル、送信元アドレスも確認に含めます。

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

def1 バリアントは、古いデフォルトエントリを見えるままにしつつ半デフォルトの組が検索に勝つため、知っておく価値があります。したがって出力の 0.0.0.0/0 行だけでは何も証明できません。検索は、一覧が答えたように見えるだけの問いに答えます。

DNS、IPv6、プライベートルートはまだ動く必要があります

IPv4 のリダイレクトを一つ断ってもリゾルバーについては何も言えず、プッシュされた DNS オプションはルートが正しく見える間も問い合わせをトンネルへ送り続けられます。IPv6 のデフォルトも、IPv4 の確認が触れなかったアドレスファミリーに対して同じことをします。どちらも仮定ではなく明示的な決定が要ります。そのうえで、プライベートルートを失ったスプリットトンネルはスプリットトンネルではなく壊れたトンネルであるため、プライベートサービスがまだ応答するか確かめてください。

より広い道具には警告が必要です：route-nopull は プッシュされたすべてのルートと DNS オプションを捨てます、これは確実にフルトンネルを止め、同じく確実にデプロイが頼るプライベートルートを壊すため、一つのオプションを狙った名前フィルターよりはるかに大きなハンマーです。変更のたびにプライベート宛先、公開宛先、リゾルバーを確認し、完了したハンドシェイクはハンドシェイク以外の何の証拠でもないと扱ってください。

関連記事