Ciscoルーター+ 2ISP + NAT。 2つのプロバイダーを介したサービスの可用性

プッシュ。 彼の後ろにもう少し強く。 以上です。 高山の牧草地が私の目の前で光り、ベージュのサンドレスを着た女の子が、ひざの付いたハンドルでレースの傘をふざけてひねり、過去も光りました。 あまり正確ではないが強力な腕をそれに向けて引っ張ったという事実、描かれたジェスチャーや表情、私の力を最大限に引き出したが、どのような包括的なkunyushushkaがそれを期待できるのか、それは私に向かって腕を広げたでしょうか？他の何かを投げる）。

しかし、何が起こったのか、そして彼女から巧妙にひったくられた傘だけが、のみでなく、粘り強い手で、私の目覚めの最後の数秒間にピンクの色調でわずかに陰影が付けられ、私の傷ついた心を温めました（彼女の髪を覆う傘なしで、少女は少し柔らかくなったはげを話す）。 目を開けると、それは奇妙なことではなく、新潟の遺跡の真ん中にいないことに気づき、すぐに震えの地震の性質を拒否しました。 少し安心。 叫びを止めた-「船を出て！」。 彼は非難して、部門の長が肩で私を揺さぶりました。 謝罪する代わりに、監督と私は彼が小さなながらも非常に責任ある仕事をするのを待っているというニュースを私にもたらしました。 彼の言葉を心に留めずに、私は何度かハゲ誘惑に戻ってみましたが、ボスは忍耐の奇跡を見せ続けました。 行かなければなりませんでした。



監督のオフィスに滞在する瞬間と戦闘ミッションを設定するプロセスは省略します。これらの犯罪シーンの詳細を知る必要はありません。ひどいベールに包まれた脅迫や開かれた恐mail、両親の養子の写真を示す涙と嘆願、絶望に満ちた腕を上げるすでに治安委員会の捜査官の番号がダイヤルされた状態でチューブを台無しにしないで投げることを要求します（あなたが見ることができるように、私はそのようなケースのために私の袖に切り札がありました-しかしその前に私はなぜ熱心に急いだのか考えなければなりませんでした 監督のラップトップのWi-Fi設定を確認し、「今、パパは誰だ、ダーリン？A？A BL ### b！？」と言われているように）。 しかし、何らかの方法でタスクが設定され、彼女はProject Serverキャンバスに立って、彼女を見た若い女の子が頬を持ち、他の女性チームは、あなたが知っているように、角に立つ彼らの壊れやすい半分の写真に嫌悪感を持って見ました年配の女性のテーブル。 後戻りはできませんでした-タスクを解決する必要がありました。



そのため、最終的には、特定のサーバーへのリモートアクセスを提供する必要がありました。特定のサーバーが遅延して許容できないダウンタイムを引き起こさないように、サーバー上で明らかに破損した性質のアクションを実行するためです。 このタスクのネットワーク部分は、私の壊れやすい肩に重く重ねられ、首にしっかりと抱きしめられました。 呼吸が困難になり、階段を上層階に登ることが難しくなりました。



私のオフィスに戻って、私は仕事とお金を返さずに質屋からパスポートを取り戻す方法について真剣に考えました。 「まあ、それは起こる可能性がある」と私は安心した。「私たちのインターネットは安定している。ひもをつけて、それを機能させ、人々や他の犯罪者を喜ばせる。」 当局に「チャンネルが落ちる確率は非常に高い！！」と報告した。 そして、この考えを公理と考えて、私は幸せそうに笑って、ピンクのサンドレスを着たハゲの女の子と一緒に視力を取り戻しました。 しかし、運が良ければ、当時の郡の電気通信事業者のエンジニアの好奇心は、3つの文字（それ以来、私にとって非常に不愉快）を拾い始めました-BGP、およびフィルタリングパス属性のあらゆる種類の改良を積極的に習得しました（すべての人が知っているように、これらのエンジニアが家族と直接結びつく可能性が高い）、RFC 4274の終わりまで信頼していない、宣言されたものに準拠するためにルート選択アルゴリズムをテストします。以前の陰謀（エンジニア、そして-悪の勢力）によるこのグループの行動のため、至福に 沈黙の私たちの部門は、ますます頻繁に電話を聞きました。 呼び出しの逐語的な内容は私にはわからないが、部門長の頭の最初の白髪の外観（彼が「ゼロ未満」とスタイル付けされたとき、かなり警戒すべき兆候である）および彼の（サービス）提供に関するサービスユーザーの印象を私に伝えるときの彼の豊かな表情によって判断する、状況は外科的介入を必要としました。



