別セグメントを経由して同セグメント間通信を実現させる方法を検証してみた
本記事の趣旨
同セグメント間通信は通常L2処理で実現させることができるが、別拠点にそれぞれ同じネットワーク帯を持っている場合、別セグメントを経由してどのように疎通できるかをCisco Packet Tracerを用いて検証する。
構成図
PC1とPC2が同一セグメント上(192.168.1.0/24)に存在し、その間に192.168.2.0/24という別セグメントが存在している。
条件
①ルータにデフォルトルートのみを設定した場合
同じセグメント間であるにもかかわらず、PC1→PC2へのpingは通らない。
これがなぜ通らないかというと、ロンゲストマッチの法則に基づいているからだと推測できる。
ルータ1のルーティングテーブルを参照すると、Connectedルートとして192.168.1.0/24宛ての経路が記載されている。
PC2へ到達するためにはルータ2へ到達＝デフォルトルートを通る必要があるが、ロンゲストマッチの法則により192.168.1.2宛ての通信はデフォルトルートよりもConnectedルートが優先され、ルータ1とConnectedの端末に192.168.1.2のアドレスが存在しないためパケットが破棄されていると考えられる。
ちなみに、ルータ2のアドレスである192.168.2.254にもpingは通らない。
PC1(192.168.1.1)→ルータ2(192.168.2.254)の行きの通信はデフォルトルートの処理で問題なく到達できるが、帰りのパケットの宛先アドレスとなる192.168.1.1はルータ2側でConnectedルートとして処理され、ルータ1へは戻らないためである。
②ルータに/32のスタティックルートを追加した場合
ロンゲストマッチの法則でConnectedルートが優先されるならば、Connectedルートよりも当てはまるビット数が長い/32でスタティックルートを設定した場合はどうなるのかを検討する。
ルータ1
#ip route 192.168.1.2 255.255.255.255 192.168.2.254 を追加
ルータ2
#ip route 192.168.1.1 255.255.255.255 192.168.2.1 を追加
PC1→PC2への疎通が成立した。このことから、ロンゲストマッチの法則でConnectedルートを上回るようスタティックルートを設定すれば別セグメントを経由しても同セグメント間通信は成立することがわかる。
しかしデメリットとして、実環境では各端末（サーバ）毎のスタティックルートをそれぞれのルータに1本ずつ追加する必要があるので、数十行数百行というおびただしい数の設定追加が必要になる。
③ルータにTwice NATの設定を追加した場合
NATには3つ種類が存在する。
・Source NAT
送信元IPを変換する。いわゆる普通のNAT。
・Destination NAT
宛先IPを変換する。主にサーバをインターネット上に公開する際に用いる。
・Twice NAT
送信元/宛先IPをどちらも変換する。
Twice NATで使う主なconfigとしては下記の2つ。
#ip nat inside source static 内部ローカルIP 内部グローバルIP
・Inside側から着信してくるパケットの送信元IPを変換
・Outside側から着信してくるパケットの宛先IPを変換
#ip nat outside source static 外部グローバルIP 外部ローカルIP
・Outside側から着信してくるパケットの送信元IPを変換
・Inside側から着信してくるパケットの宛先IPを変換
送信元IPと宛先IPを変換するTwice NATの設定を入れて、そもそも同セグメント間通信にしなければ疎通ができるのか検証してみる。
なお、ここではNATの変換後のアドレスはすべてルータの物理IFに紐づいているアドレスを指定している。
ルータ1
#ip nat inside source static 192.168.1.1 192.168.2.1
#ip nat outside source static 192.168.2.254 192.168.1.254
#ip route 192.168.1.254 255.255.255.255 g0/1
#int g0/0
#ip nat inside
#int g0/1
#ip nat outside
ルータ2
#ip nat inside source static 192.168.1.2 192.168.2.254
#ip nat outside source static 192.168.2.1 192.168.1.253
#ip route 192.168.1.253 255.255.255.255 g0/1
#int g0/0
#ip nat inside
#int g0/1
#ip nat outside
※ルータのパケット処理の順序は下記の通り。
・Inside→Outsideへの通信
ルーティングテーブル参照→NAT変換→ACLチェック
・Outside→Insideへの通信
NAT変換→ルーティングテーブル参照→ACLチェック
このようにInside側からのパケットはNAT変換が後に来る関係で、/32のスタティックルートを1行追加する必要がある。
show ip nat translationsコマンドでNATテーブルが作成されているのは確認できたが、debug ip natコマンドを打ちPCでpingを打ってもNAT変換が確認できない。なぜ。。。
トラブルシューティングしたところ、ルーティングテーブル上に192.168.1.254が/24ではなく/32でローカルルートとして登録されていることに気づいた。
#ip route 192.168.1.254 255.255.255.255 g0/1
のコマンドが反映されていなかったのである。/24ではなく/32で登録されるのはおそらくパケトレ上のCiscoルータの仕様の問題だと思われる。(Catalystスイッチなら/24で登録される)
このためパケットはNAT変換される前にローカルルートとして識別され、宛先不明で破棄されていたことがわかる。
ここで下記のように修正を試みたが、ルータがadd-routeコマンドに対応しておらず入力も不可。
ルータ1
#no ip route 192.168.1.254 255.255.255.255 g0/1
#no ip nat outside source static 192.168.2.254 192.168.1.254
#ip nat outside source static 192.168.2.254 192.168.1.254 no-alias add-route
ルータ2
#no ip route 192.168.1.253 255.255.255.255 g0/1
#no ip nat outside source static 192.168.2.1 192.168.1.253
#ip nat outside source static 192.168.2.1 192.168.1.253 no-alias add-route
NAT変換後のアドレスが物理IFのアドレスだったためローカルルートと被ってしまったことから、変換後のアドレスは物理IFのアドレスとは違うものを別途用意する必要があると推測した。
※今回は172.16.0.1~3を使用
ルータ1
#ip nat inside source static 192.168.1.1 172.16.0.1
#ip nat outside source static 192.168.2.254 172.16.0.2
#ip route 172.16.0.2 255.255.255.255 g0/1
ルータ2
#ip nat inside source static 192.168.1.2 192.168.2.254
#ip nat outside source static 172.16.0.1 172.16.0.3
#ip route 172.16.0.3 255.255.255.255 g0/1
ルータ1でdebug ip natコマンドを打ちPC1でping(宛先172.16.0.2)を打つと無事に送信元・宛先どちらも変化され、疎通も成功した。
show ip nat translationsコマンドを打っても確かにNAT変換された跡が残っていることが確認できた。（今回はpingで確認したためプロトコルはicmp）
パケットの宛先・送信元の変遷を図にするとこのようになる。
結論
以上の結果から、別セグメントを経由して同セグメント間通信を実施する方法は2つあることがわかった。
１．ロンゲストマッチの法則に基づき、/24で登録されているConnectedルートよりも当てはまるビット数の多い/32のスタティックルートを追加する
⇒実環境ではかなりの数のスタティックルートを記載する必要がある。
２．Twice NATの設定を用いて送信元/宛先IPを変化させる
⇒設定が複雑なため事故の要因になる。また、結局スタティックNATとして1対1で変換アドレスの組みを用意する必要があるので、こちらも現実的ではない。
どちらを使っても面倒な設定が必要になるので結論、別拠点やサーバセグメントはおとなしく別セグメントで設計しましょうねという学び。
今回の勉強はここまで。
〜参考にしたサイト〜
・ネットワークエンジニアとして(双方向NAT)
https://www.infraexpert.com/study/natz7.html
・Cisco公式ドキュメント(NATのトラブルシューティング)
https://www.cisco.com/c/ja_jp/support/docs/ip/network-address-translation-nat/8605-13.html
・Cisco公式ドキュメント(NATの処理順序)
https://www.cisco.com/c/ja_jp/support/docs/ip/network-address-translation-nat/6209-5.html
フローティングスタティックルートについて勉強してみた
本記事の趣旨
フローティングスタティックルートが機能する場合・機能しない場合の条件をCisco Packet Tracerを用いて検証する。
特に出力インターフェースにVLANを割り当てた場合で条件分けを行い、細部の条件を確認する。
フローティングスタティックルートとは
簡単に言えばバックアップ経路みたいなもの。
スタティックルートのAD値は通常1であるが、それを2以上に設定することでメインのプライマリルートがダウンした場合のバックアップルートとしてルーティングテーブルに記載することができる。
(通常時はshow ip routeを打っても出てこず、メイン経路がダウンした時のみ現れる)
構成図
PC1-PC2間の疎通に際し、上側192.168.2.0/24を通る経路をメイン経路とし、下側192.168.3.0/24を通る経路にはAD値をつけサブ経路として設定する。
条件
①メインサブ(G1,G3)どちらもルーテッドポートにアドレスを振った場合
上側が正常時で下側はメイン経路を遮断した状況でのtracert。
メイン経路(ネクストホップ192.168.2.254)を切断した場合、サブ経路(ネクストホップ192.168.3.254)を経由して疎通可能
⇒フローティングスタティックルートとして成立
②メイン経路(G1)はルーテッドポートに、サブ経路(G3)はSVIにアドレスを振った場合
192.168.3.0/24をVLAN30とし、ルーテッドポートではなくSVIとしてCatalyst3650#1に192.168.3.1を、#2に192.168.3.254を割り振る。
こちらもサブ経路を通して疎通可能
⇒フローティングスタティックルートとして成立
③メインサブ(G1,G3)どちらもSVIにアドレスを振った場合
192.168.2.0/24をVLAN20とし、ルーテッドポートではなくSVIとしてCatalyst3650#1に192.168.2.1を、#2に192.168.2.254を割り振る。
こちらもサブ経路を通して疎通可能
⇒フローティングスタティックルートとして成立
念のためCatalyst3650#1のルーティングテーブルを見てみる。
正常時は192.168.4.0/24宛ての経路のNHは192.168.2.254になっている。
一方で、メイン経路遮断時のNHは192.168.3.254に変化しており、フローティングスタティックルートが反映されていることがわかる。
⇒物理インターフェースにVLANが紐づいていても、ダウンした物理インターフェースにのみそのVLANが割り当てられているならば問題なくフローティングスタティックルートが機能すると推測
④メインサブ(G1,G3)どちらもSVIとしてアドレスを振り、メイン経路のVLANを他のポートにも持たせた場合
メイン経路(VLAN20)を遮断してポートをダウンさせる一方で、VLAN20が別のアップしているポートに割り当てられていた場合はフローティングスタティックルートが機能するのか検証する。
イメージとしては上図の感じで、VLAN20がメイン経路のポートだけでなく、他のアップしているポート(=上のCatalystと接続しているポート)に割り当てられていてもメイン経路がダウンしたとみなされるのかを確認した。
結果、メイン経路を遮断してもNHが192.168.2.254(=VLAN20)のままであり、フローティングスタティックルートが機能していないことがわかる(=疎通できない)
結論
以上の結果から、次のことが読み取れる。
１．フローティングスタティックルートが機能するためにはAD値の低い経路(＝メイン経路)の物理インターフェースがダウンする必要がある。
２．ただしその物理インターフェースにVLANを割り当てた場合、そのVLANが割り当てられている全てのポートがダウンしている必要がある。
今回の勉強はここまで。
