我が家におけるRTX-3000の位置づけ

我が家では、RTX-3000を環境内に組み込んでいますが、その役割として主な所は以下のようなものです。

• 災対ネットワークを接続するVPNルーター
• Mastodon本番インスタンスの窓口
• IHANetとHomenocを結合する境界
• インターネットゲートウェイ副系統

今回取り組もうとしているのは、4番目に書いたインターネットゲートウェイ副系統として機能する際に、主系統であるSophos UTM9と同等のインターネット経路を持たせることです。

現状の構成

現状の構成は下図のとおりです。

現状では、主系統であるSophos UTM9は2つのインターネット経路に接続されています。ここから、ポリシールートにより、クライアントセグメントからのWebアクセスに限りInterlinkを通じて外に出られるよう構成しています。

しかしながら、副系統であるRTX-3000はHomenoc向け経路しか存在していないため、例えば経路が副系統に切り替わった際、UTM9でやろうとしたことができないことになります。

この構成にしたのは理由があって、HomenocはNGNを通じてEtherIPを構成し、インターネットへ抜けるようになっているのですが、例えばNGN側のPrefixに変更が発生した場合や、それに合わせてPeerの張り直しが必要な場合に、Webだけは外に抜けられるようにする非常回線的な役割があります。

また、妻のノートPCはIPv6を使用しない構成にしており、常にInterlink側でアクセスするよう差し向けることで、仮に仮想基盤が全滅した場合などに、最低限のアクセス経路が担保できるようにと考えたというのもあります。

Homenoc経路はこれまで安定していることは確かなんですが、あくまで彼らは「実験用ネットワーク」としてこちらに提供してくださっていることもあるので、そういう点に配慮した・・と言うところになります。それでも、まだDHCPやDNS/NTPがきちんとそれに準拠できてないので、可用性があるかというと実はないんですけども。まぁまぁ、手始めの第一歩という感じです。

変更方針

下図のように構成を変更します。

流れとしては以下のような感じです。

• Interlinkに接続しているRouterboardのPort6を使用します。
  • RB2011-UiASではPort1-5がGbE、Port6-10が100BASE-TXで構成されています。対向のRTX-3000のLAN3ポートが100BASE-TXですので、コレに合わせてPort6を使用します。
  • DMZブリッジがPort3で構成されているんですが、これに新たにPort6を追加します。
• RTX-3000のLAN3ポートを使用します。
  • LAN3ポートにIPアドレスを割り当てます。
  • デフォルトゲートウェイの設定にポリシールートを加えます。
    • クライアントセグメントからの80,443ポートアクセスに対して、Interlink経路を使用するよう構成します。
    • 当該経路が途絶した場合は、デフォルトゲートウェイから外す(hidden)ようにします。
    • それ以外のアクセスは従来のHomenoc外接経路を使用します。

Routerboardのブリッジ追加はGUIで簡単にできることから、本記事ではRTX-3000側で実施した内容を記載します。

LAN3に対するIPアドレス追加

ip lan3 address 10.5.1.3/24

ポリシールートの構成

ip filter 4001 pass 192.168.220.0/24 * * *
ip route default gateway 10.5.1.1 filter 4001 hide gateway 103.***.***.142

一旦この状態でRouterboardのPort6とRTX-3000のLAN3を接続します。

OSPF設定の追加

自宅環境の内部ネットワーク経路は基本的にOSPFで回しています。Interlink DMZに対する経路はエリアを分けており、内部ネットワークはarea backbone、DMZはarea 0.0.0.5にて構成しています。

今回、LAN3インタフェースを用いてRTX-3000がInterlink-DMZセグメントに接続されているので、経路交換をするためにエリアの追加、インタフェースの追加を行います。

RTX-3000側で以下の設定を行います。

ospf area 0.0.0.5
ip lan3 ospf area 0.0.0.5
ospf configure refresh

エリアの設定をミスったりすると、OSPFがdisabledとなり、経路を喪失してしまうので注意が必要です。私の場合、エリアの定義をせずにLAN3インタフェースに対するエリアの指定だけ行った状態で「ospf configure refresh」を実行したため、「エリア0.0.0.5がないやんけ！OSPFやめるで！」と叱られ、経路喪失したりしました。こういうところの確認って大事ですね。

動作確認

まず、Interlink-DMZに対する経路ができたかどうかを確認(関連する所以外は省略しています)。

show ip route

default 10.5.1.1 LAN3 static filter:4001
default 103.***.***.142 LAN2 static
10.5.1.0/24 10.5.1.3 LAN3 implicit
10.242.2.0/24 10.5.1.2 LAN3 OSPF E2 cost=1 metric=10
 :
 (以下略)

デフォルトゲートウェイの設定が2つあることが確認できると思います。filterルール4001番に該当する通信はRouterboardである10.5.1.1へ行くようになります。それ以外は従来のゲートウェイを通ります。また、OSPFでUTM9に対する経路が配られていることを確認しました。

OSPFネイバーについても確認します。

show status ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
192.168.100.3 1 2WAY/DROTHER 00:00:37 192.168.100.3 LAN1/1
192.168.100.4 1 FULL/DR 00:00:33 192.168.100.4 LAN1/1
192.168.220.254 1 FULL/BDR 00:00:31 192.168.100.254 LAN1/1
10.5.1.1 1 FULL/BDR 00:00:38 10.5.1.1 LAN3
192.168.100.4 1 FULL/DR 00:00:33 10.5.1.2 LAN3