非常に専門的なネットワークエンジニア（私）のチームによる短いブレインストーミングセッションの結果に基づいて、バックアップチャネルを接続することが決定されました。 しかし、ルートの特定のセクションで闘争が行われていなかったため、殺害され、何かが発生した場合、メインからバックアップにチャネルを切り替えますが、BGPの研究を真剣に受け止めた悪の勢力により、両方のチャネルで同時にサーバーの可用性を構成する必要がありました（図1）。 そして、最初のアドレスが何らかの種類の自律からアクセスできない場合（アドレスはどこからでもアクセスできますが、どこからでもアクセスできない可能性があります）、ユーザーは2番目のアドレスに接続しますが、同時に、他のユーザーは最初のアドレスにアクセスすることでサーバーにアクセスできます。



図1



注： 敵の武器を彼に引きつけて使用することは確かに少し考えられていましたが、BGPについて言及するたびに部門全体が跳ね上がり、十字架で十字架を覆い隠したので、神に腹を立てないように請願でRIPEに書かないことにしました。



そのため、問題を解決する際に条件と制限を手に入れて、NAT、静的ルート、ルートマップのツールを使用して解決策が見つかりました。 図2に示す例で、このソリューションを検討してください。例のアドレス指定スキームは、プライベートアドレスのみを使用します。 最初のキャリア（ISP1）のオフィスルーター（R1）とゲート（R2）間のアドレスは172.16.12.0/29に変更され、2番目のキャリア（ISP2）のオフィスルーター（R1）とゲート（R3）間のアドレスは172.16.13.0に変更されます/ 29。 ローカルネットワークは、実生活でも例でも、プライベートネットワークアドレス192.168.1.0/24を使用します。192.168.1.1はルーターに属し、192.168.1.31はサーバーに属します。



R1#sh ip int br

Interface IP-Address OK? Method Status Protocol

FastEthernet0/0 172.16.12.1 YES NVRAM up up

FastEthernet0/1 172.16.13.1 YES manual up up

FastEthernet1/0 192.168.1.1 YES NVRAM up up









NATサーバーの場合、各プロバイダーのプールに次のIPアドレスを定義します。

ISP1：192.168.1.31-> 172.16.12.4

ISP2：192.168.1.31-> 172.16.13.4





図2。



最初のプロバイダー-ISP1のチャネルでサーバーの可用性を構成します。

最初のプロバイダーを通るデフォルトルート：

R1(config)#ip route 0.0.0.0 0.0.0.0 172.16.12.2







NATブロードキャストで使用されるインターフェイスを定義します。

R1(config)#int fa 0/0

R1(config-if)#ip nat outside

R1(config-if)#int fa 1/0

R1(config-if)#ip nat inside







Natimサーバー

R1(config)#ip nat inside source static 192.168.1.31 172.16.12.4 extendable







それだけです-サーバーは172.168.12.4のユーザーが利用できます。これはもちろん、構成領域をよく見る価値はありませんが、それでも全体像については必要です。

次に、2番目のプロバイダー-ISP2のチャネルでサーバーの可用性を設定します。

インターフェイスを定義し、NATブロードキャストで使用します。

R1(config)#int fa 0/1

R1(config-if)#ip nat outside







Natimサーバー

R1(config)#ip nat inside source static 192.168.1.31 172.16.13.4 extendable







そして、最も興味深い質問です。クライアントがISP 2を経由した場合、FastEthernet0 / 1インターフェイスを介してサーバーから応答を送信する方法です。最初に頭に浮かんだのは、後に判明したことです（明確化はいくつかの非常に効果的な手順で行われました異端審問の聖大臣の裁判所のスペイン支部から借用し、結果は疑いの余地はありません）正しい決定です-これはルートマップの使用です。 そのため、fa1 / 0インターフェイスでは、ISP2を介して着信するクライアントに返されるパケットをインターセプトする必要があります。 これらのパケットをどのように一致させるかはまだ完全には明らかではありません。 パケットの送信元アドレスは同じです-192.168.1.31、宛先もパケットがルーターに送られたインターフェースを決して識別しません。 緊張が高まり、解決策は生まれませんでした。 誘惑者の膝との繰り返しの遭遇の見込みは減りました。 大量のグーグル検索と論文「カモフラージュとアート：第二次世界大戦での欺forのためのデザイン2.ユニコーンプレス」を読んだ後、解決策が生まれました-構成に導入し、後で説明します。

