トップ > 助け合いフォーラム > CCNA/CCNP関連 > CCNA全般 (前の質問|次の質問)

NAT後アドレスを広報するには

フォーラムは新サイトへ移行しました。
このフォーラムではゲスト投稿が禁止されています

NAT後アドレスを広報するには

msg# 1

前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 .2 .3 | 投稿日時 2013-9-10 21:29

ゲスト投稿数: 0

フォーラムとして不適切な質問であれば申し訳ありません。

例
192.168.0.0/24--[RT-A]----[RT-B]--172.16.0.0/24
変換前：192.168.0.0/24
変換後：200.0.0.0/24

NAT/NAPTを勉強していて疑問に思ったのですが、
RT-AはNAT後のアドレス200.0.0.0/24をoutsideの
先にいるRT-Bへ経路広報するにはどうすればよいのでしょうか？
RIPやOSPF,EIGRPはI/Fに振っていないアドレス帯を
広報できるのでしょうか？

なお、ダイナミックルーティングでどうするのかという
疑問なので、RT-Bにスタティックで設定する、デフォルト
ルートをRT-Aに向けるなどの方法は除外です。

宜しくお願いします。

Re: NAT後アドレスを広報するには

msg# 1.1

前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2013-9-10 23:43

arashi1977

居住地: 広島投稿数: 1715

構成で１点確認です。
RT-AとRT-Bの接続ですが200.0.0.0/24のアドレスが付与されている前提ではないのでしょうか？
仮に
192.168.0.0/24 - (fa0/0)RT-A(s0/0) - (s0/0)RT-B(fa0/0) - 172.16.0.0/24
な構成だとすると、RT-AおよびRT-Bのs0/0に200.0.0.0/24の範囲のアドレスを付与した上でRT-Aが192.168.0.0/24のアドレスをNATするように思えるので、ルーティング情報の広告をする必要性が見えないのですが…

Re: NAT後アドレスを広報するには

msg# 1.1.1

前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2013-9-11 0:07 | 最終変更

ゲスト投稿数: 0

arashi1977さん
コメントありがとうございます。

> 構成で１点確認です。
> RT-AとRT-Bの接続ですが200.0.0.0/24のアドレスが
> 付与されている前提ではないのでしょうか？

質問させて頂いた前提としてはRT-AとRT-B間は
200.0.0.0/24は振りません。他のアドレスを
振ります。今回の疑問の背景としては、
-------------------------------------------------
X社とY社が合併することになったが、
X社A拠点とY社C拠点では同じアドレスが使われていた。
将来的には再アドレッシングを行うが、統合が最優先で
ある為に何とかしなくてはいけない。
なお、A拠点とC拠点の間の通信は無く、
B拠点が発となる通信がある前提である。

192.168.0.0/24--[RT-A]--(WAN)
172.016.0.0/24--[RT-B]--(WAN)
192.168.0.0/24--[RT-C]--(WAN)
-------------------------------------------------
のようなシチュエーションの時に、RT-A配下の192.168.0.0/24を
200.0.0.0/24に静的NATで変換すれば良さそうですが、
RT-BがA拠点宛ての経路を持つ為にはダイナミック
ルーティングではどうするのかと思ったのが、質問させて
頂いた次第です。

Re: NAT後アドレスを広報するには

msg# 1.1.1.1

前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2013-9-11 13:57 | 最終変更

arashi1977

居住地: 広島投稿数: 1715

うーん…私の理解がおかしかったらツッコみをお願いします。

まず、疑問の背景となった構成は

RT-A --- RT-B --|- RT-C
  |        |    |    |
  |        |    |    |
Seg-A    Seg-B  |  Seg-C
                |
           統合による
X社        接続ポイント Y社

って感じですよね。
で、B拠点がX社の本店、A拠点はX社の支店、C拠点はY社の本店というような構成を想定されているんですよね。（で、あってるかな？それともRT-BはY社側かな？）
そして
引用：

なお、A拠点とC拠点の間の通信は無く、B拠点が発となる通信がある前提である。

