CiscoのNAT。 パート2
同僚の皆さん、こんにちは。
CiscoのNATに関する一連の記事tkを続けます。 前の記事はすべて、いくつかの肯定的なレビューを見つけました。
この記事では、約束どおり、宛先NATの内部を見ていきます。 誰も気にしない-猫の下でウェルカム。
さらに読む前に- 免責事項 ：同僚、私はすべての人がCisco全般、特にCLI、特にtsiskarsと正確に関連しているわけではないことを理解しています。 しかし、ホリバーを繁殖させず、議論をより建設的なものにしましょう。具体的には、この記事と記載された技術について具体的に議論します。 ブログは主題であるため、記事はその主題に含まれます。 また、別の要望として、意見の正しさに反対しないようにしましょう。 :)すべて、余談でごめんなさい。
だから
実際、非常にエキゾチックな形式のNATは、TCPプロトコルで実行されるサーバー間の負荷分散のために特別に作成されました。 実生活では、日食よりも一般的ではありません:)
もっと深く行きましょう 。
1.したがって、このブロードキャストは、インターフェイスの外部からインターフェイスの内部への接続と応答トラフィックのために接続が開始された場合にのみ機能します（そのような言葉はごめんなさい）。 ただし、トラフィックが内部から開始された場合、ブロードキャストは行われません。
2.このようなNATは、TCPプロトコルでのみ機能します。
なんでそんな喜びが必要なの ？
10.0.0.1から10.0.0.10のアドレスを持つ12個のWebサーバーがあるとします。 同じサイトがすべてのサーバー（または、単にフロントエンドサーバーになります）で回転しており、簡単にするために1つのポート（80（HTTP））もあります。
外部からのクライアントは、11.1.1.1：80にある「スミア」サイトをタップしています。
そして、RR（ラウンドロビン）の原則、つまり そのため、外部からグローバルアドレスからルーターにアクセスする次の各クライアントは、このダース（円内）から次のサーバーにアクセスします。
このcなNATはここで役立ちます。
どのように機能しますか？
1. ライブブロードキャスト 。 内部ソースNATのロジックに基づいた論理的および習慣的な期待に反して、このタイプのライブブロードキャストは、外部から内部にアクセスするときに作成されます。 TCP（およびそれだけを繰り返します）トラフィックが外部インターフェイスに表示されると、トラフィックは最初に内部宛先NATに準拠しているかどうかチェックされます。 一致する場合、宛先アドレスはプール内の次のアドレスに変更され、ブロードキャストはブロードキャストのリストに入力されます。 その後、宛先アドレスがすでに変更されたパケットがルーティングされます。
___
UPD ：非TCPトラフィックはプールの最初のアドレスにルーティングされます。 コメントありがとうございます。
2. 逆ブロードキャスト 。 繰り返しますが、逆も同様です。 リバースブロードキャストは、内部から外部に向かっています。 そして、ここでは、内部から外部へのトラフィックをスローし、変換テーブルに対応するエントリがある場合、ルーティングが最初に動作します-パケットが中継されます。
備考
1.静的内部ソースNATおよび静的内部ソースPATとは異なり、ルーターはグローバルアドレスのARP要求に応答しません。もちろん、このアドレスがインターフェイスに割り当てられている場合を除きます。 したがって、インターフェイスにセカンダリとして追加する必要がある場合があります。
2.内部ソースNATの場合のように、内部インターフェイスがない場合でも、ルーターのトラフィックもブロードキャストされます。
3. p。2の結果：内部インターフェイスがない場合、ルーター自体のトラフィックのみがブロードキャストされます。
これがどのように構成されているかを見てみましょう。
1.したがって、最初にプールを作成します。 プール内のアドレスは、サーバーのアドレスです。
特にロータリーという言葉を強調しました-このタイプのNATの場合、プールは回転する必要があります（つまり、アドレスが次々に取得されることを示すだけです）
それ以外の場合、プールの最後に到達すると、次のパケットはドロップされます）。
2.ブロードキャストするトラフィックを割り当てるアクセスリストを作成します。 特別に拡張しました：
つまり グローバルアドレスと特定のポート（TCP！）に向けられたトラフィックを送信します。
3.ブロードキャストを作成しますが、少し残っています。
4.インターフェイスをマークします（サーバーが内部にある場所、外部が外部にある場所）
そして今、サーバーへの呼び出しの様子を観察できます。
グローバルアドレスの同じポート（つまり11.1.1.1:80）が異なるアドレスに変換されたことがわかります。
___
UPD ：当然、トラフィックはセッションごとにバランスが取れています。これは、TCPが正しく機能するために必要です。 コメントありがとうございます。
備考
1.グローバルアドレスの一部のポートを他のサーバーポート（たとえば、80番目から8080番目）にリダイレクトすることはできません。ポートは一致する必要があります。 本当に必要な場合は、ループバックをフックし、通常の内部ソース静的PATで置換ポートを使用して、そこから既に内部宛先NATを使用するサーバーにループバックすることができます。 そして、サーバー上の同じプロトコルが異なるポート（たとえば、80のどこか、8080のどこか）に応答する場合、これを行うことは完全に不可能です（nat enableも使用できるという感覚です）。 しかし、誰かがショットを必要とするなら、書いて、私はそれを理解しようとします。
2. 2つの変換が構成されている場合-1つは上記のように宛先内にあり、もう1つは同じサーバーのソース動的PAT内にあります。 それらの外に出て、逆ブロードキャストに該当しないトラフィックの場合（たとえば、リポジトリへのサーバーアクセスの場合）：
それらが重なっていることがわかります。 80番目のポートからのサーバーからの応答は、宛先内でのリバースブロードキャストと直接内部ソースで行われる必要があります（ところで、両方ともルーティング後にのみ機能します）。 この場合、逆ブロードキャストが勝ち、すべてが期待どおりに機能します。
3.宛先NATの内部を静的にすることはできません。 これを行うには、静的内部ソースNATを使用します。
結論として 。 要約すると、私はもう一度次のことに注意したい：
1.内部宛先NAT-バランシングを目的としたアドレス変換テクノロジー。TCPプロトコルでのみ機能します。
2.インターフェイスは内部ソースNATと同じ方法でラベル付けされますが、順方向ブロードキャストと逆方向ブロードキャストの方向は逆です。
3. NATの優先順位（内部から外部および外部から内部）は、内部ソースNATと同じです。
4.トラフィックが内部から外部への方向で開始された場合、ブロードキャストは行われません（内部ソースNATが既にツイストされていない場合）。
この記事を過負荷にしないことに決めたので、次の記事で外部ソースNATについて見ていきます。
伝統により-私は希望や提案を受け入れています。 これまでのところ、ポリシーNATがリストに載っています。
CiscoのNATに関する一連の記事tkを続けます。 前の記事はすべて、いくつかの肯定的なレビューを見つけました。
この記事では、約束どおり、宛先NATの内部を見ていきます。 誰も気にしない-猫の下でウェルカム。
さらに読む前に- 免責事項 ：同僚、私はすべての人がCisco全般、特にCLI、特にtsiskarsと正確に関連しているわけではないことを理解しています。 しかし、ホリバーを繁殖させず、議論をより建設的なものにしましょう。具体的には、この記事と記載された技術について具体的に議論します。 ブログは主題であるため、記事はその主題に含まれます。 また、別の要望として、意見の正しさに反対しないようにしましょう。 :)すべて、余談でごめんなさい。
だから
内部宛先NAT
実際、非常にエキゾチックな形式のNATは、TCPプロトコルで実行されるサーバー間の負荷分散のために特別に作成されました。 実生活では、日食よりも一般的ではありません:)
もっと深く行きましょう 。
1.したがって、このブロードキャストは、インターフェイスの外部からインターフェイスの内部への接続と応答トラフィックのために接続が開始された場合にのみ機能します（そのような言葉はごめんなさい）。 ただし、トラフィックが内部から開始された場合、ブロードキャストは行われません。
2.このようなNATは、TCPプロトコルでのみ機能します。
なんでそんな喜びが必要なの ？
10.0.0.1から10.0.0.10のアドレスを持つ12個のWebサーバーがあるとします。 同じサイトがすべてのサーバー（または、単にフロントエンドサーバーになります）で回転しており、簡単にするために1つのポート（80（HTTP））もあります。
外部からのクライアントは、11.1.1.1：80にある「スミア」サイトをタップしています。
そして、RR（ラウンドロビン）の原則、つまり そのため、外部からグローバルアドレスからルーターにアクセスする次の各クライアントは、このダース（円内）から次のサーバーにアクセスします。
このcなNATはここで役立ちます。
どのように機能しますか？
1. ライブブロードキャスト 。 内部ソースNATのロジックに基づいた論理的および習慣的な期待に反して、このタイプのライブブロードキャストは、外部から内部にアクセスするときに作成されます。 TCP（およびそれだけを繰り返します）トラフィックが外部インターフェイスに表示されると、トラフィックは最初に内部宛先NATに準拠しているかどうかチェックされます。 一致する場合、宛先アドレスはプール内の次のアドレスに変更され、ブロードキャストはブロードキャストのリストに入力されます。 その後、宛先アドレスがすでに変更されたパケットがルーティングされます。
___
UPD ：非TCPトラフィックはプールの最初のアドレスにルーティングされます。 コメントありがとうございます。
2. 逆ブロードキャスト 。 繰り返しますが、逆も同様です。 リバースブロードキャストは、内部から外部に向かっています。 そして、ここでは、内部から外部へのトラフィックをスローし、変換テーブルに対応するエントリがある場合、ルーティングが最初に動作します-パケットが中継されます。
備考
1.静的内部ソースNATおよび静的内部ソースPATとは異なり、ルーターはグローバルアドレスのARP要求に応答しません。もちろん、このアドレスがインターフェイスに割り当てられている場合を除きます。 したがって、インターフェイスにセカンダリとして追加する必要がある場合があります。
2.内部ソースNATの場合のように、内部インターフェイスがない場合でも、ルーターのトラフィックもブロードキャストされます。
3. p。2の結果：内部インターフェイスがない場合、ルーター自体のトラフィックのみがブロードキャストされます。
これがどのように構成されているかを見てみましょう。
1.したがって、最初にプールを作成します。 プール内のアドレスは、サーバーのアドレスです。
(config)# ip nat pool NAME_OF_POOL 10.0.0.1 10.0.0.10 netmask 255.255.255.0 type rotary
特にロータリーという言葉を強調しました-このタイプのNATの場合、プールは回転する必要があります（つまり、アドレスが次々に取得されることを示すだけです）
それ以外の場合、プールの最後に到達すると、次のパケットはドロップされます）。
2.ブロードキャストするトラフィックを割り当てるアクセスリストを作成します。 特別に拡張しました：
(config)# access-list 100 permit tcp any host 11.1.1.1 eq www
つまり グローバルアドレスと特定のポート（TCP！）に向けられたトラフィックを送信します。
3.ブロードキャストを作成しますが、少し残っています。
(config)# ip nat inside destination list 100 pool NAME_OF_POOL
4.インターフェイスをマークします（サーバーが内部にある場所、外部が外部にある場所）
(config)# int fa0/0
(config-if)# ip nat inside
(config-if)# int fa0/1
(config-if)# ip nat outside
そして今、サーバーへの呼び出しの様子を観察できます。
R3#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 11.1.1.1:80 10.0.0.1:80 11.1.1.251:18747 11.1.1.251:18747
tcp 11.1.1.1:80 10.0.0.2:80 11.1.1.250:52943 11.1.1.250:52943
グローバルアドレスの同じポート（つまり11.1.1.1:80）が異なるアドレスに変換されたことがわかります。
___
UPD ：当然、トラフィックはセッションごとにバランスが取れています。これは、TCPが正しく機能するために必要です。 コメントありがとうございます。
備考
1.グローバルアドレスの一部のポートを他のサーバーポート（たとえば、80番目から8080番目）にリダイレクトすることはできません。ポートは一致する必要があります。 本当に必要な場合は、ループバックをフックし、通常の内部ソース静的PATで置換ポートを使用して、そこから既に内部宛先NATを使用するサーバーにループバックすることができます。 そして、サーバー上の同じプロトコルが異なるポート（たとえば、80のどこか、8080のどこか）に応答する場合、これを行うことは完全に不可能です（nat enableも使用できるという感覚です）。 しかし、誰かがショットを必要とするなら、書いて、私はそれを理解しようとします。
2. 2つの変換が構成されている場合-1つは上記のように宛先内にあり、もう1つは同じサーバーのソース動的PAT内にあります。 それらの外に出て、逆ブロードキャストに該当しないトラフィックの場合（たとえば、リポジトリへのサーバーアクセスの場合）：
ip nat inside source list 110 interface FastEthernet0/1 overload
access-list 110 permit ip 10.0.0.0 0.0.0.255 any
それらが重なっていることがわかります。 80番目のポートからのサーバーからの応答は、宛先内でのリバースブロードキャストと直接内部ソースで行われる必要があります（ところで、両方ともルーティング後にのみ機能します）。 この場合、逆ブロードキャストが勝ち、すべてが期待どおりに機能します。
3.宛先NATの内部を静的にすることはできません。 これを行うには、静的内部ソースNATを使用します。
結論として 。 要約すると、私はもう一度次のことに注意したい：
1.内部宛先NAT-バランシングを目的としたアドレス変換テクノロジー。TCPプロトコルでのみ機能します。
2.インターフェイスは内部ソースNATと同じ方法でラベル付けされますが、順方向ブロードキャストと逆方向ブロードキャストの方向は逆です。
3. NATの優先順位（内部から外部および外部から内部）は、内部ソースNATと同じです。
4.トラフィックが内部から外部への方向で開始された場合、ブロードキャストは行われません（内部ソースNATが既にツイストされていない場合）。
この記事を過負荷にしないことに決めたので、次の記事で外部ソースNATについて見ていきます。
伝統により-私は希望や提案を受け入れています。 これまでのところ、ポリシーNATがリストに載っています。
All Articles