ヒントとコツ: VPN プロキシ ID を使用する理由
Resolution
先週からのジレンマを思い出してください, 我々は、IPSec VPN トンネル上で重複したサブネットを持っていた場所?我々は、ピアネットワークの通信を取得する方法を探していた。レスキューへのプロキシ id。ピアをサポートするポリシーベースの VPN を使用しているパロアルトネットワークファイアウォールを使用している場合は、プロキシ id が必要です。
先週の今週の議論 (DotW)プロキシ id のヘルプですが、VPN プロキシ id についての詳細については、なぜそれを使用することが重要です。
IPSec vpn トンネルについて話しているときに、ポリシーベースの vpn をサポートするピアと連携するようにパロアルトネットワークファイアウォールを設定する場合は、プロキシ id を定義する必要があります。ポリシーベースの VPN をサポートするデバイスは、特定のセキュリティルール/ポリシーまたはアクセスリスト (送信元アドレス、宛先アドレス、およびポート) を使用して、IPSec トンネルを介して興味深いトラフィックを許可します。これらのルールは、クイックモード/IKE フェーズ2ネゴシエーション中に参照され、プロセスの最初または2番目のメッセージでプロキシ id として交換されます。
したがって、ポリシーベースの VPN ピアで動作するようにパロアルトネットワークファイアウォールを構成する場合は、フェーズ2ネゴシエーションを成功させるために、両方のピアの設定が同じになるようにプロキシ ID を定義する必要があります。プロキシ id が構成されていない場合、パロアルトネットワークファイアウォールはルートベースの VPN をサポートしているため、プロキシ id として使用されるデフォルト値はソース ip: 0.0.0.0/0、宛先 ip: 0.0.0.0/0 およびアプリケーション: any;これらの値がピアと交換されると、結果として VPN 接続のセットアップに失敗します。
次に、プロキシ ID ウィンドウとオプションを見てみましょう。
[プロキシ id] セクション (WebGUI の内部にある > [IPSec トンネル] > [トンネルを選択] > [プロキシ id] タブ) 内に、多くのオプションが表示されます。
- [プロキシ ID ]-[追加] をクリックし、プロキシを識別する名前を入力します。任意の名前を指定できます。番号のみを使用する場合は、受け付けられません。
- Local — IP アドレスまたはサブネットを ip_address/マスク形式で入力します (たとえば、10.1.2.1/24)。
- リモート —ピアによって必要な場合は、ip_address/マスクの形式で IP アドレスまたはサブネットを入力します (たとえば、10.1.1.1/24)。
- プロトコル-ローカルおよびリモートポートのプロトコルとポート番号を指定します。
- number —プロトコル番号を指定します (サードパーティ製デバイスとの相互運用性に使用されます)。
- Any — TCP または UDP トラフィックを許可します。
- tcp -ローカルおよびリモートの tcp ポート番号を指定します。
- udp -ローカルおよびリモートの udp ポート番号を指定します。
注: 各プロキシ ID は vpn トンネルとしてカウントされるため、ファイアウォールの IPSec vpn トンネル容量に対して数えられます。(例: サイト toiSite IPSec VPN トンネルの制限-pa-3020-1000、pa-2050-100、pa-200-25)
プロキシ id を使用する利点は、VPN トンネルのみを経由して移動する特定のトラフィックがある場合に、プロトコル番号または TCP/UDP ポート番号を使用して詳細に取得できることです。プロキシ id は、このような粒度を容易にします。
IKE には2つのバージョンがあるため、プロキシ id を使用した動作は異なります。
-IKEv1 と、パロアルトネットワークデバイスは、プロキシ ID の完全一致のみをサポートしています。ピアのプロキシ ID が一致しない場合、VPN が正常に動作している問題が発生します。
-IKEv2 を使用すると、サポートトラフィックセレクタが狭くなっているプロキシ ID の設定が2つの VPN ゲートウェイで異なる場合は、実装された選択肢のみが以下のユースケースで説明されます。
ユースケース IKEv2
多くの ipsec VPN セットアップを説明するのに役立つ ipsec および IKEv2 の使用例と、プロキシ ID を適切に使用する方法の一覧については、以下を参照してください。
例: vpn ゲートウェイが2つあります: a と B の IKE ネゴシエーションが開始されます。 i = イニシエータ、r = レスポンダ
VPN GW-定義されたトラフィックセレクタ TSi-a/TSr と仮定します。VPN の GW-b は、トラフィックセレクタ TSi-b/TSr-b の設定をしています。tsr-a は tsr-b と同じなので、無視することができます。tsi-a は tsi-b とは異なることができます。
A。tsi-a は tsi-b と同じで、例えば、いずれも 5.10.11.0/24 である。
期待される: その後、必要な縮小はありません, 動作は、既存の IKEv1 プロキシ ID の場合と同じです。. トラフィックは、この例では、NAT は、適切な通信を許可する必要があります渡すことができませんでした。
VPN の GW は-a: 送信: TSi: 5.10.11.0-5.10.11.255
VPN の GW-b の: 返信: TSi: 5.10.11.0-5.10.11.255 [最終結果]
このソリューションについては、DotW の記事で詳しく説明します。
プロキシ ID の
b. tsi-a のヘルプは、tsi-b のスーパーセットです:
b1. VPN の GW は-a が提案する TSi-a = 5.10.0.0/16;VPN の GW に-b の: TSi-b = 5.10.11.0/24。
しました。トンネルは、トラフィックなしで (たとえば、初期化中またはテストコマンドによって) もたらされます。
期待される: 応答者として、vpn の gw-b は 5.10.11.0/24 と vpn の gw-a に応答します。VPN の GW-a はそれを受け入れ、子 SA を作成する必要があります。
VPN の GW は-a: 送信: TSi: 5.10.0.0-5.10.255.255
VPN の GW-b の: 返信: TSi: 5.10.11.0-5.10.11.255 [共通のサブセットに絞ら]
ii です。VPN GW-a の背後にあるホスト (たとえば、ホスト IP 5.10.11.2) は、トンネルを持ち出すことを試みます。
期待される: 応答者として、vpn の gw-b は 5.10.11.0/24 と vpn の gw-a に応答します。VPN の GW-a はそれを受け入れ、子 SA を作成する必要があります。トラフィックが通過する必要があります。
VPN の GW は-a: 送信: TSi: 5.10.11.2;5.10.0.0-5.10.255.255
VPN の GW-b の: 返信: TSi: 5.10.11.0-5.10.11.255 [共通のサブセットに絞ら]
イニシエータである場合、IKE ペイロード内の最初の特定のトラフィックセレクタ (5.10.11.2) は送信されません。
応答側として、特定のトラフィックセレクタを送信するピアを処理できるようにする必要があります。また、トラフィックセレクタを共通サブセットに絞り込むこともできます。
iii。VPN GW-a の背後にあるホスト (たとえば、ホスト IP 5.10.6.2) は、トンネルを持ち出すことを試みます。
期待される: 応答者として、vpn の gw-b は 5.10.11.0/24 と vpn の gw-a に応答します。VPN の GW-a はそれを受け入れ、子 SA を作成する必要があります。
VPN の GW は-a: 送信: TSi: 5.10.6.2;5.10.0.0-5.10.255.255
VPN の GW-b の: 返信: TSi: 5.10.11.0-5.10.11.255 [共通のサブセットに絞ら]
イニシエータである場合、IKE ペイロード内の最初の特定のトラフィックセレクタ (5.10.6.2) は送信されません。
応答側として、トラフィックセレクタを共通サブセットに絞り込みます。受信した TS ペイロードに特定のトラフィックセレクタが含まれている場合は、ローカルポリシーから除外されますが、RFC 5996 あたりの特定のトラフィックセレクタは無視されます。
B2。VPN の GW は-a が提案する TSi-a = 5.10.0.0/16;VPN の GW-b に: 複数のエントリが定義されています: TSi-b = 5.10.11.0/24 + 5.10.12.0/24。
しました。トンネルは、トラフィックなしで育てられます。
strongswan では、トラフィックセレクタごとに複数のエントリをサポートしています。だから strongswan は、VPN の GW-b としてセットアップするために使用することができます。パノスが GW-b の場合は、複数のプロキシ id を設定する必要があります。
VPN の GW は-a: 送信: TSi: 5.10.0.0-5.10.255.255
VPN の GW は-b: 返信: TSi: 5.10.11.0-5.10.11.255 [パノス: 最初の一致するエントリから共通のサブセット]
上記は、応答側 (VPN の GW-b) としてパノスの結果を示しています。それは、エントリのいずれかで vpn の GW-a に返信: 5.10.11.0/24 または 5.10.12.0/24 ("show VPN トンネル" の順序に基づいて最初のエントリは、完全なトンネル名のアルファベット順)。
一部のベンダー (として、VPN の GW-b) の両方のエントリ (5.10.11.0-5.10.11.255 + 5.10.12.0-5.10.12.255) との TS を返すことがありますが、我々は最初のエントリをインストールします。
ii です。VPN GW-a (例えばホスト IP 5.10.11.2) の後ろのホストはトンネルを持ち出すことを試みる。
期待される: 応答者として、vpn の gw-b は 5.10.11.0/24 と vpn の gw-a に応答します。トラフィックが通過する必要があります。
VPN の GW は-a: 送信: TSi: 5.10.11.2;5.10.0.0-5.10.255.255
VPN の GW-b の: 返信: TSi: 5.10.11.0-5.10.11.255 [パン-OS: 最初の一致するエントリから共通のサブセットは、5.10.11.2 をカバーすることができるポリシーを好む]
イニシエータである場合、IKE ペイロード内の最初の特定のトラフィックセレクタ (5.10.11.2) は送信されません。
もし我々が応答者である場合、1つのエントリは、特定のトラフィックセレクタをカバーすることができます絞り込むことができるか、正確に一致するすべての設定されたプロキシ ID を検索します。特定のトラフィックセレクタを共通のサブセットでカバーできない場合は、依然として絞り込みを実行しようとします。
iii。ステップ ii の後、vpn の GW-a (例えば、ホスト IP 5.10.12.2) の背後にある別のホストは、vpn のもう一方の端に到達しようとします。
予想: トラフィックが以前に作成された VPN トンネルと一致しないため、別の IPSec SA がネゴシエートされます。
VPN の GW は-a: 送信: TSi: 5.10.12.2;5.10.0.0-5.10.255.255
VPN の GW-b の: 返信: TSi: 5.10.12.0-5.10.12.255 [パノス: 最初の一致するエントリから共通のサブセットは、5.10.12.2 をカバーすることができるポリシーを好む]
この時点で、両方のプロキシ ID の VPN トンネルは、トラフィックを通過しています。
ベンダによっては、別の IKE ネゴシエーションを開始できない場合があります。5.10.12.2 と一致しないものの、ステップ ii で確立された既存のトンネルを使用してパケットを送信します。我々は、この種の行動を分析するために全体のトンネル交渉プロセスをチェックする必要があります。
iv します。vpn GW の背後にあるホスト (たとえば、, ホスト IP 5.10.6.2) vpn のもう一方の端に到達しようとします (ステップ ii と iii なし).
期待される: vpn の gw-a に一致する SA がないので、それは vpn の gw-b とネゴシエートしようとします。応答は実装に依存する場合があります。
VPN の GW は-a: 送信: TSi: 5.10.6.2;5.10.0.0-5.10.255.255
VPN の GW は-b: 返信: TSi: 5.10.12.0-5.10.12.255 [パノス: 最初の一致するエントリから共通のサブセット]
v. ステップ iii の後で、vpn の GW-a の後ろのホスト (例えば、ホスト IP の 5.10.6.2) は vpn のもう一方の端に達することを試みる。
イニシエータは、以前に確立されたトンネルを使用して、トラフィックをピアに転送できます。どのトンネルをベンダ依存にすることができるかを選択する。
b3. トラフィックセレクタの絞り込みをサポートしていない VPN GW-b の場合
一部の VPN デバイスは、トラフィックセレクタの絞り込みをサポートしていません。Cisco IOS 15.0 返信 NO_PROPOSAL_CHOSEN この場合。
トンネルを確立できず、構成を変更する必要があります。
c. TSi-a は TSr b のサブセットです。
VPN の GW は-a が提案する TSi-a = 5.10.11.0/24;VPN の GW に-b の: TSr の-b = 5.10.0.0/16。
しました。トンネルは、トラフィックなしで育てられます。
期待される: VPN の GW-b の返信 5.10.11.0/24。トンネルは、トラフィックセレクタ (5.10.11.0/24) の共通部分を使用して確立されます。
VPN の GW は-a: 送信: TSi: 5.10.11.0-5.10.11.255
VPN の GW-b の: 返信: TSi: 5.10.11.0-5.10.11.255 [最終結果-共通のサブセット]
ii です。VPN GW-a (例えばホスト IP 5.10.11.2) の後ろのホストはトンネルを持ち出すことを試みる。
予想される: トラフィックセレクタ 5.10.11.0/24 とトンネルが確立されます。トラフィックを渡すことができる必要があります。
VPN の GW は-a: 送信: TSi: 5.10.11.2;5.10.11.0-5.10.11.255
VPN の GW-b の: 返信: TSi: 5.10.11.0-5.10.11.255 [最終結果]
イニシエータである場合、IKE ペイロード内の最初の特定のトラフィックセレクタ (5.10.11.2) は送信されません。
応答側として、特定のトラフィックセレクタを送信するピアを処理できるようにする必要があります。我々は、イニシエータからのトラフィックセレクタを選択しますが小さいです。
iii。VPN の GW-a の後ろのホスト (例えば、ホスト IP 5.10.6.2) はトンネルを持ち出すことを試みる
期待：
VPN の GW は-a: 送信: TSi: 5.10.6.2;5.10.11.0-5.10.11.255
VPN の GW-b の: 返信: TSi: 5.10.11.0-5.10.11.255 [最終結果]
PAN-OS がイニシエータの場合、同じトンネルインタフェースにプロキシ id または単一のプロキシ id が定義されていない場合、トンネルは上記のようにネゴシエートされ、トラフィックはトンネルを通して送信されます。
複数のプロキシ id の場合は、他のプロキシ id (トンネル id) が一致しているかどうかを確認します。一致するものがない場合は、最後のプロキシ ID を使用してトンネルをネゴシエートし、トラフィックを送信します。これは、IPsec の複数フェーズ2の関連付けで定義された動作です。
PAN-OS が応答側であり、ポリシー VPN を実行している別のベンダがイニシエータである場合、パケットがローカルポリシーの範囲外であるため、トンネルネゴシエーションを開始できないことがあります。トンネルネゴシエーションが開始された場合は、イニシエータのトラフィックセレクタを狭くして使用します。
d. TSi-a と TSr-b の間に重複があります。
VPN の GW は-a が提案する TSi-a = 5.10.0.0/16;VPN の GW-b の: TSr-b = 5.10.11.0/24 + 5.9.0.0/24。
しました。トンネルは、トラフィックなしで育てられます。
期待される: VPN の GW-b の返信 5.10.11.0/24。トンネルは、トラフィックセレクタ (5.10.11.0/24) の共通部分を使用して確立されます。
VPN の GW は-a: 送信: TSi: 5.10.0.0-5.10.255.255
VPN の GW-b の: 返信: TSi: 5.10.11.0-5.10.11.255 [最終結果-オーバーラップサブセット]
ii です。VPN GW-a (例えばホスト IP 5.10.11.2) の後ろのホストはトンネルを持ち出すことを試みる。
予想される: トラフィックセレクタ 5.10.11.0/24 とトンネルが確立されます。トラフィックを渡すことができる必要があります。
VPN の GW は-a: 送信: TSi: 5.10.11.2、5.10.0.0-5.10.255.255
VPN の GW-b の: 返信: TSi: 5.10.11.0-5.10.11.255 [共通のサブセット]
イニシエータである場合、IKE ペイロード内の最初の特定のトラフィックセレクタ (5.10.11.2) は送信されません。
応答側として、特定のトラフィックセレクタを送信するピアを処理できるようにする必要があります。また、トラフィックセレクタを共通サブセットに絞り込むこともできます。
iii。vpn の gw-a の背後にあるホスト (例えば、ホスト IP 5.10.12.2-vpn の gw のためのポリシー内で-しかし、vpn の gw-b のためのポリシーの外) トンネルを持ち出すしようとします。
期待：
vpn の gw は-a: 送信: tsi: 5.10.12.2、5.10.0.0-5.10.255.255 の
vpn gw は-b の: 返信: tsi: 5.10.11.0-5.10.11.255 [共通のサブセット]
パノスがイニシエータの場合: レスポンダは5.10.12.2 に役立つ範囲を見つけることができないので、共通の範囲 (5.10.11.0/24) を返します。トンネルを設けることができます。我々は、特定のトラフィックセレクタを送信しないでください。
IPsec の複数フェーズ2の関連付けで定義されている既存の動作に基づいて、パケットはこのトンネルを通じて送信されますが、応答側によって削除される可能性があります。送信側の VPN トンネルはそれに気付かないかもしれません。
iv します。vpn の gw の背後にあるホスト-a (例えば、ホスト IP 5.9.0.2-vpn の gw-b のためのポリシー内の vpn の gw-a のためのポリシーの外) トンネルを持ち出すしようとします。
期待される:
vpn の gw-a: 送信: tsi: 5.9.0.2, 5.10.0.0-5.10.255.255 の
vpn gw は-b の: 返信: tsi: 5.10.11.0-5.10.11.255 [共通のサブセット]
イニシエータが PAN OS の場合、プロキシ id 0.0.0.0/0 (プロキシ id が定義されていない場合) または最後のプロキシ id (トンネルインタフェースで複数のプロキシ id が定義されている場合) が TSi で使用されます。
トラフィックは、応答側 (ポリシーベースの VPN) によって、それが狭くなった TS に違反してドロップすることができます。
イニシエータが厳密な vpn ポリシーチェックを実行している場合 (PAN OS ではありません)、vpn ポリシーに違反すると IKE ネゴシエーションがトリガーされないことがあります。
これは、ヒント & トリックを終了します。私はあなたがこの記事から何かを学んだ願っています。
いつものように、我々は以下のすべてのフィードバックと提案を歓迎します。
ご安心ください!
デリオ ・ ジョー