ということから、統合後はX社本店（B拠点）→統合後X社新支店（C拠点）向け通信およびその通信に対する応答がC拠点→B拠点に帰るという動きですよね。
そしてA拠点とC拠点の通信はないという。

それからすると
・C拠点のWAN側I/FにてNAT
・B拠点のC拠点接続I/FにてNAT
のいずれかになると考えられます。A拠点はもともとA-B拠点間通信があるので、A拠点の構成をいじると既存の業務に影響が出ると想定されるからです。

となると、基本的には
・B拠点にC拠点のNATアドレスに向けたルーティングがあればよい
・A拠点はB拠点からダイナミックルーティングで経路情報をもらえばよい（要件的には不要ですが）
のであり、C拠点（想定されていたのはA拠点ですかね？）から経路情報を広告する必要がないですよね。

私の見えていない要件、制約があればもう少し話が変わってくるかもしれませんが…

ここからは余談ですが、NATに使用する予定の200.0.0.0/24は設問で与えられたセグメントでしょうか？
このアドレスレンジはグローバルアドレスであり、通常企業内ネットワークで使用するアドレスではない範囲なので、要件として指定されているのでなければ使用しない方がいいですよ

Re: NAT後アドレスを広報するには

msg# 1.1.1.1.1

前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2013-9-11 20:45

ゲスト投稿数: 0

arashi1977さん

返信ありがとうございます。
構成の認識が少し違っております。
私が例で書いた企業統合のシチュエーションでは
広域LANのような網型WANを考えての記載です。
そのため、RT-BはWAN向けIFを2つは
持たずに1つです。
(RT-BはX社のほうでOKです)

> ということから、統合後はX社本店（B拠点）→統合後
> X社新支店（C拠点）向け通信およびその通信に対する
> 応答がC拠点→B拠点に帰るという動きですよね。
> そしてA拠点とC拠点の通信はないという。

はい、そうです。

> それからすると
> ・C拠点のWAN側I/FにてNAT
> ・B拠点のC拠点接続I/FにてNAT
> のいずれかになると考えられます。A拠点はもともと
> A-B拠点間通信があるので、A拠点の構成を
> いじると既存の業務に影響が出ると想定されるからです。

前回の質問ではRT-A配下の192～を200～に変換と
書いていますが、重複してしまったA拠点とC拠点の
どちらかを変更すれば良いので、以降はRT-C配下の
192～を変換するとします。

> となると、基本的には
> ・B拠点にC拠点のNATアドレスに向けたルーティングがあればよい

はい、まさにそうです。
重複したSeg-CはNATしないことには、RT-Bからすると
192.168.0.0/24がRT-AとRT-Cのそれぞれ向こうにいる
ように見えるので、RT-CはRT-Bに対して、Seg-Cは
200.0.0.0/24だと言うことを広報する必要があると
考えています。

> ・A拠点はB拠点からダイナミックルーティングで経路情報を
> もらえばよい（要件的には不要ですが）
> のであり、C拠点（想定されていたのはA拠点ですかね？）から
> 経路情報を広告する必要がないですよね。

初めに書いたように網型WANによる接続をイメージしての
質問でしたので、RT-AはRT-Bから経路情報をもうらのでは
なく、RT-Aも経路情報をRT-Cからもらいます。
ただ、今回の拠点間通信の要件としては、RT-AはRT-Cから
もらえなくても問題はありません。

長くなりましたが、RIPやOSPFでnetworkコマンドで
経路を設定する時、自I/FのアドレスのNWアドレスを
入力するかと思いますが、今回の例でいえば、RT-Cは
Seg-CのIFは192.168.0.0/24なのに、
network 200.0.0.0 みたいなことができるのか？と
疑問に思ったのです。

200.0.0.0/24がグローバルである旨、ありがとうございます。
実際に業務で直面しているとかではありませんし、
とりあえず例として書いたアドレスにすぎません。

宜しくお願いします。

Re: NAT後アドレスを広報するには

msg# 1.1.1.1.1.1

前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2013-9-12 10:01 | 最終変更

