システム奮闘記：その37

ヤマハルーター RTX1000設定入門

はじめに

  インターネットVPNの導入の時、ヤマハのルーター（RT105e、RTX1000）を
触る機会があった。
  そのため、ある程度は設定ファイル(コンフィグ:config)も読めるようになった。
  詳しくは「システム奮闘記：その35」(インターネットVPN導入)をご覧ください。

  だが、操作方法を覚えたのかと言われると・・・

  全く触れませーん (^^)

  だった。
  そうなのです。英文読解はできても、英作文ができないのと同じで
単語の意味は知っていても、それを組み合わせて、表現する力がないのだ。
  ヤマハルーターの設定も同じで、コマンドの意味はわかっても、
それを活用して自分が設定したい水準には達していないのだ。

  そのため、操作方法の指示書があれば、指示書通りには操作はできるが、
自分で考えて操作したり、設定変更を行うのは、全くできない状態だ。

  唯一、覚えたコマンドはshow configだ。

  だが、RTX1000の操作方法を覚えたくても、稼働しているRTX1000は、
インターネットVPNで使っていて、本社〜営業所間を結ぶ基幹部分なので、
下手に触る事ができない。

  しかし、私は技術者ではなく、タダの事務員なので

  事務員だから、触れなくて当然なのらー！！

  ということで、気にする事なく、悠長に構えていた。

ヤマハルーター・RTX1000導入の経緯

  だが、転機はいきなり訪れる。
  2005年1月の半ば、Linuxで組んだNATのマシンに異変が起こったからだ。

  7、8年前の型のパソコンで、Pentium133MHz、RAM48Mだ。
  NATとして使う分には、スペック的には全く問題はない。
  そのため、Windowsが重たくて使い物にならないので、Linuxを入れて
古いパソコンの再利用として、NATとDNSに使っていた。

  だが、1月になり、急にファンがおかしくなりだした。
  時々、ファンが止まりだしたのだ。ファンが止まると、パソコンの中に熱がこもる。

  時々、止まっては、勝手に動き出したり、ファンが止まっている事に、
私が気がついたら、つまようじを使って、軽くファンに刺激を与えると、
ファンが回り出す状態だった。

  だが、完全にファンが壊れると、CPUの熱で、CPUそのものや、
マザーボードが壊れる可能性も考えられる。
  いくらPentium133MHzの熱量が少ないからといって、バカにはできない。
  もし、故障してしまい、NATが使えなくなると、外部とのメールのやりとりや、
社内からネットの利用ができなくなる。
  うちの会社のサーバー構成は以下のようになっていた。

サーバーの構成
この構成図をご覧いただければ、DNS&NATのマシンが止まると 大変な事になるのが、わかっていただけると思う。 プライベート側とグローバル側でのデータのやりとりが止まってしまう。 そのため、外部とのメールのやりとり、社外向け検索システムが プライベート側にあるPostgreSQLサーバーへの接続不可能になったりする。 しかも、DNSが止まるので、社内と社外から名前解決ができなくなり、 通信そのものができなくなる。

  Linuxを導入した5年前は、たった一台のLinuxマシンで稼働していたのだが、
いつのまにやら、複雑な構成になっていた。

  NAT & DNSサーバーは、相当、重要な位置づけにあるのだが、
それを古いパソコンで動かしていたのだ。

  完全に、ファンが壊れるまでに、新しくサーバー用としてのパソコンの
買い替えの必要に迫られる。


  いつもなら、新規にサーバー購入としていたが、今回は違った。
  その理由は、NAT機能に、Linuxを使うのも、どうかなぁと思った。
  というのも、NATはグローバルとプライベートの間にある要所。
セキュリティー的にも強くないといけないし、何よりも安定稼働が求められる。
  ハードディスクの故障等で、動かなくなっては問題だ。

  それに、これ以上、サーバーを購入しても、置場に困る。
  結構、サーバーの置場にはスペースが必要なのだ。
  しかし、2000年にLinuxを導入した時点では、誰も、ここまで拡張されるとは
全く予想もしていなかった。

  以上の3点を踏まえた上で、考えた末、次の結論を出した。

  ヤマハのルーター（RTX1000）の採用だった！

  そして、次のような構成に変更するのを考えた。

考えたサーバー構成
NAT & DNS サーバーのあった場所に、ヤマハルーターRTX1000を設置する。 RTX1000は、VPNサーバー機能(PPTP)も持たせる事にした。 DNSだが、メールサーバーを社内向けDNSサーバーにした。 社外向けDNSだが、少し話がややこしい。 メールゲートウェイとWebサーバーも、古いマシンで、 Pentium133MHz RAM48だった。そこで、余ったVPNサーバー（Linux）を、 メールゲートウェイとWebサーバーにした。 今まで、メールゲートウェイとWebサーバーだったマシンを、 社外向けDNSサーバーにした。

  早速、ヤマハのルーターRTX1000を購入するための稟議書を書いて提出した。
  すぐに稟議が降りたので、購入の手続きを行った。


ヤマハルーター・RTX1000のコマンド学習

  1月28日、ヤマハのルーター、RTX1000が手元に届く。
  これで、自由にRTX1000が触れる。

  だが、ここで早く設定をしたいという気持ちを抑える必要がある。
  いきなり見よう見まね（設定本の丸写しとも言う）で、設定を行い、
