一台のLinuxホストに二つのOpenVPNトンネル：経路の所有者は誰か

二つのプロファイルが接続され、そのうち一つがもう一つ宛ての通信を静かに運んでいます。Linuxホストは両方のOpenVPNクライアントを同時に難なく実行できます。できないのは、どのプロセスがどのプレフィックスを要求してよいかをあなたの代わりに決めることです。その判断は二本目のトンネルが上がる前に下す必要があり、リソースが応答をやめた後では遅すぎます。

二本目のリンクが果たすべき仕事から始める

一つのプロファイル経由で届くオフィスと別のプロファイル経由で届くラボでは、両方のトンネルが上がっていて、どちらもすべてを要求しない必要があります。二つ目のプロファイルから出る必要がある頑固なアプリが一つあるなら、二本目のデフォルト経路ではなくポリシールールが必要です。待機系リンクは同時に一本のトンネルだけ動けばよいので、予備はマシンと一緒に起動すべきではありません。

これは三つの異なる構成で、どれも同じように始まるために混同されます：二つ目のプロファイルと成功した接続です。まず意図する配置を書き出し、それに向けて設定します。意図を一文書くだけで、パケットキャプチャの一時間が節約できます。

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

最初のコマンドは実行中のインスタンスを一覧し、マネージャの外で手動起動されたものも含みます。二つ目は現在のデフォルト要求を出力しますが、これは後で説明を求められる状態です。

重複するプールはルーティングより先に壊れる

二つのサーバーは同じ10.8.0.0/24から喜んでアドレスを割り当てます。するとクライアントは一つのプレフィックスの中に二つのインターフェースを持ち、どの宛先がどちらに属するかを示すものが何もなくなり、その結果の挙動はルーティング障害に見えますが実は番号付けの障害です。プールの再番号付けは設定一回の編集で済みますが、その後のルーティングの回避策は週末一つ分かかります。経路を追加する前にプールを確認してください。

ローカルLANも見てください。一つのトンネルが公開する192.168.1.0/24の家庭内LANも同じ曖昧さを生み、症状はホスト名は解決するのに接続が完了しないというものです。経路を出力するまで、それは名前解決の障害に見えます。

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

クライアントに触る前に、両方の出力を二つのサーバー設定と比較してください。プレフィックスが重なっているなら、何度再起動しても分離できないため、止めて再番号付けしてください。

各プロファイルに独自のユニットを、各プレフィックスに所有者を与える

各プロファイルは独自のインスタンス名と独自の設定ファイルを持つので、officeというインスタンスはoffice.confを、labというインスタンスはlab.confを読み込みます。drop-inはどのファイルが読み込まれるかを変えられるため、ディレクトリ一覧を信じるのではなく、サービスマネージャ経由でその対応を確認してください。対応を間違えると、動いていないプロファイルを調整することになります。

次に、経路を誰がインストールするかを決めます。サーバーが互換性のないセットをプッシュする場合、プッシュを拒否してプレフィックスを自分で列挙するか、一つのプロファイルにデフォルトを保持させてもう片方をポリシールールで誘導します。両方がデフォルトをインストールする二つのプロセスは、静かな勝者と決定の記録がない状態で終わります。

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

一つ目は引数を変えるあらゆる上書きを含めてユニットを表示します。二つ目はプロファイルがプッシュ経路をそもそも受け入れるかを示し、これが以降すべてを決めるスイッチです。

マークは応答をそれが届いたインターフェースに留める

各トンネルが異なる送信元を扱う場合、応答が間違ったリンクから出て、最初のパケットの後に接続が死ぬことがあります。持ちこたえるパターンは、到着パケットを入力インターフェースでマークし、そのマークを応答で復元し、各マークに独自のデフォルトゲートウェイを持つテーブルを与えることです。

影響を受けるインターフェースでは、応答がメインテーブルなら決して選ばないリンクから正当に到着するため、通常、緩い逆経路フィルタリングを緩める必要があります。マークは狭く保ち、捕まえるとトンネルが自分自身を通ってしまうトンネル自身の暗号化トラフィックを決して捕まえないようにしてください。

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

別のルールを追加する前に既存のルールを読んでください。重複した優先度と忘れられたテーブルが、マークポリシーがまったく効いていないように見える通常の理由です。

一本のリンクを止めて分離を証明する

両方のトンネルが上がった状態で、各インターフェースのアドレス、各トンネルの先にある一つのホストへの経路、無関係な宛先がたどる経路を記録します。一つのテーブルは最終判断を決して示さないため、一つのテーブルを読むのではなくカーネルに検索を尋ねてください。

次に一つのインスタンスを停止し、もう片方が動き続ける間にそのインターフェースと経路が消えるのを見ます。生き残った側に破断があれば、二つはまだ誰も分離していないデバイス名、経路、ファイアウォールルールを共有しています。

停止したプロファイルを戻し、同じ確認を繰り返します。再起動後の最初の起動だけトンネルが生き残るなら、ルーティング設計ではなくライフサイクルの欠陥を見ています。