arashi1977

居住地: 広島投稿数: 1715

なるほど、なんとなく見えてきました。
最後の確認です。
引用：

私が例で書いた企業統合のシチュエーションでは
広域LANのような網型WANを考えての記載です。
そのため、RT-BはWAN向けIFを2つは
持たずに1つです。

これは「統合される拠点も含めたフルメッシュ構成である」という意味ですか？
私が読み取った構成はX社本店（RT-B）を中心としたハブアンドスポークだと思っていたので、RT-Bからの広告だけでよいと判断し、統合される側のルータからの通知は不要と理解していました。
フルメッシュであれば拠点Cの経路情報が全拠点に広告される必要があるというのも理解できました。

ということで、それらしい構成を作って確認してみました（フレームリレーでのフルメッシュ）。
各ルータの基本的な状態です。長くて済みません…
RT-B:

RT-B#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            172.16.0.1      YES manual up                    up
Serial0/0                  10.1.1.1        YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down
Serial0/1                  unassigned      YES unset  administratively down down
RT-B#show frame-relay map
Serial0/0 (up): ip 10.1.1.2 dlci 102(0x66,0x1860), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 10.1.1.3 dlci 103(0x67,0x1870), dynamic,
              broadcast,, status defined, active
RT-B#show ip protocols
Routing Protocol is "eigrp 1"
（略）
  Routing for Networks:
    10.1.1.1/32
    172.16.0.0/24
  Routing Information Sources:
    Gateway         Distance      Last Update
    10.1.1.2              90      00:10:22
  Distance: internal 90 external 170

RT-B#show ip route
（略）
Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.0.0 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Serial0/0
D    192.168.0.0/24 [90/2195456] via 10.1.1.2, 00:10:32, Serial0/0
RT-B#ping 10.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/216/456 ms
RT-B#ping 10.1.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/222/656 ms

RT-A:

RT-A#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.0.2     YES manual up                    up
Serial0/0                  10.1.1.2        YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down
Serial0/1                  unassigned      YES unset  administratively down down
RT-A#show frame-relay map
Serial0/0 (up): ip 10.1.1.1 dlci 201(0xC9,0x3090), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 10.1.1.3 dlci 203(0xCB,0x30B0), dynamic,
              broadcast,, status defined, active
RT-A#show ip protocols
Routing Protocol is "eigrp 1"
（略）
  Routing for Networks:
    10.1.1.2/32
    192.168.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    10.1.1.1              90      00:10:55
  Distance: internal 90 external 170

RT-A#show ip route
（略）
Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
D       172.16.0.0 [90/2195456] via 10.1.1.1, 00:10:58, Serial0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Serial0/0
C    192.168.0.0/24 is directly connected, FastEthernet0/0
RT-A#ping 10.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/134/596 ms
RT-A#ping 10.1.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/114/376 ms

RT-C:

RT-C#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.0.3     YES manual up                    up
Serial0/0                  10.1.1.3        YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down
Serial0/1                  unassigned      YES unset  administratively down down
RT-C#show frame-relay map
Serial0/0 (up): ip 10.1.1.1 dlci 301(0x12D,0x48D0), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 10.1.1.2 dlci 302(0x12E,0x48E0), dynamic,
              broadcast,, status defined, active
RT-C#show ip protocols

RT-C#show ip route
（略）
Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Serial0/0
C    192.168.0.0/24 is directly connected, FastEthernet0/0
RT-C#ping 10.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/106/372 ms
RT-C#ping 10.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/49/192 ms

上記の通り、RT-A/BについてはX社のネットワークとしてEIGRPを使用している想定です。
RT-CはこれからX社のネットワークにつなぐのでいまからEIGRPの設定を行います。
期待されている要件を満たすには

interface FastEthernet0/0
 ip nat enable
!
interface Serial0/0
 ip nat enable
!
router eigrp 1
 network 10.1.1.3 0.0.0.0
 redistribute static metric 1500 100 255 1 1500