末尾2行にInterlink-DMZセグメントである10.5.1.0/24に対するOSPFネイバーが追加されたことを確認しました。

動作確認

実際に通信してみて想定経路を通っているかどうかを、インターネットゲートウェイを切り替えた上で確認します。まずはサーバセグメントにあるログサーバから疎通を確認してみます。途中経路を見ればわかるように、Homenocを通過しています。

[root@brahma ~]# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1 192.168.100.254 (192.168.100.254) 2.688 ms 2.782 ms 2.921 ms
 2 yomogi.bluecore.net (192.168.100.1) 0.356 ms 0.329 ms 0.300 ms
 3 * * *
 4 v104.xe-0-0-1.pop52er01.bb.homenoc.ad.jp (103.247.181.5) 17.446 ms 17.559 ms 17.483 ms
 5 133.208.55.65 (133.208.55.65) 18.482 ms 18.496 ms 18.470 ms
 6 133.208.193.136 (133.208.193.136) 18.332 ms 18.824 ms 133.208.193.200 (133.208.193.200) 18.822 ms
 7 74.125.48.110 (74.125.48.110) 18.161 ms 17.794 ms 17.181 ms
 8 108.170.243.33 (108.170.243.33) 17.348 ms 108.170.243.129 (108.170.243.129) 17.581 ms 108.170.243.33 (108.170.243.33) 17.363 ms
 9 216.239.40.93 (216.239.40.93) 17.438 ms 66.249.94.213 (66.249.94.213) 17.428 ms 108.177.3.81 (108.177.3.81) 17.914 ms
10 google-public-dns-a.google.com (8.8.8.8) 17.791 ms 17.844 ms 17.786 ms

次にクライアントセグメントにあるDNS/NTPサーバから疎通を確認してみます。Interlinkの経路を通過していることがわかります。

[root@kome ~]# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1 gateway (192.168.220.254) 1.436 ms 1.532 ms 1.645 ms
 2 yomogi.bluecore.net (192.168.100.1) 0.158 ms 0.116 ms 0.158 ms
 3 10.5.1.1 (10.5.1.1) 0.394 ms 0.415 ms 0.412 ms
 4 nas81g-3.p-fukuoka.nttpc.ne.jp (153.152.222.63) 8.992 ms 8.947 ms 8.897 ms
 5 153.152.223.169 (153.152.223.169) 9.076 ms 9.142 ms 9.118 ms
 6 153.152.223.29 (153.152.223.29) 24.343 ms 24.222 ms 24.311 ms
 7 e9-6-n-otemachi-core13.sphere.ad.jp (210.153.241.197) 24.026 ms 23.992 ms 23.967 ms
 8 e1-4-n-otemachi-core18.sphere.ad.jp (202.239.114.194) 24.875 ms e10-3-n-otemachi-core18.sphere.ad.jp (203.138.68.214) 24.065 ms e9-7-n-otemachi-core18.sphere.ad.jp (202.239.113.10) 23.895 ms
 9 72.14.202.229 (72.14.202.229) 24.308 ms 24.809 ms 24.752 ms
10 108.170.242.161 (108.170.242.161) 24.641 ms * *
11 209.85.143.47 (209.85.143.47) 25.373 ms 209.85.245.77 (209.85.245.77) 26.434 ms 209.85.143.49 (209.85.143.49) 24.662 ms
12 google-public-dns-a.google.com (8.8.8.8) 25.563 ms 25.338 ms 25.432 ms

というわけで、どうやらなんとかやりたい事はできたみたいです。

学べど学べど難しい

今回、OSPFについてだいぶ調べました。RIPなんかもそうですけど、何となく設定はできても、その中でどういう用語が有り、どういう挙動が有り、あるべき姿ってなんなのかってのがやはり学んでも学んでも理解が至りません・・・

DR/BDR/DROTHERとか、ABR/ASBRとかそうした用語、LSAのやり取りなどについてはそれなりに理解が進んだんですが、実は今この自宅環境若干OSPF周りの問題を抱えてまして。UTM9のデフォルトゲートウェイにおいて、OSPF配信された経路がスタティックルートに勝ってしまっているという。別途ポリシールートを構成することで暫定的には対応できたんですが、ここらへんのトラブルシュートに対する理解が進んでないなぁ・・・と。自身の力の足りなさを痛感しきりです。

これからもこのあたりの勉強はゆるゆる継続しようと思います・・

余談

最近近所の図書館の自習室環境が結構いい感じなので、そこに通ってリモートで自宅環境弄りをやってます。昨日なんかはL3スイッチを設定ミスで二度とログインできないスイッチにしちゃったりといろいろ有り、急遽自宅に返って現地作業・・・みたいな感じになりましたが、ふつーの机と椅子があって、広く場所取ってノート広げたり出来るのが良いねぇ・・・・とか思ったりで。

電源は使用禁止なので、バッテリー頼みなんですが、まぁ幸いにも今使ってるノートPCのバッテリーがそれなりにもつんで、だいぶその中で色々やってます。Pythonの勉強なんかは実際にペンでメモ取りながらやらないと頭に入らないので、そういう意味では非常に助かる環境だなーとおもってます。

喫煙所は外にあるので、それが寒くて辛いんだけどね・・・・でもまぁ、それでも近いから良しとしようそうしよう。