同僚（
Fedia ）の要請で、私は考えをまとめ、NAT NVIに関する記事を書くことにしました。 一般的に、ルーター上のアドレスの変換は何度も考慮されていると言わなければなりません。 記事「
労働者の要求に応じて：BGPを使用しないCiscoルーター上のデュアルISP 」 ただし、ここで説明する内部ソースおよび外部ソースNATメカニズムにはいくつかの制限があります。
タスク1特に、トポロジーを考慮してください：
問題の声明。R0でブロードキャストする必要があります。
- 1. R2のアドレス（10.0.2.0/24）-R1にアクセスするときのインターフェイスfa 0/0へ
- 2. R3のアドレス（10.0.3.0/24）-インターフェイスfa 0/1で、R2にアクセスする場合
インターフェイスアドレスは1であるため、PATは当然使用されます。
決定番号1。放送自体は、それぞれの場合に非常に簡単に書かれています。
Router(config)# access-list 101 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
Router(config)# ip nat inside source list 101 interface fa 0/0 overloadRouter(config)# access-list 102 permit ip 10.0.3.0 0.0.0.255 10.0.2.0 0.0.0.255
Router(config)# ip nat inside source list 102 interface fa 0/1 overloadここで、翻訳に参加する各インターフェイスについて、翻訳の内部（内部）か外部（外部）かを示す必要があります。 すべてが単純に思えますが、問題は次のとおりです。fa0/1インターフェースは、内側と外側の両方で行う必要があります。 これは不可能です。各インターフェイスは内部でも外部でもかまいません。
古典的なNATを使用してこのような問題を解決することは、深刻なトリックを使用することでのみ可能です。
最初の解決策は、PBR（ポリシーベースのルーティング）テクノロジを使用することです。 アイデアは次のとおりです。
- 1. R0でfa 0/1を外部として設定します。
- 2. R0で、いくつかのアドレスで仮想インターフェイス（ループバック）lo0を作成し、その上でip natを有効にします。
- 3.このトラフィックをfa 0/0インターフェイスに変換する必要がある場合、fa 0/1からlo0にトラフィックをリダイレクトします。
境界条件 。 ここで、いくつかの予約をすることができます。
まず、このようなトリックが常に可能ではないという事実に注意を喚起したいと思います。 実際、PBRは、内部から外部へのNATよりも早くトリガーされます（Ciscoの記事「複雑な構成のパケット処理手順」を参照）。 外部から内部へのNATの場合、これは当てはまりません。 NATルールが最初にチェックされます。
第二に、ルーターに過度の負荷がかかるため、 PBRを介してパケットを送信すると、常にプロセッサがロードされます。
つまり 解決策は、従来のNATの範囲を超えていませんが、非常に脆弱な小道具に基づいています。
決定番号2 。
さて、実際には、この記事が書かれたため、そのバージョンに取り掛かりましょう。
Cisco NVI NAT（またはip nat enableと呼ばれることもあります）テクノロジーにより、インターフェイスを内部または外部としてマークすることを心配する必要がなくなります。 次のコマンドを使用して、NATに含まれるものとしてマークするだけです。
Router(config-if)# ip nat enableそして、統一されたルールを書きます。 特に、私たちの場合、これらのルールは、内部に単語がない場合にのみ異なります。
Router(config)# access-list 101 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
Router(config)# access-list 102 permit ip 10.0.3.0 0.0.0.255 10.0.2.0 0.0.0.255
Router(config)# ip nat source list 101 interface fa 0/0 overload
Router(config)# ip nat source list 102 interface fa 0/1 overloadまた、ルーター自体は、インターフェイスでパケットを受信すると、このパケットを直接または逆ブロードキャストに公開し、このブロードキャストの方向を理解します。
当然、このような「自動化」では、ブロードキャストの「興味深い」トラフィックをより慎重に設定する必要があります。表面的に説明すると、双方向で予測できない数のブロードキャストを取得できるためです。
それでも、実際のネットワークでは、説明したトポロジは非常にまれです。 原則として、小規模なプロバイダーが必要です。 したがって、ここで、より重要なタスクの解決策を説明したいと思います。
タスク2問題の声明。多くの場合、外部からの一部のリクエストでは、「リクエスタ」を内部アドレスとして提示したいことがあります。
トポロジを検討する
タスク条件：- 1. R1では、192.168.0.0 / 24ネットワークからのホストの場合、PATはアドレス172.16.1.5に設定されます。
- 2. SRV1では、デフォルトゲートウェイはR2に設定されます。
- 3. SSHポート（22）をR1上のサーバーに転送する必要があります。
分析 。
明らかに、この場合の古典的な静的PATは適切ではありません。 インターネットからの要求に応じて、アドレスと宛先ポートのみを変更し（172.16.1.5:22から192.168.1.2:22に変更）、ソース（インターネットからの任意のアドレス）は変更しません。 その後、SRVからの応答はデフォルトゲートウェイを通過します。 R2経由でインターネットに接続します。
ただし、同じ方法で回答を返す必要があります-R1、つまり そのため、サーバーに接続しているクライアントは、アドレス指定した同じグローバルアドレスから応答を受け取ります。 これを行うには、ホストが172.16.1.5:22に何らかの内部アドレス（たとえば192.168.0.201）としてアクセスし、このアドレスへの回答がR2からローカルネットワーク経由でR1にルーティングされ、その後インターネットにのみルーティングされると想像すると便利です。
これには外部ソースNATを使用できるように見えますが、Cisco IOSには1つの問題があります。外部ソースNATはPATにできません。 ネットワークレベルで動作し、アドレスをアドレスに変換します。 これにより、プールへのブロードキャストが強制されます。 また、このような同時ブロードキャストの数は、プールの容量によって制限されます。
インターネット上のアドレスの数が所定のプールを超えており、サーバーに非常にアクセスできるため、このソリューションは私たちにはあまり適していません。
解決策。Cisco NVIを見てみましょう。 変換の方向がインターフェイスで設定されなくなったため、いくつかの直接PAT変換を実行できます。
1.ブロードキャストして、ホストのインターネットにアクセスします。
Router(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any
Router(config)# ip nat source list 100 interface fa0/0 overload2.ポート転送用のブロードキャスト：
ip nat source static tcp 192.168.1.2 22 172.16.1.5 22 extendable
3.すべての種類の要求ホストのアドレスの内部アドレス192.168.0.201への変換
Router(config)# access-list 101 permit tcp any host 172.16.1.5 eq 22
Router(config)# ip nat pool SERV_PAT 192.168.0.201 192.168.0.201 prefix-length 24
Router(config)# ip nat source list 101 pool SERV_PAT overloadつまり、2つの動的PAT変換と1つの静的PAT変換を組み合わせました。
もちろん、この記事はCisco NVI NATの可能性を完全に明らかにするものではありませんが、トポロジでNATを頻繁に使用し、従来のNATの機能に限定したくない場合に役立ちます。
PS招待してくれたFedia、habrabschestvoに慣れていること、そして仲間がこの作品を書くという事実に感謝します:)
Podkopaev Ilya、インストラクター