OpenVPN クライアントがゲートウェイの IPsec セレクタに届かない理由

ゲートウェイからリモート IPsec トンネルの向こうのホストに ping を送ると、きれいに応答するので、トンネルは正常に見え、チケットは先へ進みます。次に接続済みのクライアントが同じホストを試すと、何も返ってきません。その ping は、ゲートウェイ自身の送信元アドレスで出発し別の IPsec セレクタに一致していたため、クライアントのフローの証拠にはなりませんでした。二つのケースがなぜ食い違うのかを理解することが、修正の大部分です。

ゲートウェイの ping はクライアントが決して使わないフローを試している

適用されるポリシーを決めるのは送信元アドレスです。ゲートウェイ上で生成されたパケットは、ローカル LAN かトンネルの端点のアドレスで出発し、それに一致するポリシーはまさにそのケース向けに書かれています。クライアントのパケットはクライアントプールのアドレスを載せて OpenVPN インターフェースに到着しますが、これはまったく別のセレクタです。

だから障害はルーティングの問題に見えますが、実際にはポリシーの適用範囲の問題です。ゲートウェイからの到達性は、ピアが生きていて提案が交渉されたことを証明しますが、プールが保護されているかどうかは何も証明しません。

アプリケーションが本当に必要とするリモートプレフィックスをプッシュする

接続クライアント用の 10.8.0.0/24 と、保護されたリモートネットワーク用の 172.30.239.0/25 という例の組を取ります。クライアントが必要とするのは二つ目のプレフィックスへのルートであり、ゲートウェイの LAN でも別のトンネルアドレスでもありません。プールにプッシュされたルートがあって初めて、クライアントはそのトラフィックをゲートウェイに渡します。それがなければ、パケットはデバッグ中のポリシー判断に決して到達しません。

プッシュされたルートを受け入れる Community サーバーでは、ディレクティブは実際のマスクを取ります：push "route 172.30.239.0 255.255.255.128"。Access Server は同じ宛先を、インストールされたバージョンのプライベートネットワークまたはアクセスルール設定で構成し、ルーテッドかトランスレーテッドのモードを意図的に選びます。所有する設定ではなく生成されたファイアウォールチェーンを編集することが、動作する構成を再現不可能にする道です。

接続後はサーバーの意図ではなく、クライアントのルーティングテーブルを読みます。プールだけを覆うルートは、プッシュが届かなかったことを意味し、トンネル経由のデフォルトルートはこの要件より広く、後で驚かされます。マスクとプレフィックスの両方を確認し、/25 を /24 としてプッシュすると隣接アドレス向けのトラフィックが運べない経路に入ることに注意してください。そのうえで、クライアントがその宛先にトンネルインターフェースを選んだことを確認します。

セレクタにクライアントプールを含める

クライアントのアドレスを保つルーテッドアクセスでは、IPsec ポリシーがプールとリモートプレフィックスの間のトラフィックを保護する必要があります。ゲートウェイ自身の LAN 向けに書かれたセレクタは ping を通してクライアントの要求を落としますが、これがこの調査を始めた非対称性そのものです。

構成された提案だけでなく交渉されたポリシーも、たとえば strongSwan の ipsec statusall や実装に応じた同等の状態コマンドで確認します。ポリシーベースの IPsec では、通常のルートが物理インターフェースを指していても一致するトラフィックは暗号化されるため、トンネルデバイスの不在は何も証明しません。セレクタの組を、書き留めたプールとプレフィックスと比較してください。

ゲートウェイの汎用ソース NAT も一致を壊します。ポリシー検査の前に masquerade ルールがクライアントの送信元を書き換えると、パケットは書いたセレクタのようには見えなくなります。広い masquerade ルールが二つ目の VPN のまずい修正である理由の一つで、適用されるポリシーとリモート側が記録するアドレスが変わってしまいます。ルーティングしたいトラフィックを除外するか、意図的に変換してセレクタを更新してください。

ルーティングか変換かを意図して選ぶ

ルーティングはクライアントのアドレスをリモート側に見えるままにするので、リモートのログや送信元ごとのルールが意味を持ち続け、リモートゲートウェイがプールへの戻り経路を知っている必要があります。変換はプールを一つのアドレスの背後に隠し、戻り経路の問題を取り除く代わりに、クライアントごとの識別を破壊します。

二つの設計は別のセレクタと別のファイアウォール順序を必要とするため、一つの設計を選んで書き留めてください。中途半端に適用された masquerade はその間に落ちて、どちらも満たしません。書き留めた選択は、次の技術者がバグと意図的な決定を区別できるようにもします。

転送と応答でループを閉じる

ゲートウェイは意図したプロトコルと宛先を転送する必要があり、それは IP 転送が有効でその組を許可する転送チェーンがあることを意味します。次にリモート側が IPsec 経路で応答を返す必要があり、それはこちらのゲートウェイではなく相手のゲートウェイでのルーティング判断です。どちらの半分も普通の設定で、どちらも中途半端に残しやすいものです。別々に試して、転送ルールの欠落を壊れたトンネルと取り違えないようにします。

クライアントからアプリケーションへの実際の要求一つで検証し、OpenVPN インターフェース、IPsec の判断、リモートホストを通る様子を観察します。到着する要求と決して戻らない応答はクライアントの席からは同じに見えるため、応答は別の観測として調べます。追跡した要求一つは、どれだけのゲートウェイ ping よりも価値があります。

テスト中は宛先の承認を狭く保ち、ルールのないクライアントがサービスに到達できないことを確認します。インストールされたルートと確立されたアソシエーションは、付与されたアクセスとは同じではありません。