R1(config)#ip nat pool ISP_2nd 192.168.133.0 192.168.133.254 prefix-length 24

R1(config)#access-list 100 permit ip any host 172.16.13.4

R1(config)#ip nat outside source list 100 pool ISP_2nd add-route







2番目のプロバイダーからインターフェイスfa 0/1に到着するパケットの場合、ユーザーアドレス（ソースIPアドレス）をプール192.168.133.x / 24に変換し、2番目のオペレーターを介してサーバーにアクセスするユーザーに返されるパケットはインターフェイスfa 1 /になります0には、フィールドdst ip addr = 192.168.133.xがあります。これにより、次のことができます。



R1(config)#access-list 101 permit ip any 192.168.133.0 0.0.0.255

R1(config)#route-map 2ISP permit 10

R1(config-route-map)#match ip address 101

R1(config-route-map)#set ip next-hop 172.16.13.3

R1(config-route-map)#exit

R1(config)# int fa 1/0

R1(config-if)#ip policy route-map 2ISP







そして出来上がり-実行可能なソリューションの準備が整いました。 経営陣への簡単な報告書、そしてそれは…それをロールバックし、ワインを注ぎ、近くの村を燃やし、一般に、その月の計画の通常の実施に注意し、人生を楽しんでいますが...ではありません。 GNS3のラボを収集し、2つのクライアントホストのリソースを節約して、私は1つに制限し、次の機能に気付きました-クライアントがNATブロードキャストのアドレス172.16.13.4に2番目の通信事業者を介してサーバーに接続する場合、次の行を取得します：

R1#show ip nat translations

Pro Inside global Inside local Outside local Outside global

--- --- --- 192.168.133.1 ZZ.ZZ.ZZ.ZZ

tcp 172.16.13.4:3389 192.168.1.31:3389 192.168.133.1:59324 ZZ.ZZ.ZZ.ZZ:59324







最初の行に特に注意を払います。 何らかの理由でユーザーがISP1を介して切断され、アドレス172.16.12.4に再接続された場合、ユーザーからのパケットの送信元アドレスもプール192.168.133.x / 24に変換され、サーバーからのパケットはルートマップに分類されますISP2ネットワークへのfa0 / 1インターフェイスを介してスローされます。 放送の場合



t cp 172.16.13.4:3389 192.168.1.31:3389 192.168.133.136:59324 ZZ.ZZ.ZZ.ZZ:59324







最終的に期限切れになり、タイムアウト後にブロードキャストはクリアされますが、最初のブロードキャストはまだハングし、深刻な問題が発生します。 そして、広告が「なぜそれを試してみなかったのですか！」と言ったように、私は最初のfa 0/0で追加のNATを試して、VRFの2番目のインターフェースとNAT NVIのローカライズを試み、ウスリ神話のトラに対する寛大な血の報酬- 「Duse」、そしてルーターの周りのデイビッドの星に7人の処女（当然、小学校ではマチネではありません）を構築する確実な方法でさえ、彼は目を滑らかにしましたが、望みの結果をもたらしませんでした（から実行している同僚の気まずい顔によって判断しましたが）セレモニー中のキャビネット-望みどおりの結果は誰でも異なる e）。 この状況では、同じチームの非常に専門的なエンジニア（悪の勢力のエンジニアと混同しないように）を迅速に収集する必要があり、彼女（状況）はこのコレクションを受け取りました。 さて、すべてがパターンに従って進みます-ブレーンストーミング、解決策の発見、実装、当局への報告、血なまぐさい報復、ソスノフカのscar色の輝きなど。



さあ、早速始めましょう。 トポロジには重大な変更はありません。IPアドレス10.0.0.1/32のループバック0インターフェイスのみが追加されます。 使用されるIOS機能に関しては、これもポリシーベースのルーティングになります。



図3



設定を行います（設定は0から行われます-以前の設定は削除されます）。

NAT変換のインターフェースを定義します。

R1(config)#int fa 0/0