サーバー構成の変更を行うと

  いつものようにドツボにハマる (^^;;

  2年前（2003年2月）、ISDNからADSLへ切り替えを行った際、地獄を見たからだ。
  詳しくは「システム奮闘記：その19」(ISDNからADSLへの切り替え)をご覧ください。

  設定地獄にハマり、徹夜なんぞすると、体がもたない。
  その上、安易にネットを止められない状態にある。
  ISDNからADSLへ切り替えた時ですら、4日間、ネットを止めてしまい
相当、文句を言われたのだが、今では、1日どころか半日でもネットを止めると、
えらい事になる。


  そこで、不測の事態を回避するため、RTX1000の操作の練習を行う事にした。
  その方が安全な上、色々な事を試しながら、ルーターで遊ぶ事ができる。

  RTX1000を覚える前に、DNS & NAT マシンのファンが完全に壊れる
可能性はあるのだが、しばらくは、実験サーバーで代行させれば良いと考え、
じっくり腰を据えて取り掛かる事にした。


学習に必要な項目


  まずは、うちの会社で導入する際に、RTX1000の設定を行うのに
必要な知識を、簡単に、まとめてみる事にした。

  何をどうしようか、キチンとまとめておいた方が、わかりやすいし、
項目ごとに、設定の練習もできる。

  さて、まずは、NATの設定からと考えた。
  だが、ルーティングの設定方法を知らないので、基本的な設定から
見て行く事にした。

  RS232Cケーブルを使って、パソコンからRTX1000へ接続する。
  そして、RS232C経由で設定を行う事にする。

  まずはパスワードの設定からだ。
  初期状態ではパスワードが設定されていない。
  これを行わないと、誰でもルーターに侵入できてしまうからだ。

  まずは、login passwordと打ってみたが・・・

  管理者じゃないとパスワードが変更できへん

  だった (^^;;

  LinuxやUNIXだったら、管理者でなくても、ユーザー自身が自分の
パスワードの変更ができるが、ヤマハのルーターは、管理者権限で行うという。

  そこで、administratorと打って、管理者になる。
  そして、ログインパスワードの変更ができる。
  もちろん、管理者パスワードも設定する必要があるので、
administrator passwordと打って、パスワードの変更を行う。

  さて、設定した内容を不揮発性のメモリに記録させるのには、
saveコマンドが必要だ。
  でも、打ち忘れても大丈夫。キチンとルーターが設定変更した事を覚えていて
変更内容を保存するかどうか、尋ねてくるからだ。

# exit
新しい設定を保存しますか? (Y/N)Y
セーブ中...  終了

  これだと安心だ。
  その後、設定を行う際に、saveコマンドを打ち忘れる事もあったが、
この問い合わせのお陰で設定がオシャカにならずに助かった事が何度かあった (^^)


  次に、RTX1000のファームウェアのバージョン情報を見る。
  在庫品で、古いバージョンのファームウェアが入っている可能性もある。
  show environmentコマンドで、ルーターの状態を確認する事ができる。

> show environment
RTX1000 Rev.7.01.41 (Tue Sep 28 17:02:18 2004)
  main:  RTX1000 ver=b0 serial=N0E100841 MAC-Address=00:a0:de:29:1b:26 
MAC-Address=00:a0:de:29:1b:27 MAC-Address=00:a0:de:29:1b:28
CPU:   1%(5sec)   1%(1min)   1%(5min)    メモリ: 40% used
ファームウェア: internal  設定ファイル: 0
起動時刻: 2005/01/28 11:30:18 +09:00
現在の時刻: 2005/01/28 14:01:09 +09:00
起動からの経過時間: 0日 02:30:51
セキュリティクラス レベル: 1, タイプ: ON, TELNET: OFF

2005年1月28日現在では、7.01系の最新バージョンになっている事がわかる。
他にも、CPU、メモリのリソースの状態、セキュリティーレベル、
MACアドレスが表示されている。
MACアドレスが3つあるのは、3口、別のネットワークにつなぐための
ポートがあるため、3つのMACアドレスが存在する。

  この時点でのファームウェアのバージョンアップの必要性は無しだった。
  （あくまでも、2005年1月28日の段階の話です）

  さて、次に、いよいよルーターの本格設定を行う。
  だが、いきなり設定は、失敗しても、原因が見つけにくいので、
単純な設定から行っていく事にする。

  まずは、簡単なルーターとしての設定を行う事をした。
  NATを設定する前に、ルーターとしての設定方法を知らないと、
NATの設定もできない。

ルーターの設定
社内LANの中に、練習として、ルーターの設定を行う。 ルーティングの設定方法を覚えない限り、NATの設定すらできないからだ。

  設定本を見ながら、見よう見まねで設定を行う。

ip route default gateway 192.168.1.XXX
ip lan1 address 192.168.1.200/24
ip lan2 address 192.168.200.10/24

1行目は、ルーターのデフォルトゲートウェイの設定。
2行目は、LAN1側のIPとサブネットマスクの設定。
3行目は、LAN2側のIPとサブネットマスクの設定。

  そして、実際に稼働しているかテストを行うと、問題なく通信ができていた。

  では、デフォルトゲートウェイ以外に、他のネットワークへの
ルーティングを行う場合の設定も知る必要がある。

ip route 192.168.100.0/24 gateway 192.168.1.XXX

  ふと思った。
  設定する際、誤って設定を行う場合もある。
  その時、設定内容を消す方法を知る必要もある。

  そこで、設定本を調べてみると、今まで設定した内容を
綺麗サッパリと消す方法が見つかった。

cold start

  実際に、使ってみると、綺麗に設定内容が消える。

  だが、設定した内容で、1行だけ消したい場合が、ほとんどだ。
  いつも綺麗に消すのは作業効率が良くない。

  そこで、調べてみる事にしたのだが、

  マニュアルに載ってへん (--;;

  だった。
  実際は、マニュアルにキチンと書いてあったのだが、見つけられてなかったのだ。

  だが、別の方法で調べると、なんとか見つかった。

no ip route 192.168.100.0/24 gateway 192.168.1.XXX

ip route 192.168.100.0/24 gateway 192.168.1.XXX
の設定を取り消す方法。
設定した内容の頭にnoをつける事で、設定を消す事ができる。

  これで、基本的な操作は覚えた。


NATの設定の練習


  いよいよNATの設定の練習だ。
  以下のような環境で、練習する事にした。

NATの設定の練習
いきなり、DNS & NATマシンを撤去して、置き換えるのは、 失敗の事を考えると、あまりにも危険なので 1個、使っていないグローバルIPを、RTX1000に割り当てて、 もう1つのプライベートアドレスの範囲を構築する事にした。 これだと安全にルーターの設定の練習ができる。

  上図の構成にして、失敗しても他に影響が出ない状態にして、
NATの設定を行う事にする。

NATの設定

  ルーターに付属としてついている設定事例集のNATの部分を見てみる事にした。
  だが、問題が発生した。

  どの設定事例を丸写しすれば、ええねん （ＴＴ）

  だった。

  NATと言えば、IP変換を行う事だが、私はプライベート側から外へ出る時、
プライベート側のIPからNATのIPアドレスに変換されるとばかり思っていた。
  だが、事例集を見ると、変換後のIPに他のIPをできるという。
  使いこなせると便利な半面、入門者には混乱を招く (^^;;
  
  その上、事例集の内容を見ると、純粋にNATの設定なら良いのだが、
DHCPサーバーと兼任させる設定になっていて、どれがNATの設定で、
どれがDHCP設定なのか、わからなくなる (--;;

  そのため、入門者には、とても敷居が高いと感じた。

NATの設定の練習(1)
まずは基本として、パケットがグローバル側で出る際 発信元のIPを、ルーターのIPに変換する設定を行う事にした。

  早速、お得意のマニュアルの丸写しから始める。
  だが、丸写しだとトラブルがあった場合、対処できなくなるので、
コマンドの意味も理解していこうと考えたのだが・・・

  コマンドの意味が理解できへん （ＴＴ）

  以前なら、コマンドの意味を理解できないため、理解する事を全くせずに
マニュアルを丸写しをして、ドツボにハマるパターンだった。
  しかし、今は、コマンドを理解しようとして、前に進めないパターン。

  どっちにしろ、前に進めないパターンだ。
  自分は進歩しているのかと考えると、非常に怪しい (--;;

  とりあえずは、本の丸写しを行う事にした。
  そして、設定がうまくいった時に、振り返って見て、
コマンドの意味を見ていく事にした。
  そういう方向で、コマンドの意味を理解していこうと考えた。

  とりあえず、丸写しで以下の設定をしてみた。

ip route default gateway XXX.YYY.ZZZ.RRR
ip lan1 address 192.168.1.10/24
ip lan1 nat descriptor 1
ip lan2 address XXX.YYY.ZZZ.10/24
nat descriptor type 1 masquerade
nat descriptor address outer 1 primary

  結果は・・・

  アカンかった （ＴＴ）

  ここから「動く設定」にするための模索は始まる。
  そこで、次のコマンドを入れてみる事にした。
 

# nat descriptor address inner 1 XXX.YYY.ZZZ.10 auto
エラー: IPアドレスが認識できません

  うぬぬぬ・・・ (--;;
  エラーが出るので、エラーが出ないように、次のコマンドを入れてみた。

nat descriptor address inner 1 auto

  結果は・・・

  アカンかった （ＴＴ）

  何せ、コマンドの意味を理解していないので、適当にコマンドを打ち
試行錯誤をしないといけない。

  そこで、コマンドの意味を見ていく事にした。
  まずは、nat descriptor type 1 masqueradeを見てみる事にした。
  だが、コマンド集を見ても、よく意味がわからない。
  そこで、英和辞典を取り出し、descriptorの意味を調べてみた。

  「記述、描写、説明書、解説、種類、タイプ」が載っていた。

  何の事やら理解できない。結局、この時点で、意味を理解するのを諦め
設定事例集を見ながら、とりあえず、うまくいく設定を見つける事にした。
  そして、試行錯誤の上、次の設定に辿り着いた。

ip route default gateway XXX.YYY.ZZZ.RRR
ip lan1 address 192.168.1.10/24
ip lan2 address XXX.YYY.ZZZ.10/24
ip lan2 nat descriptor 1
nat descriptor type 1 masquerade
nat descriptor address outer 1 XXX.YYY.ZZZ.10
nat descriptor address inner 1 auto

  結果は・・・

  うまくいった！  (^^)V

  だが、個々のコマンドの意味が理解できない。
  これでは、今、行っている設定が正しいのか、たまたま動いているだけなのか
区別がつかない状態だ。
  トラブルが起こった時の原因究明ができない問題が起こる。
  それに、NATを応用した設定を行う時に、コマンドを意味を理解しないと
何もできなくなる。要は、応用力がない状態のままだ (^^;;

ip route default gateway XXX.YYY.ZZZ.RRR
ip lan1 address 192.168.1.10/24
ip lan2 address XXX.YYY.ZZZ.10/24
ip lan2 nat descriptor 1
nat descriptor type 1 masquerade
nat descriptor address outer 1 XXX.YYY.ZZZ.10
nat descriptor address inner 1 auto

  まずは、青い部分と赤い部分を見ていく事にする。

ip lan2 nat descriptor 1
nat descriptor type 1 masquerade

青い部分は、NATディスクリプタ番号「1」に該当するパケットは、
「lan2」を通過する際に、パケットのIP変換を行うという意味。
NATディスクリプタ番号は、NAT識別番号とも言う。
ここから先は、NAT番号と書きます。

ピンクの部分は、NAT番号「1」のNAT方式は、静的NATと
IPマスカレード変換を行うという意味。

  NAT番号「1」が出てきたのだが、NAT番号「1」に該当するパケットが何かが
わからないと、IPアドレスの変換はできない。

  ところで、静的NATとIPマスカレードという言葉が出てきました。
  NAT識別番号を指定するコマンドでnat descriptor type 1 ****
  があるが、****の中には次の4種類が入る。

  さて、この意味の違いは何かと聞かれますと・・・

  全くわかりませーん (^^)

  と正直に答えます。

  設定していた時は、「動くねんから、どうでもええやん」と思ったが、
放置していると、その部分を突っ込まれる事は予想できる上、
トラブルが起こった際に、対処できないと困るのは私自身なので、
この原稿の編集時に調べてみる事にした。

  まずは、NATとIPマスカレードの違いを調べる事にした。
  NATとIPマスカレードの違いだが、ヤマハのルーターの場合、
次のような違いがある事が、マニュアルに書かれている。

NATとIPマスカレードの違い
NATの場合は、発信元のIP変換のみが行われる。 IPマスカレードは、発信元IPだけでなくのポート番号の変換も行われる。

  今まで、2つの違いを考えた事もなかったが、これで違いを初めて知った (^^;;
  でも、ここで疑問に思った。

  なんで、ポート番号の変換が必要やねん？

  IP変換だけで充分なのに、なぜ、ポート番号まで変える必要があるのだろうか。
  しばらく謎のままだったが、ある日、ふと頭によぎった。

  IP変換された後の発信元IPが一つのみの場合、ポート番号の変換が
必要なのではないか？
  そこで、次のケースを考えてみる事にした。

もし、IP変換しか行われない場合
プライベート側に2台のパソコン（PC1、PC2）があるとします。 2台ともグローバル側と通信を行う際、たまたま発信元ポートが 同じだったとする。NATでは、IP変換のみ行うので、 変換後の発信元IPと発信元ポートが同じになってしまう。

  上のような状態だと、大きな問題が発生する！

もし、IP変換しか行われない場合
外部から戻ってきた応答パケットなのだが、PC1への応答なのか PC2への応答なのかが、わからない。 「一体、どっちやねん」となり、混乱を招いてしまう。

  そこで、ポート変換を行う事で、この手の問題が解消できる。

ポート変換を行う事により解消される

  IPマスカレードの重要性を認識できた (^^)


  さて、NATでも、静的NATと動的NATの2種類がある。
  その違いも調べてみる事にした。

静的NATとは
変換前と後とでは、1対1の対応関係になっていて どのIPがどれに変換されるのか、わかる状態になっている。

  最後に、動的NATについて調べてみました。

動的NATとは
変換後のIPは、何種類かあるのだが、静的NATと違い、 変換前のIPとの対応関係は全くない。 要するに、空いたIPを取得して、それを変換後のIPとして使っている。

  私が、ずーとNATだと思っていたのは、実は、IPマスカレードだった (^^;;

私がNATだと思い込んでいた物

  これで、静的NAT、動的NAT、IPマスカレードの意味が理解できた。
  そして、以下の表の内容も理解できたと思った。

  これで納得した (^^)

  だが、ルンルン気分も束の間。「ちょっと待てよ」と思った。
  上の表には「静的NATと動的NATの変換を行う」と書いている。
  となれば、静的NATと動的NATは同居できるという意味なのだろうか？

  ふと、マニュアルを見ると「nat-masquerade」の所に、
「動的NAT変換できなかったパケットをIPマスカレード変換で救う。
例えば、外側アドレスが16個利用可能な場合は先勝ちで15個NAT変換され
残りはIPマスカレード変換される」

  要するに、動的NAT変換だけだと、選択できるIPが残り1個になった場合、
2台以上のパソコンから外部へアクセスしたくても、NAT変換できないため、
IPマスカレードを使って、回避（ごまかす）形になる。

  なるほど。うまい方法を考えるなぁと思った (^^)


  さて、話は設定の続きに戻します。
  残り2行のコマンドの意味を見ていく事にする。

ip route default gateway XXX.YYY.ZZZ.RRR
ip lan1 address 192.168.1.10/24
ip lan2 address XXX.YYY.ZZZ.10/24
ip lan2 nat descriptor 1
nat descriptor type 1 masquerade
nat descriptor address outer 1 XXX.YYY.ZZZ.10
nat descriptor address inner 1 auto

青い部分は、NATディスクリプタ番号が「1」に該当するパケットは、
パケットが外へ出る時、IPアドレスを「XXX.YYY.ZZZ.10」に
変換するという意味。
NATディスクリプタ番号はNATの番号と考えて良いので、
ここでは、NAT番号と省略して書きます。

赤い部分は、内部から外へ出るパケットで、全ての発信元のIPアドレスが
IPアドレス変換の対象になるという意味。
ここの部分でNAT番号「1」に該当するパケットを定義している！

  これでNATの設定の原型が完成と思ったが、「ちょっと待てよ」と思った。

  だが、この設定の場合、一つ問題がある。
  プライベート側のIPが変換される範囲だ。
  上の設定の場合、変換されるIPアドレスは、何でもOKになってしまい、
ルーターのIPアドレスに変換されてしまう。
  そこで、変換されるIPアドレスの範囲を決める方法を調べてみた。

  まずは、192.168.1.0/24 のネットワークの範囲に該当するIPアドレスが
変換される設定を行う事にした。
  そして、試しに次のコマンドを打ってみた。

nat descriptor address inner 1 192.168.1.0/24

  結果は・・・

  エラーが出た （ＴＴ）

  そこで、設定事例集を見て、次のコマンドを打ってみた。

nat descriptor address inner 1 192.168.1.0-192.168.1.255

  結果は・・・

  見事、成功！

  でも、うちの会社の場合、ネットワークの範囲は192.168.1.0/24ではく、
192.168.0.0/16なので、上の設定だと、変換できないIPが出てくる。
  そこで次の設定をしてみる事にした。

nat descriptor address inner 1 192.168.0.0-192.168.255.255

  結果は・・・

  見事、成功！

  という事で、NATの設定は、次のようになる事がわかった。

ip route default gateway XXX.YYY.ZZZ.RRR
ip lan1 address 192.168.1.10/24
ip lan2 address XXX.YYY.ZZZ.10/24
ip lan2 nat descriptor 1
nat descriptor type 1 masquerade
nat descriptor address outer 1 XXX.YYY.ZZZ.10
nat descriptor address inner 1 192.168.0.0-192.168.255.255

  NATの設定の原型ができた。
  だが、NATの設定は、これが終わりでなく、第一歩を踏み出したにすぎない。

  NATが絡む問題で、解決しないといけない問題が他にあるからだ。
  うちの会社では、グローバル側にメールゲートウェイを置き、
メールサーバーをプライベート側に置いている状態だ。
  そのため、メールゲートウェイを中継して、メールサーバーへメールが
やってくる際、どうしてもNATを通過しないといけなくなる。

  そう、内側から外側への通信するための設定はできても、
外側から特定のパケットだけを内側へ通す設定ができていないのだ！

NATの設定の練習
プライベート側に、Webサーバーを立ててみた。 そして、グローバル側から閲覧できるように設定する方法を 覚える練習する事にした。

  ここで、また、お得意の設定事例集の丸写しを行う事になる。

外部から内部へ接続する際の、IP変換の設定
tcpとudpのパケットで、接続先のポートが、Webのポートの場合 接続先のIPを「192.168.1.30」に書き換える設定。

  上の設定を、NATの設定に組み込んでみた。

ip route default gateway XXX.YYY.ZZZ.RRR
ip lan1 address 192.168.1.10/24
ip lan2 address XXX.YYY.ZZZ.10/24
ip lan2 nat descriptor 1
nat descriptor type 1 masquerade
nat descriptor address outer 1 XXX.YYY.ZZZ.10
nat descriptor address inner 1 192.168.0.0-192.168.255.255
nat descriptor masquerade static 1 1 192.168.1.30 tcp,udp www

  そして、ブラウザーから、http://XXX.YYY.ZZZ.10/を
閲覧してみる事にした。すると・・・

  見事、成功 (^^)V

  内部から外部へパケットを飛ばす際のIP変換に加えて、
外部から内部へアクセスする際の、接続先のIP変換もできるようになたので
これで、NATの部分は完成だと思いたいが、続きがあります。


  最初、NATの設定の事例集を見た時に、混乱した原因に、
内部から外部へ出る際のIP変換で、変換後のIPを必ずしも、
ルーターのIPにする必要がないと言う事だ。
  最初、その事を知らずに、設定事例集を見て、混乱してしまった (^^;;

  そこで、変換後のIPが、ルーターのIPと異なる設定をやってみようと考えた。
  次の設定を考えてみた。

NATの設定の練習

  意外に簡単だった。

ip route default gateway XXX.YYY.ZZZ.RRR
ip lan1 address 192.168.1.10/24
ip lan2 address XXX.YYY.ZZZ.10/24
ip lan2 nat descriptor 1
nat descriptor type 1 masquerade
nat descriptor address outer 1 XXX.YYY.ZZZ.20
nat descriptor address inner 1 192.168.0.0-192.168.255.255

  さて、ルーターのIPと、内部から外部へパケットが出た時に変換されるIPが
異なる場合の設定ができ、喜んだのも束の間。ふと疑問が出てきた。

  もし、内部にWebサーバーを置いた場合、グローバル側から接続すると
どのIPで接続すれば良いのかが問題になる。
  ルーターのIPなのか、外部へ出る時に変換されるIPなのか？

  結論から書きますが、外部へ出る時に変換されるIPが答えです (^^)

NATの設定の練習
もちろん、頭の中で考えた結果ではなく、上図のように練習をしました。 自分の目で確認しないと、納得できないし、仮に納得しても、 それが誤りの可能性もあるため、できるだけ、自分の目で確認したいと思う。

  さて、この設定は、以下の通りです。

ip route default gateway XXX.YYY.ZZZ.RRR
ip lan1 address 192.168.1.10/24
ip lan2 address XXX.YYY.ZZZ.10/24
ip lan2 nat descriptor 1
nat descriptor type 1 masquerade
nat descriptor address outer 1 XXX.YYY.ZZZ.20
nat descriptor address inner 1 192.168.0.0-192.168.255.255
nat descriptor masquerade static 1 1 192.168.1.30 tcp,udp www

  もちろん、最初から外部へ出る際に変換されるIPが正解とは知らなかった。
  どっちのIPで接続できるか確かめた結果、わかったのだった (^^)

  これで、NATの基本的な設定は覚えた！


  さて、ちょっとした管理コマンドを覚える。
  「システム奮闘記：その35」(インターネットVPN導入)でも、ちょこっと出てきましたが、
show status pp 1というコマンドだ。

  「pp」はインターフェイスという意味だ。
  そこで、show status lan1と、コマンドを打ってみる事にした。

# show status lan1
LAN1
説明:
イーサネットアドレス:           00:a0:de:29:1b:26
動作モード設定:                 Type (Link status)
               PORT1:           Auto Negotiation (100BASE-TX Full Duplex)
               PORT2:           Auto Negotiation (100BASE-TX Full Duplex)
               PORT3:           Auto Negotiation (Link Down)
               PORT4:           Auto Negotiation (Link Down)
最大パケット長(MTU):            1500 オクテット
プロミスキャスモード:           OFF
送信パケット:                   5543204 パケット(3718694664 オクテット)
受信パケット:                   4984326 パケット(1073400541 オクテット)
未サポートパケットの受信:       2941
受信オーバーフロー:             56
#

  コマンドを打つと「LAN1」のインターフェイスの状態が出てきた。

  通信がキチンと行われているかどうかの確認もできる。
  インターネットVPN導入の際、鹿児島でADSLのリンクが立たない問題が発生した時、
業者のSEから「show status pp 1を打ってください」
と指示されて、打った事がある。

  その時は、どういう意味のコマンドはわからなかったため、
ロボットのように、言われた通り、行ったのだが、この時、ようやく
ADSLの接続状態を見るための確認だったのが、わかった！！


ヤマハルーター・RTX1000でPPTPの設定入門

  NATの次に、とりかかったのは、PPTPの設定だったが・・・

  難しそうだ・・・ (--;;

  という事で、簡単に挫折。お得意の忍法「先送り術」で、
PPTPの設定の練習は後回しにする事にした。

  そこで、パケットフィルタリングの練習をする事にした。
  まずは、マニュアルの事例集から見てみる事にした。
  だが・・・

  フィルタリングの設定の事例集は、外部との接続の部分でしか載っていない （ＴＴ）

  つまり、社内LANで、プライベートアドレスの中での、
ルーター兼パケットフィルタリングの設定が載っていなかったのだ。

  そこで、RTX1000をADSLルーターの設定を行い、そして、
パケットフィルタリングの設定を行う方針にした。
  まさかネットを止めるわけにもいかないので、試しで触る前に、
あまり好きではない座学から入る事にした。

  pp select 1を見た。

  PPって何？

  PPが何か知りたい。調べてみると「相手先情報」だという。

  相手先情報って何？

  根本から理解していかないと、前に進まない状態だった。

  PPに関して、別のコマンドを見てみた。
  pp enable 1
  マニュアルを見たら次のように書いていた。
  「相手先を利用できる状態にする」

  うーん、わかったような、わからないような表現だ。

  禅問答を考えても時間を食うだけなので、実際の設定を見て行き、
そこからPPが何を意味するのか理解していこうと考えた。

  まずは、ADSLルーターの設定を行う部分を見て行く事にした。

  pp select 1を見てみると
相手先番号「1」を選択するだった。
  この時点では、何を意味するのか理解できなかった。

pppoe use lan2
pp auth accept chap pap
pp auth myname ID PASSWORD

  ADSLの設定の部分を見ていると、「相手先」という意味がわかってきた。

  「『相手先』とは接続する先の装置を指している」だった。

  そして「相手先」へ接続するための情報を書き込むようになっている。
  つまり、接続先の相手の情報を記述する事なので、「相手先情報」となる。

  これで納得できた (^^)V

  さて、設定事例を見ていると、下にあるパケットフィルタリングの
実例が載っていた。

パケットフィルタリングの実例
外部からやってくる icmpのパケットのみを弾き飛ばし 他のパケットを受け入れる設定。

  さて、上のを参考にして、フィルタリングの部分で、次のような説明ができる。

パケットフィルタリングの説明
外部からやってくる icmpのパケットのみを弾き飛ばし 他のパケットを受け入れる設定。

  さて、特定のパケットを弾く設定を行ってみる事にした。

パケットフィルタリングの実例と解説 (特定のWebサイトを見れなくする設定)
上の設定は、プライベート側からWebサーバーを見る時に、 Webサーバーからの全てのパケットを弾く設定を行った。 となると、応答パケットも弾かれるため、Webサーバーの コンテンツが閲覧できなくなるという設定。

  必要なパケットだけを通す設定は、よくある話なのだが、
特定のパケットだけ弾くのは、あまりした事がない。


  さて、次に設定してみたのは、プライベートからは外部へ出る事ができ、
しかも、外部からの応答パケットだけを通す設定にしてみた。

パケットフィルタリングの実例と解説
上の設定は、プライベート側から外部へはパケットを通過させて 外部からのパケットは、応答パケット（established）のみを 通過させる設定だ。

  さて、上の設定で、プライベート側から、外部にあるWebサーバーを
閲覧してみる事にしたのだが・・・

  全く閲覧できへん （ＴＴ）

  なぜ、閲覧できないのか、しばらく、考え込んでしまった。

  ふと、気づいた！
  DNSのパケットの応答がパケットフィルタリングで弾かれている事を (--;;

  応答パケット（established）の場合、ACKフラグを含んだパケットなのだが、
ACKフラグとは、TCPヘッダーのフラグであって、UDPヘッダーにはない。
  DNSのパケットは、ゾーン転送以外は、UDPパケットなので、
応答が返ってこないのだ (--;;

  でも、すぐに原因がわかり、ホッとした。

ip filter 30 pass * * established 
ip filter 31 pass * * udp domain *
ip filter 35 reject * *
ip filter 40 pass * * 
ip lan2 secure filter in 30 31 35
ip lan2 secure filter out 40

  これで、静的フィルタリングの設定方法は身についた。


  次に動的フィルタリングを行う事にした。
  さて、動的フィルターなのだが、しばらくルーターを触っていないと
どういう働きをするのか忘れてしまう。そこで復習をかねて、
自分が書いた「システム奮闘記：その18」(ヤマハルーターRTA55iの設定入門)を
見てみる事にした。

動的フィルターの働き：その1
外へ出るパケットを動的フィルターが記録する。 そして、返答で戻ってきたパケットを動的フィルターが検査。 LAN内から出たパケットの返答なら通過させる。 （注意） 返答パケットでも、一定時間が過ぎた返答が遅いパケットは破棄される。

  内部から出たパケットを記録してきて、外部からやってきたパケットが
応答パケットか、それ以外かを判断して、応答パケットだけを
通過させる事ができる。

  応答パケットとして、ACKフラグを含むパケット（established）を
通過させる方法もあるが、以下の問題があるため、お薦めできません。

ACK信号のみの場合だと・・・
（ちょっと蛇足） 「システム奮闘記：その18」(ヤマハルーターRTA55iの設定入門)を 書いた時に、自分でペイントで描いた画像。 どう見ても、悪魔でなく黒ネコだなぁ・・・ (^^;;

  悪意のあるパケットを攻撃先に送る際、ACKフラグを立てて攻撃されると
パケットフィルタリングがあっても、通過できてしまうため、
悪い奴の餌食になってしまう。


  さて、復習が終わった所で、早速、設定してみる事にした。

パケットフィルタリングの実例と解説
内部から外部へは全てのパケットを通過させ 外部からは、動的フィルターでWebのパケットのみ通過させる設定

  さて、プライベート側から外部のWebサイトを見ようとしたのだが・・・

  全く閲覧できへん （ＴＴ）

  なぜ、閲覧できないのか、しばらく、考え込んでしまった。

  ふと、気づいた！
  またもや、DNSのパケットの応答がパケットフィルタリングで弾かれている事を (--;;

  同じ過ちを2回も行うおバカな私 (--;;

  この場合、DNSのパケットに関しても、動的フィルターを適用しないと
DNSの応答パケットが返って来ないからだ (--;;

ip filter 30 reject * *
ip filter 40 pass * * 
ip filter dynamic 100 192.168.1.0/24 * www
ip filter dynamic 200 * * domain
ip lan2 secure filter in 30
ip lan2 secure filter out 40 dynamic 100 200

青い部分は、DNSのパケットに関する動的フィルターの設定。
これを入れると、DNS検索した結果（応答パケット）が通過可能になり
DNS検索ができるようになる。

  これで、ようやくWebの閲覧ができるようになった。



  次に、外部から内部のWebサーバーがある場合のフィルタリングを
行う事にしてみた。

  まずは、簡単な例で、NATが絡まない場合を考えてみた。

設定内容と方法
上の設定は、外部から内部のWebサーバーを閲覧できるように Webのパケットのみ通過させる設定。

  今までの応用なので、簡単にわかった。
  問題は、NATが絡んだ場合だ。

NATが絡んだ場合のパケットフィルタリングはどうするの?
外部から内部のWebサーバーを、Webパケットだけを通過させたい。 外部からは、ルーターのIPで接続しにいき、そこから目的のIPに変換されるため フィルタリングの設定で、接続先のIPを、ルーターのIPにすべきなのか、 接続先のサーバーのIPにすれば良いのか、迷ってしまう (^^;;

  という事で、どっちが正しいのか実験してみる事にした。
  実験の結果は・・・

  接続先サーバーのIPが正しかった！

  これで、NATが絡んだ場合のパケットフィルタリングのノウハウを得た。

  さて、パケットフィルタリングでも、静的フィルターと動的フィルターを
組み合わせて活用した方法がある。
  プライベート側にあるWebサーバーのIPを「192.168.1.30」の場合の
フィルタリングは次のようになる。

ip filter 30 reject * 192.168.1.30 established * www 
ip filter 40 pass * * 192.168.1.30 * * www 
ip filter dynamic 100 * * www
ip lan2 secure filter in 30 40 dynamic 100

  上の設定が、どういう意味を持っているのか、私自身の復習のため、
「システム奮闘記念：その18」(ヤマハルーター・RTA55iの設定入門)の図を見てみる事にした。

パケット第1弾の場合
（説明） 第1弾のパケットは静的フィルターのチェックを受ける。 この時、パケットはSYN（接続要求）のみを通る状態になっている。 通常、第1弾のパケットはSYNなので、問題なく通るが 第1弾なのに、ACKを含んだ、あやしげなパケットは破棄される。
パケット第2弾の場合
（説明） 第2弾以降のパケットは、動的フィルターがパケット検査を行う。 受信しているパケットが関連ない場合、動的フィルターは 静的フィルターに判断を委ねる。 静的フィルターがパケットの通過か破棄かを決める。

  なかなか巧妙だと感心してしまう。
  もっと感心してしまうのは、自分の記憶力のなさだ！

  最近、システム奮闘記の内容を詳しくしている理由と関連がある。
  なぜなら・・・

  自分で書いた事を簡単に忘れるから (^^;;

  よく自分自身で「あの設定、どうやったんやろ？」と思い、
自分の書いた物を、参考書にしていたりする (^^;;

  これで、一応、パケットフィルタリングの練習も終わった。

  次に、先送りしていたPPTPの設定を行う事にした。

RTX1000をPPTPサーバーにする練習
今まで、LinuxでPPTPサーバーにしていたのを、RTX1000に置き換える練習

  まずは、本の丸写しから行った。
  といっても、PPTPのコマンドの説明を読んでいきながらの丸写しなので
必要な部分だけピックアップしながら、丸写しを行った。

PPTPサーバーにする設定例
なんとか上のような設定にできました。

  さて、本当にPPTPサーバーとして機能するのか、実験を行ってみた。
  結果は・・・

  見事、成功！！

  あまりにも簡単にいったため、拍子抜けだった (^^;;

  PPTPの設定。
  「システム奮闘記：その25」(ヤマハルーターRTA55iでVPNサーバー・PPTP構築)と
「システム奮闘記：その27」(LinuxでVPNサーバー・PPTP構築)で
散々、手こずった経験がある。
  だが、今回は、PPTPがどういう通信なのかなど、頭に入っているお陰もあって、
RTX1000で設定したら、比較的、円滑に設定に終わった。実に、呆気ない・・・。

  とはいえ、多少は手こづったので、その話を書きます。

  まずは言葉の意味「バインド」からだった。
  何を意味しているのか、理解できないので、英和辞典で調べてみた。

PPTPの設定コマンドでpp bind tunnel1がある。

ヤマハのコマンドリファレンスには「相手先情報番号にバインドされる
トンネルインターフェイスの設定」と書かれているが、これだけだと
「バインドって何？」となってしまう。

そこで「bind」という英単語を辞書で調べてみる事にした。
動詞で「縛る」「結ぶ」「縛り付ける」「束ねる」「義務づける」がある。

さて、適切な訳はないかなぁと考えたら、「関連づける」が良いと思った。
「相手先情報番号に関連づけられるトンネルインタフェイスの設定」だと
すっきりした訳になったと思う (^^;;

いくら英語の流量が多いからといって、日本語に訳してもらわないと
バインドという言葉の意味がわからないだけに、言葉の部分で、
理解するのに時間がかかってしまう。

DNSのBINDは、同じ意味なのだろうかと考えたのだが、調べるのが、
めんどうなので、調査を先送りしまーす (^^)

  それと、PPTPサーバーがPPTPクライアントに割り当てるIPがある。
  そのIPの範囲を選ぶ際に注意が必要だ。

ip pp remote address pool 192.168.0.10-192.168.0.20は、
IPの範囲が「192.168.0.10〜192.168.0.20」を意味するコマンドだ。

ここで注意ですが、PPTPクライアントに割り振るIPのネットワークアドレスと
ルーターのIPアドレスが属するネットワークアドレスが同じにならない事。

PPTPクライアントに割り振るIPの範囲が「192.168.0.0〜192.168.0.255」だと
ルーターのネットワークアドレスを「192.168.0.0/24」にしない事です。
なぜ、そんな事をしてはいけないかと言うと・・・

接続がうまくできへんかった （ＴＴ）

なので、私と同じツボにハマらない事を祈ります。

  もう1点、PPTPに関しての注意点があります。

ヤマハのルーターの説明書を読めば、pp select anonymousの場合
接続中に何もしなければ、60秒で接続が切断される。
そのため、PPTP経由でtelnetを使う場合など、秒を気にしながら
操作を行う必要があるので注意が必要！

（2005年10月に追加）

  上の内容について、びぎねっとのMLで知り合いになった札幌の後藤さんから
以下のメールを頂きました。

奮闘記37、39内にて、RTX1000のPPTPについて記載があり、奮闘記39の中で、

 > ヤマハのルーターRTX1000に変更してからというもの、60秒間、通信がなければ、
 > 通信が切断されるという不便な物になった。

このように記載されておりました。
当方も１年前にRTX1000を導入し、PPTPを設定したときにハマッタ箇所でした
ので、もしお役に立てればと思いメールいたしました。
以下のようなコマンドを使う事により、60秒で切断される事はありません。

pptp tunnel disconnect time off

選択されているtunnelに対してこのコマンドを使うので、
PPTPで10カ所から同時に接続を許可するようにtunnelを10個設定していたら、
10個上記のコマンドが必要になります。


tunnel select 1
tunnel encapsulation pptp
pptp tunnel disconnect time off
tunnel enable 1
tunnel select 2
tunnel encapsulation pptp
pptp tunnel disconnect time off
tunnel enable 2
tunnel select 3
tunnel encapsulation pptp
pptp tunnel disconnect time off
tunnel enable 3
……

というような感じです。
もし良ければ、お試しください。

  そこで実際にやってみると・・・

  60秒経っても全く接続が切れへん！！

  後藤さんのおっしゃる通り、長時間でも接続ができるようになった (^^)  


  自分でも気持ち悪いほど、順調に進む。
  ここまでくれば、いつでもパケットフィルタリングの設定を行った
NATの設定が組める。
  2月11日に、休日を利用して、サーバー構成の変更を考えていたが、
まだ、時間に余裕がある。

  そこで、RTX1000を使って、ADSLルーターの設定も考えてみた。
  当初は、NAT&DNSサーバーの代用品として考えていたのだが、
次のような構成にできるのではと思った。

こんな事もできるのではないかと考えてみた
RTX1000が、ADSLルーターとNAT機能の機能統合をさせて RTA55iを取り除こうと考えた。

  上のような考えが浮かんだ事から、急遽、ADSLルーターとしての設定練習も
盛りこんだ。

RTX1000をADSLルータとしての設定の練習
ADSLルーターを、RTA55iから、RTX1000に置き換えてみる練習を 行ってみる事にした。

  どんなコンフィグの設定にしようか考えた時、ふと思った。

  RTA55iのコンフィグを見て、それを参考にして見よう！

  GUI操作なので、RTA55iではコマンド設定は行った事はないのだが、
コンフィグ表示をさせる事は可能だ。
  そして、コンフィグを見てみたら・・・

  コンフィグの内容が読めるやん！

  ここで初めて発見した。RTA55iのコマンドと、RTX1000のコマンドが
ほとんど同じである事に。
  よく考えれば、同じヤマハのルーターなので、違っていては困るのだが、
自分にとっては新鮮だった (^^)V


  さて、まずはADSL回線につなげるための設定を行う。

  まずは、PPPoEの接続に割り当てる相手先番号を「1」にしておく。
  pp selece 1コマンドを使う。

  そして、次のコマンドを入力していく。

ADSLの接続設定のコマンド
上のコマンドを見ていると、パケットフィルタリングの指定のコマンドで ふと発見した事があった。 ADSL回線へ行くパケットは、LAN2のインターフェイスを通過ため、 ip lan2 secure filter...という設定にしてしまいそうなのだが、 だが、実際には次のようになっている。 ip pp secure filter... 相手先のインターフェイス「pp」を使っている。 最初、なんで「lan2」でなく「pp」なんか、よくわからんと思っていたが、 よく考えると下図のように、ADSL回線のインターフェイス「lan2」で、 その先につながっているプロバイダーが複数の場合も設定できる。 もし、「lan2」で一括りにすると、接続形態や接続設定の内容まで 全て同じになるため、接続先別の設定が行えなくなる。 そこで、接続先別の設定を行うために、「pp」をインターフェイスにして 相手先番号を入力した後に設定を行うと、接続先別の設定ができる。

  さて、次にパケットフィルタリングの設定を行う。

ip filter 1 reject 10.0.0.0/8 * *                                 
ip filter 2 reject 172.16.0.0/12 * *
ip filter 3 reject 192.168.0.0/16 * *
ip filter 11 reject * 10.0.0.0/8 *
ip filter 12 reject * 172.16.0.0/12 *
ip filter 13 reject * 192.168.0.0/16 *
ip filter 20 reject * * tcp,udp * 135,netbios_ns-netbios_ssn,445
ip filter 21 reject * * tcp,udp 135,netbios_ns-netbios_ssn,445 *
（以下省略）

  さて、パケットフィルタリングを行う際に、PP側とLAN側の
「IN」と「OUT」の両方のパケットの行き先方向で、フィルタリングができる。

ip pp secure filter in 1 2 3 4 20 21 30 35 40 41 80 81 dynamic 50 53 54
ip pp secure filter out 11 12 13 14 20 21 100 dynamic 50 51 52 53 54 55 56

  だが、私にとっては、この「IN」と「OUT」がクセ者だ。

ルーター装置へのパケットの「IN」と「OUT」で混乱する私
ルーターでパケットの「IN」と「OUT」を見てみた場合、 「IN」は装置に入る側を意味して、「OUT」は装置の外へ出る側を意味する。 左の図が正しく、当り前と言われれば、そうなる。 しかし、どうも私の頭の中では、WAN側(PP側)を見ると 外部からパケットが来るので「IN」は、装置に入ってくる方向を意味して、 「OUT」は、WAN側へ出て行く方向を意味しているものと思い込んでしまう。 そのため、LAN側の部分で、誤解を生じてしまう。 LAN側で、LANのネットワークに入る方を「IN」と思ってしまい、 LAN側から外へ出る方を「OUT」と思ってしまうため、 実際の「IN」と「OUT」とが逆転してしまう。 今でも、時々、どっちが正しかったか迷う事がある (^^;;

  実際に、RTA55iからRTX1000に置き換えて、動かしてみた。すると・・・

  無事、成功 (^^)V

  実に、簡単に設定が終わってしまった。
  失敗談の連続が得意なだけに、スムーズにいくと気持ちが悪い。

  さて、RTX1000を使いこなす方法として、管理コマンドを見てみる事にした。
  すると、ログの取り方のコマンドを発見。

  まずは、パケットフィルタリングに引っかかったパケットを見るための
ログを取るために次のコマンドを入れる。

  syslog notice on

  そして、実際に、ログを見る時には

  show log
  
  実際にログを見てみる事にした。

Webサーバーに SYNを送らずに、ACKだけを送る奴

2005/02/08 10:23:15: PP[01] Rejected at IN(80) filter: 
TCP AAA.BBB.CCC.DDD:52620 > XXX.YYY.ZZZ.AAA:80   

Windowsの脆弱性をついた攻撃

2005/02/08 10:14:26: PP[01] Rejected at IN(20) filter: 
TCP AAA.BBB.CCC.EEE:3178 > XXX.YYY.ZZZ.AAA:445

2005/02/08 10:14:35: PP[01] Rejected at IN(20) filter: 
TCP AAA.BBB.CCC.FFF:4327 > XXX.YYY.ZZZ.AAA:135    

ログの読み方は、全く調べていなかったのだが、上のログを見て、
どういう意味なのか、すぐにわかった。

一番の上のログの意味は、フィルタリングで弾かれたパケットの情報は、
相手先番号「01」で、ルーター装置に入ってくるパケット「IN」で、
80番のフィルターで引っかかったパケットで、送信元IPとポートと、
接続先のIPとポートと、日付けと時間が記述されている。

  ここで暴露しまーす！！

  今までルーターのログを見た事がありませんでした

  そうなのです。RTA55iの時は、不正侵入者検知に引っかかったパケットは
GUI操作で簡単に見れたのだが、パケットフィルタリングで引っかかったパケットは
見た事がなかったのだ！！

  「そんな事で、ええんかい！」と突っ込みがきそうなので反論します。

  だって、事務員だもーん (^^)

  RTA55iで、ログの取り方も知らなかった上、ログの見方も知らなかった。
  だが、今回、ログの見方を知る事ができた。一歩成長したのらー (^^)V


  ここで2点ほど、だいぶ後になって、わかった事を書きます。
  時系列の流れに沿って、書ければ理想なのだけど、編集の困難さで
読みやすさと、時系列に忠実とが相反する場合が出てくる。

  まず、1点目は、ログにも3種類ある事だった。

  「DEBUGレベル」が何かですが、通常、使わない物だという。
  そのため「事務員なので、通常、使わないものは絶対使わない」と
堂々と言い切って、調べる手間を省く事にしまーす (^^;;


  もう1点は、RTX1000で、不正侵入者検知を行う設定だった。
  3月後半になり、設定方法を知ったので、その方法を紹介します。

ip pp intrusion detection in on reject=on

  不正侵入者検知の結果を見てみると

> show ip intrusion detection pp 1 in

PP[01][in] Action: reject
 2005/03/22 20:19:07: ICMP too large         AAA.BBB.CCC.DDD > XXX.YYY.ZZZ.RRR
 2005/03/22 21:27:28: ICMP too large         AAA.BBB.CCC.DDD > XXX.YYY.ZZZ.RRR
 2005/03/23 10:17:54: TCP port scan          AAA.BBB.CCC.DDD > XXX.YYY.ZZZ.RRR
 2005/03/23 10:29:36: TCP port scan          AAA.BBB.CCC.DDD > XXX.YYY.ZZZ.RRR
 2005/03/23 21:08:44: ICMP too large         AAA.BBB.CCC.DDD > XXX.YYY.ZZZ.RRR
 2005/03/24 09:08:04: TCP port scan          AAA.BBB.CCC.DDD > XXX.YYY.ZZZ.RRR
 2005/03/24 14:20:34: TCP port scan          AAA.BBB.CCC.DDD > XXX.YYY.ZZZ.RRR
 2005/03/25 11:55:03: ICMP too large         AAA.BBB.CCC.DDD > XXX.YYY.ZZZ.RRR
 2005/03/25 12:50:31: TCP port scan          AAA.BBB.CCC.DDD > XXX.YYY.ZZZ.RRR
 2005/03/25 13:41:25: TCP SYN flooding       AAA.BBB.CCC.DDD > XXX.YYY.ZZZ.RRR

  結構、不正侵入を企む不届き者がいると思った。


  さて、話はRTX1000でログの設定ができた時点に戻します。
  ログの設定ができたので、ルンルン気分だった。

  ふと思った。RTA55iでもログを採取できるのでは。
そこで、一度、RTX1000からRTA55iに戻す事にした。

  今度は、RTA55iをGUI操作ではなく、telnetを使って、コマンド操作で
RTX1000と同じようにログの設定を行い、ログを採取してみた。
  すると、凄い物を見る事ができた。

  ポート135とポート445への凄まじいアタック攻撃だ！

  2つともWindowsの脆弱性を狙ったもので、1つはRPCへの攻撃。
  もう1つは、Direct Hosting of SMBと呼ばれる物への攻撃だ。

  もし、Windows+IISでサーバーを立ち上げていたら、ポート135への
攻撃の餌食になっていたかもしれない。
  IISはソフトの依存性でRPCがないと動かないためだ。

  反ＭＳの私は「だから、Windowsサーバーは危険！」と煽ってみたくなる。
  しかし、ルーターやサーバーでパケットフィルタリングすれば済む話なので
煽ってみても効果がないのだ (^^;;

  これで全て予定していた練習が無事、終わった。


  2月11日、いよいよLinuxで構築したDNS&NATサーバーからRTX1000に
切り替え作業を行う事になった。
  とりあえずは、構成は以下の図のようにする事にした。

当初、予定していたサーバー構成

  比較的、順調に作業が進んだ。

  全てがうまくいったかに見えたが、ちょっとした問題も発生した。

  顧客向けの検索システムが動くかどうかの確認を行った。
  何せ、グローバルエリアにあるWebサーバーから、プライベート側にある
PostgreSQLのデータベースサーバーにアクセスさせているため、
パケットフィルタリングで、必要なパケットとして通過させているが、
それの確認作業だった。

サーバーの状況

  だが、データベースの検索ができへん （ＴＴ）

  原因を調べるため、ログを見ていたら、パケットフィルタリングで
パケットが弾かれていた。

ip filter 45 reject XXX.YYY.ZZZ.AAA 192.168.AAA.BBB established * 5432
ip filter 46 pass XXX.YYY.ZZZ.AAA 192.168.AAA.BBB tcp * 5432

やってくるパケットで、最初の1つ目が悪意のあるACK信号を含む
パケットの場合があり得るので、そのパケットを弾くために
ここには載せてはいないが、動的フィルターも使って、
静的フィルターは、SYN信号のパケットのみ通過させる事にした。

しかし、フィルター番号(45)で、データベースへ接続をするための
パケットが弾かれ、接続ができない事がわかった。

  なんで、接続できへんねんと思い、設定の強度を少し緩和して、
Webサーバーから、データベースサーバーへのアクセスは
全てのパケットで許可する設定にした。

ip filter 46 pass XXX.YYY.ZZZ.AAA 192.168.AAA.BBB tcp * 5432

  結果は・・・。

  見事、成功した！

　なぜ動的フィルターを使って、正しい設定を行っても
データベースへの接続に関して、うまくいかなかったのかは
腑に落ちないのだが、他は問題なく設定が終了した。


  これで、当初の予定が終了した。だが、私の挑戦は終わらない。

  RTA55iの撤去も行えるはずだと考えていたのだった。
  以下のサーバー構成だってできると考えていた。

私の挑戦するサーバー構成

  この構成は練習ができないため、ぶっつけ本番となる。
  もし、トラブルが起こっても、当初、考えていた構成に戻せば良い話だし
うまくいけば、RTA55iを撤去できる。

  ぶっつけ本番とはいえ、いきなり作業は無謀なので、
数日前から、どういう設定になるのか、シミュレーションを行っていた。

  まずは、どこに何をつなげるのかを考えた。

ルーターの差し込み口と接続先ネットワーク
LAN1側の口が4つある事から、グローバルIPを割り振った サーバー等をつなげる事にした。 LAN2側には、プライベートIPのネットワークにつなげた。 LAN3側には、ADSL回線へつなげる事にした。

  次に、どこでIP変換を行おうかと考えた。

IP変換を行う際の設定
プライベート側から外部へ出るパケットと、グローバルIPを割り振った 社内ネットワークへ行くパケットは、発信元IPを変換する事にした。 実際には、社内のネットワーク同士の通信であれば、 別にプライベート側からグローバルIPを割り振ったネットワークへ パケットを送る際に、IP変換は必要ないのだが、私の頭には グローバルIPエリアと通信するには、IP変換は絶対必要があったため IP変換を行う事にした。 これがトラブルの元とは、この時は思っていなかった。

  さて、2重にIP変換(?)の設定を行うため、次の設定を考えた。

ip lan3 nat descriptor 1
nat descriptor type 1 masquerade
nat descriptor address outer 1 XXX.YYY.ZZZ.RRR
nat descriptor address inner 1 192.168.0.0-192.168.255.255
nat descriptor masquerade static 1 1 192.168.KKK.AAA tcp 1723
nat descriptor masquerade static 1 2 192.168.KKK.AAA gre

ip lan1 nat descriptor 2
nat descriptor type 2 masquerade
nat descriptor address outer 2 XXX.YYY.ZZZ.RRR
nat descriptor address inner 2 192.168.0.0-192.168.255.255
nat descriptor masquerade static 2 1 192.168.QQQ.CCC tcp smtp
nat descriptor masquerade static 2 2 192.168.QQQ.DDD tcp 5432

実は、ここでも間違いを犯している事が、後になりわかった。
ip lan3 nat descriptor 1の部分だが、
ADSL回線側への接続なので、本来なら、次のような設定になる。

select pp 1
ip pp nat descriptor 1

「pp」としないといけない部分が「lan3」となっているためだ。
もちろん、「pp」を指定する前に相手先番号を入れる必要があるので
「select pp 1」を入れました。

  NATの設定も大丈夫だと考え、早速、RTA55iが撤去できる構成に挑戦した。

  さて、恐る恐る外部のWebサイトを見てみると

  見事、成功 (^^)V

  そして、会社のアドレスから、私の携帯へメールを飛ばしてみたら

  見事、届いた (^^)V

  これで気を良くして、無事、構成変更が完了と思っていたのだが、
とんでもない事が発覚したのだ。

  この日、私と同様に休日出勤していた同僚が「ネットつながらへんで」と
言ってきた。
  「なんでやねん」と思いながら、見てみると、本当につながらない。

  自分の机のパソコンのWebの設定を見ると、実験的に、
グローバル側のサーバーをプロキシーにして外部に接続しているので、
その設定を外して、直接、外部のサイトにつなげてみると・・・

  ホンマにつながらへん （ＴＴ）

  異変はメールにも起こっていた。
  私の携帯から私の会社のアドレスへメールを送ったのだが、
全く届いていないのだ。

  色々、調べてみると次の事がわかった。

  一番最後の部分は、まともに外部の危ないパケットを通してしまう
危険性があるので、テストを行わなかった。

  さぁ、どうしようかと悩んでしまった (--;;

  ここから毎度の如く、試行錯誤が始まる。

  もしかして、複雑に作ったパケットフィルタリングが原因だと考え、
ADSL回線の出入口以外は、全てパケットを素通りさせる事にした。

ADSL回線の出入口以外は、全てパケットを素通りさせる事にした

  結果は・・・

  アカンかった （ＴＴ）

  諦めずに考えてみる事にした。
  IP変換を2ヶ所で行うから不具合が生じると考えた私は、
プライベート側の出入口でIP変換の設定を行う事にした。

プライベート側の出入口でIP変換の設定を行う事にした

  以下のようなコマンドを使った。

ip lan2 nat descriptor 1
nat descriptor type 1 masquerade
nat descriptor address outer 1 XXX.YYY.ZZZ.RRR
nat descriptor address inner 1 192.168.0.0-192.168.255.255

この設定を今、見ていると、プライベート側に入るパケットに対して
IP変換を行おうとしているため、動くわけがない。

自分の行動ながら理解に苦しむのだが、この時は必死だったので、
設定の怪しさに全く気づいていなかった。

  結果は・・・

  どこにも接続できへん （ＴＴ）

  状況は悪化してしまった (--;;
  でも、諦めの悪い私は、悪アガキのため、設定事例集を見る事にした。

  次のような設定例がある事を知った。

IP変換を行う際の設定
プライベート側から外部に出る時のみ、IP変換を行う事になった。

  NATの設定を行うインターフェイスを、ADSLの出入口だけにした。

ip lan3 nat descriptor 1
nat descriptor type 1 masquerade
nat descriptor address outer 1 XXX.YYY.ZZZ.RRR
nat descriptor address inner 1 192.168.0.0-192.168.255.255

  早速、これで試してみたのだが・・・

  やっぱりアカンかった （ＴＴ）

  ここまでくると、何が悪いのか全く見当がつかない。
  もしかしたら、RTX1000では技術的にはできない設定かもしれない。
  そう思うと、無理に設定しようという気はなくなってしまう。

  そして、当初、予定していたサーバー構成に戻した。
  目標には達しなかったけど、最低限の事はできたので、満足だった。

  事務員なので、それで良いのらー！！ (^^)V


  そして、2週間くらいは、問題なくサーバー構成ができた事で
満足していたのだったが、やはり欲求不満が起こる。

  私が挑戦しようとした事が技術的に可能なのかどうかだけでも知りたくなる。

  可能だったと言われても、私の技術が未熟なため、できないのであれば、
それでも良いし、技術的に不可能であれば、それでも良い。
  要するに、技術的に設定が可能かどうか知りたくなった。

  そこで、ヤマハのサポートセンターに電話をかけて聞いてみた。

  サポートセンターの人は「可能です」と答えた。

  技術的に可能だという事がわかった。
  となれば、何がなんでも設定したい衝動が起こる。

  そこで、厚かましいお願いとして、サポートセンターに
私のコンフィグの間違えている点があれば、教えてくださいと
コンフィグの添削を依頼した。

  すると快く引き受けてくださるので、早速、コンフィグを送った。

  ヤマハから添削された結果が戻ってきた。
  早速、見てみると、NATの設定に問題があるという事だった。

  プライベート側から外部に出る時のみ、IP変換を行い、グローバルIPの
ネットワークへパケットを送る際は、IP変換を行わないという。

IP変換を行う際の設定
プライベート側から外部に出る時のみ、IP変換を行う事になった。

  次に、NATのインターフェイスの指定だった。

（訂正前）
ip lan3 nat descriptor 1

（訂正後）
ip pp nat descriptor 1

  これで、私が挑戦しようとしている事が可能になるかもしれない。
  だが、日中、ネットを止めて設定を行うのは困難だ。

  3月19日、休日出勤の予定が入っていたので、その日に再度、
挑戦する事にした。


  運命の3月19日。再度、設定を行った。
  最初は、ADSL回線への出入口以外は、パケットを素通りさせた。

  結果は、成功だった！ (^^)

  だが、いつまでも素通りさせるわけにはいかない。
  そこで、パケットフィルタリングの設定を行う。
  この日を迎える前に、「あーでもない、こーでもない」と考えながら
設定準備を行った。
  何せ、3方向に出入口があるため、それぞれにフィルターの設定を行うため
頭の中が混乱しそうになる。まるでパズルのような感じだ！

  プライベート側にパケットの出入りを厳しく制限したい。
  そこで、プライベート側(LAN2側)にも動的フィルターを活用して、
プライベート側から他のネットワークへ出るパケットを通過&追跡させ
それの応答パケットのみを受け入れるような設定を行った。  

フィルタリングの状態
ADSLの出入口部分にも動的フィルターがついているので、 もしかしたら、両方に動的フィルターを設定すると、 動かなくなるのか、それとも、負荷がかかりすぎるのかと心配した。

  この場合のコンフィグの設定ですが

ip filter 1 reject 10.0.0.0/8 * *                                 
ip filter 2 reject 172.16.0.0/12 * *
ip filter 11 reject * 10.0.0.0/8 *
ip filter 12 reject * 172.16.0.0/12 *
ip filter 20 reject * * tcp,udp * 135,netbios_ns-netbios_ssn,445
ip filter 21 reject * * tcp,udp 135,netbios_ns-netbios_ssn,445 *
ip filter 100 pass * *
ip filter dynamic 1000 * * www
ip filter dynamic 1001 * * telnet
ip filter dynamic 1002 * * ftp
ip filter dynamic 1003 * * smtp
ip filter dynamic 1004 * * domain
ip filter dynamic 1005 * * tcp                                  
ip filter dynamic 1006 * * udp
ip lan2 secure filter in 1 2 11 12 20 21 100 dynamic 1000 1001 1002 1003 1004 1005 1006

  早速、動かしてみる事にした。

  結果は成功だった！

  2ヶ所以上の出入口に動的フィルターを設定しても、うまく動く事がわかった。
  その他のパケットフィルタリングの設定を行って行く事にした。

  プライベート側から外部へ問題なく設定できる。
  心配していた他のパケットフィルタリングの設定も問題なかった。

  ただ、社内のグローバルIPのエリアには、IP変換しないのが
ちょっと違和感があるのだが、慣れれば済む事だと思った。

  そして、RTA55iは、2年間のルーターの役目を終え、撤去した。
  といっても、RTX1000が壊れた時に予備として使うために置いている。


(2005年6月20日追加)

  パケットフィルタリングだが、フィルタリングとルーティングに気をつけないと
思わぬトラブルを起こす事がある。

  そこで2005年6月に起こった、営業所でDNS検索ができないトラブルを紹介します。
  まずは、本社の社内向けDNSとインターネットVPNのためのルーターの
デフォルトゲートウェイを説明します。

デフォルトゲートウェイの状態
インターネットVPNのルーターのデフォルトゲートウェイは、 NATに使っているRTX1000にしている。 社内向けDNSサーバーのデフォルトゲートウェイは、 VPNルーターに使っているRTX1000にしていた。 なぜ、デフォルトゲートウェイをVPNルーターにしていた理由だが 特に、理由はなかった。フレームリレー回線だった時代に 社内のパソコンのデフォルトゲートウェイが、フレームリレー回線の ルーターがデフォルトゲートウェイだったため、その発想で何も考えずに、 VPNルーターを社内のパソコンのデフォルトゲートウェイにしていた。

  だが、ひょんな事で、社内向けDNSサーバーのデフォルトゲートウェイを
変更する事があった。

変更後のデフォルトゲートウェイの状態
インターネットVPNのルーターのデフォルトゲートウェイは、 NATに使っているRTX1000にしている。 社内向けDNSサーバーのデフォルトゲートウェイを NATルーターに使っているRTX1000にしていた。

  すると営業所から「メールが見れない」とか「ホームページが見れない」
といった報告が入ってきた。
  私は「なぜ?」と思ったが、すぐにピンときた。
  もしかして、営業所でDNS検索ができないのでは？

  VNCを使って営業所のパソコンを遠隔操作を行い、営業所から
ping www.kek.jpを行った。

  案の定、DNS検索ができないため、パケットの応答がなかった。
  すぐに、社内向けDNSサーバーのルーティングを元に戻したら、
DNS検索ができるようになった。

  だが、これだと解決とは言えない。
  単なる対処療法であって原因を究明する必要がある。

  そこで頭の中で、デフォルトゲートウェイを変更した際の
パケットの順路を考えてみる事にした。

デフォルトゲートウェイの変更後のパケットの順路
上のような順路になるのは間違いない。 そのため、どこでトラブルが起こっているのか、わからない。

  そこで再現実験を行って原因究明に乗り出す事にした。
  原因究明をしておかないと、今後、同じようなトラブルが再発しかねないからだ。

  前もって営業所に、1時間、メールとインターネットが使えない事を伝える。
  そして、実験台に岡山営業所を選んだ。  

  さて、実験開始。
  まずは、DNSサーバーでDNSのパケット採取を行い、DNSサーバーへの
問い合わせパケットを受信しているのか、DNSサーバーが応答パケットを
発信しているのか確認する事にした。
  tcpdump -S port domain

  岡山営業所のパソコンをVNCで遠隔操作を行い、神戸大学のサーバーへ
ping www.kobe-u.ac.jpを行った。
  ちなみに、神戸大学にしたのは、単に自宅のご近所さんで
ping の応答をしてくれる所を選んだ。ミエを張って「神戸大学出身」
と書きたいが、私は神戸大学へ行ける程、頭は良くなかったのらー (^^)

  さて、DNSサーバーで採取したデータを見てみる事にした。

17:15:19.934860 192.168.X.Y.1111 > dns.xxx.co.jp.domain:  1+ A? www.kobe-u.ac.jp. (34)
17:15:19.936081 dns.xxx.co.jp.domain > 192.168.X.Y.1111:  1 1/4/0 A www.kobe-u.ac.jp (150) (DF)
17:15:19.936286 dns.xxx.co.jp.domain > 192.168.X.Y.1111:  1 1/4/0 A www.kobe-u.ac.jp (150) (DF)
17:15:25.435459 192.168.X.Y.1111 > dns.xxx.co.jp.domain:  1+ A? www.kobe-u.ac.jp. (34)
17:15:25.436684 dns.xxx.co.jp.domain > 192.168.X.Y.1111:  1 1/4/0 A www.kobe-u.ac.jp (150) (DF)
17:15:25.436890 dns.xxx.co.jp.domain > 192.168.X.Y.1111:  1 1/4/0 A www.kobe-u.ac.jp (150) (DF)
17:15:36.022104 192.168.X.Y.1111 > dns.xxx.co.jp.domain:  1+ A? www.kobe-u.ac.jp. (34)
17:15:36.023273 dns.xxx.co.jp.domain > 192.168.X.Y.1111:  1 1/4/0 A www.kobe-u.ac.jp (150) (DF)
17:15:36.023477 dns.xxx.co.jp.domain > 192.168.X.Y.1111:  1 1/4/0 A www.kobe-u.ac.jp (150) (DF)
17:15:51.523481 192.168.X.Y.1111 > dns.xxx.co.jp.domain:  1+ A? www.kobe-u.ac.jp. (34)
17:15:51.524742 dns.xxx.co.jp.domain > 192.168.X.Y.1111:  1 1/4/0 A www.kobe-u.ac.jp (150) (DF)
17:15:51.524949 dns.xxx.co.jp.domain > 192.168.X.Y.1111:  1 1/4/0 A www.kobe-u.ac.jp (150) (DF)
17:16:12.028981 192.168.X.Y.1112 > dns.xxx.co.jp.domain:  2+ A? www.kobe-u.ac.jp.dns.xxx.co.jp. (52)
17:16:17.538296 192.168.X.Y.1112 > dns.xxx.co.jp.domain:  2+ A? www.kobe-u.ac.jp.dns.xxx.co.jp. (52)
17:16:28.110329 192.168.X.Y.1112 > dns.xxx.co.jp.domain:  2+ A? www.kobe-u.ac.jp.dns.xxx.co.jp. (52)
17:16:43.612547 192.168.X.Y.1112 > dns.xxx.co.jp.domain:  2+ A? www.kobe-u.ac.jp.dns.xxx.co.jp. (52)

192.168.X.Yは岡山営業所のIPアドレス
dns.xxx.co.jpは社内向けDNSサーバーのアドレス。

これを見る限り、DNSの問い合わせのパケットは受信している上、
応答パケットもキチンと返している。

だが応答パケットが岡山営業所のクライアントへ届いていないため
何度も再送している形になっている。
ついには、「www.koube-u.ac.jp」がホスト名ではないかと勘違いをして
ピンクのように、神戸大学のアドレスの後ろに、うちの会社のドメインをつけて
問い合わせを行う始末だ

  一体、どこが悪いのだろうか？
  DNSサーバーはキチンと受信して応答を返している。
  ふと思った。パケットの順路を辿れば、NATにしているRTX1000で
DNSサーバーからの応答パケットが詰まっている可能性があるのでは？

DNSからの応答パケットが詰まっている場所
上のような順路になるのは間違いない。 そのため、どこでトラブルが起こっているのか、わからない。

  そこで、NAT利用しているRTX1000のルーターのログを見てみる事にした。
  すると意外な結果が出てきた。

2005/06/13 17:21:02: LAN2 Rejected at OUT(default) filter: UDP 192.168.A.B:53 > 192.168.K.W:1052 (DNS response)
2005/06/13 17:21:14: LAN2 Rejected at OUT(default) filter: UDP 192.168.A.B:53 > 192.168.B.X:1299 (DNS response)
2005/06/13 17:21:16: LAN2 Rejected at OUT(default) filter: UDP 192.168.A.B:53 > 192.168.C.H:1693 (DNS response)
2005/06/13 17:21:17: LAN2 Rejected at OUT(default) filter: UDP 192.168.A.B:53 > 192.168.X.Y:1116 (DNS response)

192.168.A.Bは社内向けDNSサーバーのIP
192.168.X.Yは、岡山営業所のIP

ログを見ていると岡山営業所への応答パケットだけでなく、
全国の営業所へ送るDNSの応答パケットを全て破棄している。

  これでルーターに原因がある事がわかった。
  単にパケットを同じLAN2の内部のネットワークへ転送するだけでも、
パケットフィルタリングに引っかかる事がわかった！

  そこでルーターのパケットフィルタリングを見てみる事にした。

ip filter 1 reject 10.0.0.0/8 * *                                 
ip filter 2 reject 172.16.0.0/12 * *
ip filter 11 reject * 10.0.0.0/8 *
ip filter 12 reject * 172.16.0.0/12 *
ip filter 20 reject * * tcp,udp * 135,netbios_ns-netbios_ssn,445
ip filter 21 reject * * tcp,udp 135,netbios_ns-netbios_ssn,445 *
(途中、秘密事項なので省略)
ip filter 100 pass * *
ip filter dynamic 1000 * * www
ip filter dynamic 1001 * * telnet
ip filter dynamic 1002 * * ftp
ip filter dynamic 1003 * * smtp
ip filter dynamic 1004 * * domain
ip filter dynamic 1005 * * tcp                                  
ip filter dynamic 1006 * * udp
ip lan2 secure filter in 1 2 11 12 20 21 100 dynamic 1000 1001 1002 1003 1004 1005 1006
ip lan2 secure filter out 1 2 11 12 14 20 21 30 42 43 45 46 47 dynamic 1003 1005 1006

INの部分(ルーターに入る部分)は、IPスプーフィングの問題なるIPと
NBTのパケットを除く全てのパケットを受け入れしている。

OUTの部分(社内LAN内に入る部分)は、動的フィルターに反応したパケットと
諸事情で隠しているパケットのみ通過させている。

  上の設定を見ると、LAN2側(社内LAN側)からルーターへ入るパケットは
全て通過させ、かつ動的フィルターをつけている。
  ルーターから社内LAN側に出るパケットは、動的フィルターに記録された
応答パケットと諸事情で通過させているパケットのみだ。
  ログを見た限り、ルーターから社内LANへ出る際に、フィルターに
ひっかかった状態になっている。

  ここまでは、わかったが、まだ真相解明までは至っていない。

  何度か実験を行いたいのだが、DNSを頻繁に止めるのは営業所に
迷惑をかけてしまう。業務にも支障が出るので、他の方法を考えた。


  そこで、社内に実験的なWebサーバーを立ち上げ、そのサーバーの
デフォルトゲートウェイをNATで利用しているRTX1000にして、
営業所からWebコンテンツが閲覧できるかどうか確かめる事にした。
  これだと業務には支障が出ない。

Webの実験サーバーを立ち上げて実験を行う
今回のトラブルは、UDPとTCPの違いによるフィルタリングの問題でないため DNSの代わりにWebサーバーにしても、何ら問題はない。

  もちろんパケットの順路はDNSの時と同じだ。

パケットの順路
今回のトラブルは、UDPとTCPの違いによるフィルタリングの問題でないため DNSの代わりにWebサーバーにしても、何ら問題はない。

  早速、営業所からWebサーバーへコンテンツの閲覧をしてみたら

  予想通り、見られへん！！

  やはり、これもNATで使っているRTX1000のルーターが原因と考えられる。

Webが見れない原因

  そこで、私の予想があっているか確かめるために、NATのRTX100のルーターの
ログを見てみる事にした。

2005/06/14 10:10:46: LAN2 Rejected at OUT(default) filter: TCP 192.168.1.Q:80 > 192.168.X.Y:1049
2005/06/14 10:10:52: LAN2 Rejected at OUT(default) filter: TCP 192.168.1.Q:80 > 192.168.X.Y:1049

  やはりルーターでパケットが破棄されているのが、よくわかる。

  そこで次のような事を頭で思い浮かべてみた。

パケットの順路
同じ口を使う場合でも、他のネットワークへパケットを転送させる時は フィルターを通過するのではないかと考えた。

  だが、上の図のような思い描いた図式では矛盾すると考えた。
  なぜなら、INの場合(パケットがルーター内に入る時)、全てのパケットを通過させ
動的フィルターで監視させているため、OUT(ルータの外へ出る時)は、
動的フィルターが関知して、記録されているパケットと照し合せるため
問題なく通過できるはず。

  （注意！）
  この時、上のような発想をしたのだが、それは誤りだった。
  なぜなら、動的フィルターが関知して通過させるパケットは
  外部のサーバーへ飛ばしたパケットの応答を関知させる物であって
  パケットの転送なので、応答パケットとはいえないからだ。


  さて、勘違いの想像をしたのだが、この勘違いに気づいたのは
実験結果が出てからだった (^^;;

  さて、転送パケットの場合は、次のようなフィルターがかかると思った。

私が思い描いた物
同じ口から入り、同じ口へ出て行く転送パケットの場合は OUT側のパケットフィルタリングだけのチェックが入ると考えた。

  そこで、Webサーバーから営業所への応答パケットが、OUT側のフィルターを
通過できるように、以下の設定を行った。

ip lan2 secure filter out 1 2 11 12 14 20 21 30 42 43 45 46 47 50 dynamic 1003 1005 1006
ip filter 50 pass-log 192.168.1.0/24 192.168.X.0/24 tcp * *

青は本社のネットワークアドレスとサブネットマスク。
赤はWeb閲覧の実験を行っている営業所のネットワークアドレスとサブネットマスク。

そして、確認のためパケットが通過した場合は、ログに残す設定をしておいた。

  これで営業所でWebが見れるはず。そして実験の結果・・・

  見事に閲覧できた (^^)V

2005/06/14 10:20:12: LAN2 Passed at OUT(50) filter: TCP 192.168.1.Q:80 > 192.168.X.Y:1051

  どうやら、OUT側だけのフィルターが影響しているみたいだ。
  だが、それをキチンと立証しないといけない。

  そこで、Webサーバーからの応答パケットがIN側のフィルターを通過すると
仮定した上で、ルーターに、次の設定を行った。

ip lan2 secure filter in 1 2 4 11 12 20 21 51 100 dynamic 1000 1001 1002 1003 1004 1005 1006
ip lan2 secure filter out 1 2 11 12 14 20 21 30 42 43 45 46 47 50 dynamic 1003 1005 1006

ip filter 50 pass-log 192.168.1.0/24 192.168.X.0/24 tcp * *
ip filter 51 reject 192.168.1.0/24 192.168.X.0/24 tcp * *


ip lan2 secure filter out 1 2 11 12 14 20 21 30 42 43 45 46 47 50 dynamic 1003 1005 1006
ip filter 50 pass-log 192.168.1.0/24 192.168.X.0/24 tcp * *

青い部分は本社のネットワークアドレスとサブネットマスク。
赤い部分はWeb閲覧の実験を行っている岡山営業所のネットワークアドレスと
サブネットマスク。

そして、確認のためパケットが通過した場合は、ログに残す設定をしておいた。

  さて、岡山営業所からWebで実験サーバーを閲覧してみると

  Webが見られへん (^^;;

  予想を外してしまった。
  さて、ルーターのログを見る事にした。

2005/06/20 11:32:58: LAN2 Rejected at IN(51) filter: TCP 192.168.1.Q:80 > 192.168.X.Y:1058
2005/06/20 11:33:00: LAN2 Rejected at IN(51) filter: TCP 192.168.1.Q:80 > 192.168.X.Y:1058

  ルーターに入るINでも、転送パケットはフィルタリングされているのがわかる。
  つまり最初に考えていた下図の仕組みになっているのだ。

転送パケットもINとOUTのフィルタリングの対象

  ところで、よく考えると、最初から通過パケットのログをとれば
「動作検証」と称して、INとOUTのフィルターを開いたり閉じたりするような
大袈裟(?)な事をしなくても良かったはず (^^;;


  さて、INとOUTで、Webのパケットが通過した跡をキャッチしてみる事にした。

ip lan2 secure filter in 1 2 4 11 12 20 21 51 100 dynamic 1000 1001 1002 1003 1004 1005 1006
ip lan2 secure filter out 1 2 11 12 14 20 21 30 42 43 45 46 47 50 dynamic 1003 1005 1006

ip filter 50 pass-log 192.168.1.0/24 192.168.X.0/24 tcp * *
ip filter 51 pass-log 192.168.1.0/24 192.168.X.0/24 tcp * *

青い部分は本社のネットワークアドレスとサブネットマスク。
赤い部分はWeb閲覧の実験を行っている岡山営業所のネットワークアドレスと
サブネットマスク。

そして、確認のためパケットが通過した場合は、ログに残す設定をしておいた。

  結果は以下の通りになりました。

2005/06/20 11:36:34: LAN2 Passed at IN(51) filter: TCP 192.168.1.Q:80 > 192.168.X.Y:1060
2005/06/20 11:36:34: LAN2 Passed at OUT(50) filter: TCP 192.168.1.Q:80 > 192.168.X.Y:1060

  結論として、同じ口を出入りする転送パケットであっても、
パケットフィルタリングの対象になる上、動的フィルターの監視は受けない。
  そのため、社内のルーティングとRTX1000のフィルタリングを考えないと
通信ができなくなるトラブルに陥るので注意してくださいね (^^)


まとめ

  インターネットVPNの導入時に、多少、RTX1000を触りましたが、
まさか、別の用途でRTX1000を導入して、自分で設定を行うとは
全く予想もしていませんでした。

  WebのGUI操作ではなく、コマンド操作だったため、使い勝手に不安を
感じましたが、慣れれば、そうでもなくなりました。
  まぁ、最初はコマンドが打つのが面倒&覚えるのが手間ですが (^^;;

  GUIとコマンドでは、どっちが良いかとなれば、一長一短だと感じました。
  GUIですと、手軽で、コマンドを覚える必要はないのですが、
細かい設定や、色々な事を試すには、コマンド操作の方がしやすいと思いました。

  両方あれば最高という感じです (^^)V