!
ip nat pool MERGE_C 200.0.0.100 200.0.0.100 netmask 255.255.255.0 add-route
ip nat source list LOC_C pool MERGE_C
!
ip access-list standard LOC_C
 permit 192.168.0.100

でいけるかと思います。
CCNA,CCNPでは試験範囲外だったかと思いますが、仮想NATインタフェースを使用してルーティングを生成させ、それをダイナミックルーティングで配送するという手法です。
適用結果はこうなります。

RT-C#show ip route
（略）
Gateway of last resort is not set

S    200.0.0.0/24 [0/0] via 0.0.0.0, NVI0 ← 200.0.0.0/24のスタティックルートが追加される
     172.16.0.0/24 is subnetted, 1 subnets
D       172.16.0.0 [90/2195456] via 10.1.1.1, 00:04:38, Serial0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Serial0/0
C    192.168.0.0/24 is directly connected, FastEthernet0/0
RT-C#show ip nat nvi translations
Pro Source global      Source local       Destin  local      Destin  global
icmp 200.0.0.100:19469 192.168.0.100:19469 172.16.0.10:19469 172.16.0.10:19469
icmp 200.0.0.100:19725 192.168.0.100:19725 172.16.0.10:19725 172.16.0.10:19725
icmp 200.0.0.100:20237 192.168.0.100:20237 172.16.0.10:20237 172.16.0.10:20237
icmp 200.0.0.100:20493 192.168.0.100:20493 172.16.0.10:20493 172.16.0.10:20493
--- 200.0.0.100        192.168.0.100      ---                --- ← 200.0.0.100 と 192.168.0.100 がマッピングされている

※先頭が「icmp」な4行は実際に192.168.0.100から172.16.0.10へping疎通を実施したために記録されています
なお、当然のことですがEIGRPでもらったRT-A配下の192.168.0.0/24のルートよりconnectedのほうがAD値が低いため直接接続経路（拠点CのLAN）が有効となっています。

RT-A:

RT-A#show ip route eigrp
D EX 200.0.0.0/24 [170/2244096] via 10.1.1.3, 00:00:11, Serial0/0
     172.16.0.0/24 is subnetted, 1 subnets
D       172.16.0.0 [90/2195456] via 10.1.1.1, 01:10:21, Serial0/0
RT-A#ping 200.0.0.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.100, timeout is 2 seconds:
!....
Success rate is 20 percent (1/5), round-trip min/avg/max = 744/744/744 ms

RT-B:

RT-B#show ip route eigrp
D EX 200.0.0.0/24 [170/2244096] via 10.1.1.3, 00:14:01, Serial0/0
D    192.168.0.0/24 [90/2195456] via 10.1.1.2, 01:24:16, Serial0/0
RT-B#ping 200.0.0.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.100, timeout is 2 seconds:
!....
Success rate is 20 percent (1/5), round-trip min/avg/max = 1144/1144/1144 ms

※pingが1個目しか通らないのはこちらの環境のせいかと思うので気にしないでください

のように、とりあえずは広告された経路で疎通は可能になります。
ただ
引用：

重複したSeg-CはNATしないことには、RT-Bからすると
192.168.0.0/24がRT-AとRT-Cのそれぞれ向こうにいる
ように見えるので、RT-CはRT-Bに対して、Seg-Cは
200.0.0.0/24だと言うことを広報する必要があると
考えています。

設計面で考えれば、RT-BからしかRT-C配下のセグメントには通信が発生しないため、RT-Bにてスタティックルーティングを定義し、それを（通信要件として必要であれば）ダイナミックルーティングで他のルータに配信する形のほうがスマートかなぁと。RT-Cの拠点が勝手にNAT後セグメントを決めるのではなく、RT-Bからの宛先として指定するセグメントSeg-CをRT-Cに設定するわけですし。
拠点B（というか本店）のネットワークエンジニアが新たに接続する拠点Cとどのように通信するかを決めてコンフィグしないと、RT-Cからの経路広告に引きずられて既存のX社ネットワークに障害が発生することを考えると…((((;゜Д゜)))ガクガクブルブル

ご質問の回答になってればよいのですが