R1(config-if)#ip nat outside

R1(config-if)#int lo0

R1(config-if)#ip nat outside

R1(config-if)#int fa 1/00

R1(config-if)#ip nat inside







現在、fa 0/1インターフェイスがNAT操作に関与していないことに注意してください。



NATルールを追加します。

R1(config)#ip nat inside source static 192.168.1.31 172.16.12.4 extendable

R1(config)#ip nat inside source static 192.168.1.31 172.16.13.4 extendable







最初のプロバイダーを通るデフォルトルート：

R1(config)#ip route 0.0.0.0 0.0.0.0 172.16.12.2







そのため、fa0 / 0（ISP1を介した）経由のアクセスが既に提供されています。2番目の演算子を使用する場合、まだ推測していない場合、fa0 / 1インターフェイスでNAT変換を実行する代わりに、着信パケットをリダイレクトしますこのインターフェイスからlo0インターフェイスに移動し、172.16.13.4でサーバーをスレッド化します。 これにより、lo0でroute-mapを使用して、2番目のプロバイダー経由で返されるサーバーからのパケットを追跡し、GRT（一般ルーティングテーブル）をバイパスしてfa 0/1経由でリダイレクトする機会が得られます。 合計で、このアクションには3つのルートマップが関与します。

R1(config)#ip access-list extended from_2ndISP

R1(config-ext-nacl)#permit ip any host 172.16.13.4

R1(config-ext-nacl)#route-map from_2ndISP permit 10

R1(config-route-map)#match ip address from_2ndISP

R1(config-route-map)#set interface Loopback1

R1(config-route-map)#int fa 0/1

R1(config-if)#ip policy route-map from_2ndISP







このmapaルート（from_2ndISP）は、fa0 / 1インターフェースに到着するすべてのパケットをlo0インターフェースにリダイレクトし、そこでNATブロードキャストと、サーバーへのパケットのさらなるルーティングがGRTの接続されたルートを介して行われます。



次へ

R1(config)#ip access-list extended srv_2_loop

R1(config-ext-nacl)#permit ip host 192.168.1.31 any

R1(config-ext-nacl)# route-map srv_2_loop permit 10

R1(config-route-map)#match ip address srv_2_loop

R1(config-route-map)#set interface Loopback1

R1(config-route-map)#int fa 1/0

R1(config-if)#ip policy route-map srv_2_loop







このルートマップ（srv_2_loop）を使用すると、サーバーからのすべてのパケットがlo0インターフェイスにリダイレクトされ、逆NAT変換を通過した後、パケットはインターフェイスキューに到達します（開始されたセッションのソースフィールドは192.168.1.31ではなく172.16.13.4になります） 2番目の通信事業者を通じて）、これにより、

R1(config)#ip access-list extended back_2ndISP

R1(config-ext-nacl)#permit ip host 172.16.13.4 any

R1(config-ext-nacl)# route-map back_2ndISP permit 10

R1(config-route-map)#match ip address back_2ndISP

R1(config-route-map)#set ip nex-hop 172.16.13.3

R1(config-route-map)#int fa lo0

R1(config-if)#ip policy route-map back_2ndISP







ソース172.16.13.4から2番目の通信事業者のゲートウェイにパケットをリダイレクトすると、acl back_2ndISPに該当しないものはすべてGRTを使用してルーティングされます。



それだけです。 両方のオプションが機能していると認識できますが、多くの状況で最初のものはそのようなものではなくなります。そのため、2番目の方法はエレガントではありませんが、より信頼性が高くなります。



そのためには、読者に理解を任せます（おそらく誰かがそれを読んだ後に啓示を受けたので、時間をかけてください）。私は絵のように美しい遊歩道に沿って散歩に出かけ、ベージュのレースの傘の下で堂々とした姿で周囲の風景をリフレッシュします。



使用された文献：



ジェフ・ドイル、ジェニファー・デヘイブン・キャロル。 ルーティングTCP / IP、ボリュームII（2001 CiscoPress）

I.A.クリレフ。 Bonき火と科学と科学者に対する拷問（1933; reprint。、1934）。

M.M.シャインマン。 神の名における火と血（1924）; 教皇（1959）; Pius IXからJohn XXIII（1966）まで。

I.O. スサニン。 オリエンテーリングとGLONASSの使用の基本（2010; Polit。Publ。）