フルトンネルが SSH セッションを殺した：戻り経路を固定する

SSH 経由で作業しているマシンで OpenVPN クライアントを起動すると、コマンドの途中でセッションが固まります。トンネルは接続済みと報告し、ホストはトンネル経由でインターネットに到達でき、キー入力は届き続けるのに何も戻ってきません。変わったのはトンネルではなく、あなた宛てのパケットの戻り経路が新しいデフォルトルートに一致し、リモートゲートウェイがあなたのデスクに届けるために使わないトンネルに入ってしまうことです。

redirect-gateway が実際にインストールするもの

その def1 形式では、redirect-gateway は 0.0.0.0/1 と 128.0.0.0/1 をデフォルトルートの上書きではなく追加します。この二つの半分はアドレス空間全体を覆い、どちらも 0.0.0.0/0 より長いプレフィックスのままなので、より具体的な一致を持たない宛先はすべてトンネルに入ります。以下の修正はすべてより具体的な一致をインストールすることで機能するため、この仕組みは覚えておく価値があります。

あなたの管理アドレスも、そうした宛先のひとつです。

VPN サーバーはクライアントの通信をインターネットへ転送します。あなたが接続してくる公開アドレスへのルートは持っておらず、そのパケットをクライアントから来た通信以外の何かとして扱う理由もないので、破棄します。一方で、あなたが送った要求はホストに届いているので、セッションは片側だけ生きているように見えるのです。

ip route show table main | head -n 20
ip route get 198.51.100.23

送信元アドレスとトンネル前の経路を突き止める

サーバー上で確立済みの SSH 接続を一覧して、それがどこから来たピアアドレスを記録します。戻りルートが覆うべきなのはそのアドレスであり、いつもあなたが思うものとは限らず、ジャンプホスト、NAT ゲートウェイ、通信事業者のトランスレータが別の送信元に置き換えることがあります。

次に、トンネルが始まる前に通信を運んでいた物理ゲートウェイとインターフェースを見つけます。def1 構成ではデフォルトルートが半デフォルトの下にまだ残っているので、情報は得られますが、長いルートテーブルを目で読むのは間違いを招きます。

両方の値とインターフェース名は、これから追加するルートに三つすべてが必要なのでまとめて記録します。ホストが上位リンクを選ぶのにポリシールーティングのルールを使っていた場合、単純なルートはまったく参照されないことがあり、その可能性が修正方法を変えます。

半デフォルトに優先するホストルートを固定する

ある /32 ルートはどちらの半デフォルトよりも長いので、あなたのアドレスへの応答はトンネルより優先してこれを選びます。ネクストホップはトンネル前のゲートウェイ、デバイスは物理インターフェースで、これによりパケットはトンネルが存在する前の経路にとどまります。

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

テーブルを眺めるのではなくルックアップで確認しますが、答えは eth0 とゲートウェイを示し、決して tun0 を示してはいけません。

OpenVPN も同じ理由で VPN サーバー自身のアドレスへのホストルート をすでに追加しているので、このパターンはおなじみで、管理アドレスは単にもう一つの例外にすぎません。これを直すのに route-nopull に手を伸ばさないでください、トンネルが必要とするプッシュされたルートを捨ててしまい、リモートネットワークや DNS のオプションも含まれるからです。

再接続しても生き残るようにする

手で追加したルートは、クライアントが再接続して自分のルートをインストールすると消えるので、修正が繰り返しの障害になってしまいます。ルートがインストールされた後に走るものへコマンドを結びつけてください。

たとえば route-up スクリプトでも、ネットワークマネージャーの pre-up フックでも機能し、信頼できる確認は再接続の後に同じルックアップをすることです。

Windows で同等なのは -p を付けて追加する永続ルートで、再起動を越えて残りますが、ネットワークが変わった後は正しいゲートウェイを指す必要があります。プラットフォームが何であれ、ルートの隣に、それがネットワーク設計の要請ではなく管理セッションを守るために存在することを次の管理者が知れるよう理由を書いてください。

固定したルートでも足りないとき

逆経路フィルタリングは、一方のインターフェースで入り他方から出るパケットを落とすことがあり、固定ルートはまさにそれを作ります。何かをグローバルに無効化する前に、有効な rp_filter の値を確認し、チェックを切るのではなく非対称を直すほうを選んでください。適用されるのはインターフェースごとの設定で、loose モードはパケットを落とす代わりに非対称を記録するだけのことがよくあります。フィルタのせいだと結論する前に、両方を読んでください。

ポリシールーティングを使うホストには、ルールベースがその中のルートの前にテーブルを選ぶため、ルートだけでなくルールも必要です。main テーブルのルートは、別のテーブルを指すルールに一致するフローには見えません。main に何かを追加する前にルールを読んでください。あるルールがすでに管理通信を覆っているなら、例外はそのルールのテーブルに入れるべきです。

テスト中は帯域外のコンソールを開いたままにし、使っているログインを切断する前に二つ目のログインから再確認してください。自分の管理通信をトンネルへ送るルートは、それを直している接続そのものを切ります。そうなると戻るにはシリアルコンソールかレスキューブートが必要で、確認の手順を一つ省くには割の悪い取引です。