システム奮闘記：その35
(2005年1月25日に掲載)
はじめに
うちの会社の基幹業務は、AS/400を基幹業務で使っている。
どの営業所からでも、AS/400やメール・インターネットの利用ができるように
全拠点をフレームリレー回線を使って結んでいる。
| うちの会社のネットワーク |
|---|
 |
フレームリレー回線の速度は64kなのだが、最低保証帯域であるCIR値は
「0」という細い回線を使っている。
一番安いプランなのだが、それでも全国13ヶ所の営業所を結んでいるため、
通信費用はバカにならない (--;;
以前から上層部から「通信費削減」というお達しが来ていた。
だが、何度も色々な通信事業者から見積もりをとってはいるが、
どこも似たり寄ったりだった。
例え、現状より安いプランが出ても、設備投資の回収が2年以上かかるなど、
通信事業者の価格差は微々たるものだった。
なぜ、フレームリレー回線に、こだわるかといえば、AS/400のパケットは
SNAプロトコルで飛ばしていた。
他の通信方法に変えると、SNAのパケットをカプセリングするための装置が
必要になるため、初期コストが高くなる。
SNAにこだわる理由は、次の2つの理由があった。
| SNAに、こだわっていた理由 |
|---|
| (1) |
元々、AS/400の導入時の通信プロトコルはSNAを使っていた。
現在の機種を購入時に、TCP/IPが実装されたばかりで
購入先のJ社は「SNAが無難」と勧めていた。
不安定な動きをされては困るため、TCP/IPへの変更に踏み切れなかった
当時、私は関与していなかっただけに、詳しい事情は知らない (^^;;
|
| (2) |
セキュリティーの問題。
SNAだと外部からの侵入はされないが、TCP/IPだと、その可能性がある。
絶対安全というのが保証されないため、TCP/IPへの変更に踏み切れなかった
|
何せ、基幹業務に使っているAS/400にクラッキングという事態になれば
極秘情報の漏洩という事で、SNAからTCP/IPへの切り替えに社内は及び腰だった。
逆に言えば、SNAの状態にしておけば、完璧だと思い込んでいたのだ。
だが、少しづつ変化が見られるようになった。
色々な業者から、フレームリレー回線の見積もりを取る際に、業者の話を聞くと
「SNAでやっているのは、今は少ない」とか、AS/400を購入したＪ社からも
「今や、TCP/IPが主流になりつつあります」と言い始めた。
そのため、社内の考え方も「TCP/IPでも良い」に変わってきた。
そこで出てくるのが、インターネットVPNへの切り替えという発想だった。
| インターネットVPN回線 |
|---|
 |
VPN装置を使って、通信データを暗号化する。
それによってデータの盗聴を防ぎ、インターネット上を安全に
通信を行なうという仕組み
|
さて、2002年の秋に、初めてVPNの見積もりをとる機会があった。
AS/400を購入したJ社の方が「安くて回線速度の速いプランを提案します」と
言ってきたからだった。
早速、上司と私が話を聞く事にした。
話を聞くと、VPNを使った通信の話だった。
インターネットVPNは、帯域保証がないため、危険だという。
そこで、帯域保証のある閉じたネットワークのIP-VPNの提案だったのだが・・・
なんと、フレームリレー回線より高い金額だった！！
フレームリレー回線の倍近い、通信費用がかかる見積もりだったので、
当然、却下になる。
上司と私は「確か、J社の人は、うちのフレームリレー回線の費用を
知っているはずなのに」と首を傾げた。私も同感だった。
この時、社内ではVPNは高いという印象を持ってしまった。
実はこの時、私は、インターネットVPNと、IP-VPN方式の違いは
全くわかっていなかった。
そのため、VPNを使うと回線費用は高くなると思い込んでしまったのだった (^^;;
AS/400がTCP/IPで通信を行うと不安になる可能性が捨て切れないため、
障害が出るのを防ぐ意味もあり、引続き、現状より安いフレームリレーを
探す事になった。
折しも、通信事業者間の競争は激しいため、売り込みの電話がかかってくる。
何社か見積もりを依頼する事にした。
通常、見積もりを出してもらう時は、現在の費用を伏せておく。
なぜなら、相手が、その金額よりも少し安い金額を提示するのを防ぐため。
相手の金額に対して「今の方が安い」といって、揺さぶりをかける。
でも、相手が提示できる金額がギリギリの線なのは、わかっているので、
そういう手は使っても、あまり成果は期待できない。
そこで、ワルな私はカマをかける。現状の通信費用を数万円くらい安く偽って言う。
だが、相手の業者もギリギリの金額よりも安くはできないため
「この金額には、かなわない」で諦める (--;;
これ以上の安い回線は期待できない。
ところで、2002年の半ばくらいから、費用面以外で問題が発生しだした。
社内間でやりとりするデータ量が増加してきた事だった。
通達の文書や、図面などの画像データが本社から営業所へ送られるのだが、
エクセルで作成した文章に、デジカメで撮った画像を使って送る人が増えてきた。
何も考えずに、デジカメで撮った画像を大量に送る人まで出てきた。
営業所からは・・・
メールをダウンロードするのに
メチャクチャ時間がかかる
という苦情がやってくるようになった。
私は「回線を太くしたいけど、これ以上の回線増強は費用が上げるので
稟議が通らないですわ」と答える以外、どうしようもなかった。
大量のデータを営業所に送るのは、本社でCD-Rに焼いて、
運送便で営業所へ送る事をしていたが、急ぎの場合は、とても対応できない。
ある日、急ぎで本社から営業所へ動画データを送ろうと、800Mの動画データを
メールで送った人がいた。営業所は、本社のサーバーからダウンロードするため、
とても遅い上、営業所のパソコンはメールのダウンロード中に固まってしまった。
高速データ通信が必要になってくると、嫌でも実感させれてしまう (--;;
全く身動きがとれないまま、ズルズルと月日が過ぎていった。
2003年11月、大手家電メーカで通信事業から保険業まで手を出している
S社から電話があった。通信回線の売り込みだった。
早速、話を聞く事になった。回線費用は安くなりそうな見込みだったが、
私が営業マンの態度にムカついたので、ご破算にした。
| こんな営業マンはやめてくれー! |
|---|
どこの会社の営業マンでも良い人、悪い奴はいる。
この時、やってきたS社の営業マンは、私の相当嫌いなタイプだった。
「安いので早く買うように」という感じで迫ってきた。
その上、グループウェア─を売り込んできたので、私が「今は必要ないですね
過去に導入したけど、うまくいかなかったですし」と言うと、営業マンは
いかにも「使えないのは程度が低い」と言わんばかりに、バカにした態度で
「使い方が悪いのでは」と言ってきたり、「これを使えば、必ず使う」など
グループウェア─の押し売りを始めた。
押し売りでかつ、見下した態度をとる営業マンは、胸クソ悪い。
その上、延々と売り込みの話を聞かされ、うんざりした。
こんな営業マンはやめてくれーと思った (--;;
|
まぁ、安くなる事がわかれば、腹の立つ営業マンの相手をするよりも
他の通信業者で契約すれば良い事。別の業者を探す事にした。
しばらくして、東京支店の部長から電話があった。
菅ちゃん、頼むわ。なんとかしてくれや
この間、メールを取り込むのに、40分ぐらいかかったで!
という悲痛とも言える叫び声だった。
だが、私にはどうする事もできない。
上司が私に「東京支店のメールの問題を解決するには、東京支店が
独自でADSLに入ってもらうしかないのか」と言ってきたので、
私は「それしかないですねぇ」と答えた。
ふと、私は考えた。
どうせADSLを引くなら、VPNを導入して高速データ通信をすれば、
それに越した事はない。
いきなり全営業所の回線をVPNに変えるのではなく、まずは試験的に
本社と東京支店との回線をVPNを導入して様子を見て、支障がなく使えるのが
確かめられたら、必要性の高い営業所から段階的にVPNに切り替える。
しかし、2002年の時に、J社に出してもらった見積もりで「VPNは高い」が頭にある。
そんな折、ADSL回線を導入した時、お世話になったＮ社のH子さんから
「通信関係で、お困りの事がありませんか」というメールがやってきた。
そこで、ダメ元で、N社のH子さんに問い合わせる事にした。
| H子さんへ書いたメール |
|---|
> 御社では最近通信の関係で何かお困りのことなどは
> ありませんでしょうか。
最近、ちょっとした話が出ています。
実は、本社と営業所の間の回線をVPNなどに切り替えて
回線増強と費用削減ができないかと考えています。
まだ、具体的に全く動いていませんので、いつどうなるのか
わかりませんが、もし、導入の方向になりましたら、
H子さんに連絡しますので、その時は、よろしくお願いいたします。
|
早速、H子さんから電話がかかってきて「今度、VPNを紹介に行きます」と
言ってきたので、話を聞く事にした。
H子さんがやってくる前に、本社と東京支店とを結ぶネットワークを
どんなネットワーク構成にするのか、案を考える事にした。
そこで考えたのが、以下の2つの方法だった。
| 接続形態:その1 |
|---|
 |
ただ、上の方法だと、厄介な所にNATがあるため、NAT越えの設定が
難しいと考えられる。そこで、下の図の設定も考えた。
| 接続形態:その2 |
|---|
 |
本社側のNAT越えの設定が手間がかかると考えて
本社のLANに穴を開けて、そこと、東京支店との間を結ぶ方式
|
これだとネットワークの構築はしやすくなる。
この2つの案をN社のH子さんに渡そうと考えた。
さて、H子さんがやってきた。
私が「こういう構成を考えている」と2つの案を示した。
H子さんは「両拠点に、フレッツADSLを使えば、安くできますね」と言った。
そして、H子さんは電卓を叩いて、だいたいの回線費用を弾き出した。
この時、H子さんは全営業所を、フレッツADSLを使って、インターネットVPNで
結んだ場合の金額を出したのだった。
そして、H子さんは「これだと、今までの半額でいけそうです」と言った。
私も「これだと、全営業所に導入する話を進めやすくなる」と言った。
H子さんが「全営業所での見積もりを出します」と言ったので、
私は、見積もりを、お願いをした。
| こういう営業マン(ウーマン)は好感が持てる |
|---|
私は、H子さんに対して良い営業ウーマンとして好感を持っている。
なぜなら、正直な上、提案はしても、押し付ける事はしない。
グループウェアの話になった時、ITの先端を行く通信会社といえども、
使いたがらない人がいる話、入力項目が多くて面倒な話などを聞くと、
正直に問題点を挙げているなぁと思うと同時に、信用できると思う。
雑談をしながら、商談をしていると1時間くらい経つが、
時間が過ぎるのを忘れるくらいだ。
経費削減のため、無条件にH子さんに仕事を依頼する事はできないが、
できる事なら、H子さんに仕事を回してあげたいという気になる。
ふと思う。ユーザーは、口八丁手八丁で売り込む営業マンに注意すべきだ。
きらびやかな部分だけしか見せない営業マンは、己れの営業成績だけ考えて
顧客の事を考えていない事を見抜くべきだ。
その製品の良い面、悪い面を正直に挙げてくれる営業マンこそ、
顧客を重視している営業マンとして、大事にする必要があると思う。
ユーザーの目がしっかりしない限り、悪い営業マンは減らないと思う。
|
H子さんは25才くらいの女性だというのは、うちの会社では知られている。
ADSL導入時の際、H子さんを見た事のあるパソコン好きの部長が
「菅くんは、かわいい、おねーちゃんを見て、鼻の下を伸ばしながら
ADSLの契約をした」と広めたためだった。
ADSL導入については「システム奮闘記：その19」をご覧ください。
(回線切り換えトラブル ISDNからADSLに切り換え)
こんな会話が出る始末だった。
| こんな会話がありました |
|---|
| 顧問 |
菅くんはやり手やで。商談と言いながら
その子の携帯や家族構成まで聞き出すからなぁ
|
| 私 |
そこまでやり手でしたら
今頃、女の子にモテモテですよ。
|
| 上司 |
N社に頼んで、担当変えてもらわないと、
菅くんが、鼻の下を伸ばして、商談しなくなるから
|
| 私 |
そりゃ、ないですよ |
閑話休題。ここで暴露。
実は、この時、私は、フレッツADSLに関して、凄く誤解している事が、
相当、あとになってからわかった。
普段なら、あとで誤解していた話を書く所だが、今回は先に、
どんな誤解をしていたかについて書く事にしました。
でないと、この先、私が起こす行動が、読者の方にとって理解できないからだ。
| フレッツADSLでの接続形態 |
|---|
 |
フレッツ網を使う場合、電話局から契約したプロバイダーまでの区間は
上図のように、NTT東西が所有している「地域IP網」を使っている。
(私が誤解していた事)
私はフレッツ網は、ルーターから電話局までの部分だと誤解していた上
地域IP網の事をADSL回線の部分だと思い込んでいた。
H子さんが「足回りはフレッツ網」と言っていたのだが、
私は足回りの事を「電話局までの回線」だと思い込んでいた。
実際は、NTT東西が所有している「地域IP網」の事を指している。
帯域保証だが、地域IP網がベストエフォートのため、帯域保証がないのだが、
この時、誤解していた事があった。それは帯域保証がない事に関してだが、
地域IP網に問題があるのに、私は「ADSLの速度が電話局までの距離に大きく依存し、
しかも、ISDNの雑音などに通信速度が変わるため、帯域保証がない」
と思い込んでいた (^^;;
しかも、電話局から直接、N社のネットワークに、つながっていると
思い込んでいた。
そのため、上のような構成だと、N社だけのネットワークで通信が完結する
インターネットを介さない「疑似IP-VPN」ができあがりと思い、
帯域は確保できると考えた。
今思えば、凄い誤解だったのだが、その誤解のお陰(?)で、
大胆にも、インターネットVPNを推進できたと思う。
|
私が、以上の事を誤解していたのを踏まえていただければ、
今後、展開される話の内容が理解しやすいかと思います。
さて、回線はN社に依頼する事にして、AS/400の設定変更。
各パソコンにインストールされているAS/400のエミュレーター（P-COMM）の
変更作業などは、AS/400を購入したJ社に依頼しないとできないので、
設定変更する場合の費用の見積もりを出してもらう事にした。
だが、J社は見積もりを出すのを渋った。
J社の営業の人に「インターネットVPNは、通信の品質保証がないため
トラブルが起こります」と止めに入った。
この時点では、まだ、導入するかどうか決めていなかったので、
無理に押し通す事もないだろうと思い、見積もりをとらなかった。
VPN方式(IPSecかPPTP)を決める
さて、VPNの導入の際に決めないといけない事がある。
VPNの暗号化には2種類あるのだが、どちらを選ぶかの問題だ。
1つはPPTP方式。もう1つはIP-Sec方式がある。
本にはIPSeCの方がセキュリティー的に安全と書いている
こんな文章を見ると、PPTPに対して不安を持ってしまう。
そこで、実際にPPTPでも大丈夫なのか確かめるために、
びぎねっとのMLに聞いてみる事にした。
| まいパパさんのお返事 |
|---|
今年の6月号のSoftware DesignにPPTPで構築するVPNサーバー
の記事を書きましたが、PPTPだとアカウントとパスワードがばれて
しまうと成りすましを防げないので確かにセキュリティ的に不安は
あります。
ですが、運用次第（定期的にパスワードを変更する等）では十分に
使用に耐えうると考えます。
# 実際に私はそうしています。
|
このお返事を見て安心した私は、PPTPを使おうと思った。
PPTPの方が手軽な感じがする。
だが、実際には、IPSeCを採用した。その理由は後述しています。
能見さんからの次の助言を頂いた。
| 能見さんからの助言 |
|---|
VPNを構築する場合の要点を記載します。
１．業務系のみの接続（内部）とインターネットへの接続（外部）を切り分ける。
２．内部、外部への接続は箱物を使用する。
３．内部系は自社内のセンター接続をスタティク接続にする。（外部からは見え
ない様にする。）これは外部からの危険を回避するためです。
そして、一番重要なのは回線の帯域保証を行っているプロバダーと契約するです。
業務を中心考えるとこの様な点です。
|
能見さんからの助言を読んで、私が考えていた2つ接続形態のうち、
下図の形態を選ぶ事にした。
能見さんからの助言を基に
以下の通信形態を選ぶ事にした |
|---|
 |
これだと、外部(インターネット)への接続と、
内部(各営業所)への接続をわける事ができる。
(注意)
実際に採用したのはインターネットVPNですが
この時は、両側の拠点が同じプロバイダー契約すれば
上図のような通信網になると想像していました。
|
これで、ネットワークの構成は決まった。
これだと、NAT越えの問題を考えずに済む。
それに「疑似IP-VPN構築」と誤解している私は、ベストエフォートでも
大丈夫だと思い込んでいた。
VPN入門 通信形態と仕組み
さてさて、年末に近づいてきた。
この頃、上司に「菅ちゃん、モバイルを使って、俺のノートパソコンから
会社へ接続して、メール見れるようにしてくれへんか？」と言われた。
丁度、インターネットVPNとは別に、営業マンがモバイルで外部から社内へ
アクセスできるようにする話が出ていた。
そこで、VPNが、どんな物なのか、実際に自分の目で確かめる事ができる。
そこで、とりあえず、自宅から会社のメールサーバーへ
VPNでアクセスできるようにして、VPNが何なのかを体験する事にした。
| VPNの設定実験 |
|---|
 |
上図のように、自宅から会社に接続実験を試みる事にした。
ここでも毎度の如く、ルーター（RTA55i）の設定に手こずった。
何度か、ヤマハのサポートセンターに電話をして、試行錯誤しながら
設定を行っていった。
そして、七転八倒の末、1月の半ばに接続ができるようになった。
詳しくは「システム奮闘記：その25」をご覧ください。
(PPTP方式 ヤマハルーターRTA55iでVPN接続)
自宅から会社へ接続してメールの読み書きができるようになったのは凄く便利だ。
だが、これで満足できたわけではなかった。
VPNを使って、社内のパソコンの共有フォルダーからファイルや画像を取ったり
または、自宅で作成したファイルを、会社のパソコンに置いたりできたら便利だ。
それに、社内LANにアクセスできれば、帯域保証がない回線でも、
AS/400のエミュレーターが動くかどうかが確認できる。
そこで、以下の図のような環境を設定する必要があった。
| VPNで社内LANに接続 |
|---|
 |
この作業、カーネルの再構築や暗号化のパッチを当てたりなどがあり
なかなか思うように進まなかった。
しかし、七転八倒の末、2月末には、LAN内にVPNサーバーを構築した。
詳しくは「システム奮闘記：その27」をご覧ください。
(VPN通信 LinuxでPPTPサーバー構築)
帯域保証がないと、よく回線が切れたりする物だと思っていたが、
そんな事はなかった。社内LANにアクセスして、社内の端末の共有フォルダーから
ファイルをダウンロードしたり、アップロードが問題なくできたりする。
「これだと帯域保証がなくても、AS/400のエミュレーターが問題なく使えるのでは」
と思いはじめたが、この時はまだ、確固たる自信はなかった。
「これはいける！」と思うようになったのは、4月になってからだった。
AS/400は無理としても、会社のLAN内へ自由に接続できるため
便利になった事もある。
自宅へデータの持ち帰る際、フロッピーディスクしか手段がなかった。
もちろん、運べるデータなんて大した量ではない。
だが、VPNのお陰で数メガ単位のデータでも自宅へ転送できる。
PPTPとIPSecの仕組み
さて、VPNの事を調べ出すと、もっと詳しく知りたくなった。
そこで「最新VPNハンドブック」（伊藤幸夫、紫藤政義、野口修：秀和システム）
を読んでVPNについて勉強する事にした。
本を開いて読んでいくと、VPNには2種類の接続形態がある事を知った。
| IP-VPN |
|---|
 |
1つの通信事業者が持っている回線（広域IP網）を利用して
2つの拠点を結ぶ方法。閉じた通信回線内で仮想専用線という形になる。
通信事業者によって提供されるもので、サービスや価格はまちまち。
|
この上の場合、通信業者内のネットワークしかパケットが通らないため、
安全性が高いと言われている。
安全性といえば、データの盗聴になるが、データそのものが暗号化されている。
ここでの安全性は通信の品質の事を意味している。
もし、片方が違う通信事業者の場合、相互間の接続部分がネックになったりする。
そのため、IP-VPNの利点は、利用回線が同じ通信業者内のため、
その業者が責任を持って通信の品質を保とうとする事ができるのだ。
IP-VPN以外には、インターネットVPNと言われるものがある。
| インターネットVPN |
|---|
 |
|
安価で構築できる方法だが、帯域保証がない。
|
うちの会社は、インターネットVPNの導入という事になるのだが、
この時点では、インターネットVPNにしているとは思っていなかった。
なぜなら、N社の閉じたネットワークで通信が完結していると
思い込んでいたためだった (^^;;
さて、VPNの暗号方式には、PPTP方式と、IPSeC方式の2種類ある。
最初、私は、PPTP方式の方が簡単だと考えていたが、IPSeC方式も
どんな物か知るために調べてみる事にした。
| PPTPとIPSeCの違い |
|---|
 |
PPTPの場合、データリンク層で暗号化を行っているが
IPSeCの場合、ネットワーク層で暗号化を行っている。
|
PPTP方式は、ダイヤルアップのPPPプロトコルを拡張してできた方式だ。
詳しくは「システム奮闘記：その25」をご覧ください。
(ヤマハルーターRTA55iでPPTPサーバー構築)
さて、IPSeCの場合、第3層（ネットワーク層）で、暗号化される。
暗号化方法は、パケットカプセリングで、送信するデータに
ヘッダーをつける方法だ。
IPSeCの通信方法には2種類ある。
トランスポートモードと、トンネルモードだ。
| トランスポートモードと、トンネルモードの違い |
|---|
 |
トランスポートモードとは、端末間でのIPSeCを使った通信。
トンネルモードは、ルーターなどの経路途中の装置を使ったIPSeC。
トンネルモードの場合、IPSeC装置間だけデータが暗号化される。
|
今回は、ルーターを使ったIPSeC通信（トンネルモード）を使うので、
トランスポートに関しては、ここで軽く触れるだけにします。
さて、IPSeCで暗号化と書いたが、実は、暗号化しないIPSeCも存在する。
暗号化するしないは、IPSeC化の際の、ヘッダーの種類で決まる。
| IPSeCの種類 |
|---|
| AHヘッダー |
データの暗号化を行わないIPSeCの方法。
送信データの完全認証を行う。パケット通信を行っている際
途中の経路でデータの中身が改竄の恐れがあるため、
改竄されたかどうかを確認するため、データの中身の認証を行う。
これだと例え改竄されても、チェックする事ができるため、
誤った情報が流れる事はなくなる。
ただし、暗号化されないため、データの中身は丸見え！
|
| ESPヘッダー |
データの暗号化と認証を行うIPSeCの方法。
データ改竄防止と、中身が丸見えなのを防ぐ。
ただし、データの中身の認証はAHと違って不完全。
|
主に2種類あるのだが、文章だけだと、わかりにくいので、
カプセリングの様子を図にしました。
IPSeCのカプセリング
（トンネルモードの場合） |
|---|
 |
AH認証ヘッダーを使う場合、データの完全認証できる。
そのため、データの改竄が行われても、完全チェックが可能になるのだが、
暗号化しないため、あまり使われない方法だ。
ESP認証ヘッダーを使う場合、データの中身は暗号化されるため、
途中経路での中身の盗み見ができないようになっている。
パケット認証だが、AHの場合、AHヘッダー内部に認証情報がある。
ESPの場合、ESP認証データの部分が認証データだ。
認証データは、データの中身を不可逆暗号を使って暗号化した物だ。
不可逆暗号の方式は、MD5やSHA1を使っている。
カプセリングされた後、ヘッダーとしてIPヘッダーがつく。
トンネルモードの場合、相手先のIPSeC装置のIPの情報が入るため、
この部分が盗み見されたとしても、どの端末同士で通信を行っているかは
全くわからないようになっている。
|
AHヘッダーについて、かなり省略した説明なので「詳しく調べろ！」と言う
声があるかもしれませんが、堂々と反論します。
使わへんから、調べる気がないもーん (^^)
そうなのです。技術者なら調べないといけないと思うかもしれませんが、
私は、ただの事務員。事務員なので堂々と手抜きしまーす！！
ここで、PPTPと比較した場合、IPSeCを使う利点として次の事が挙げられる。
パケットの内容チェック（認証）が行われている事だ！
これだと、例え、パケットの中身が改竄されたとしてもチェックができるため、
データの信頼性が確保できる。
さて、本をめくっていくと、お互いの通信の確立（コネクション）について
書かれていた。
IPSeCでは、コネクションの事を「SA」という。
| IPSeCのコネクション「SA」について |
|---|
 |
装置Aが装置Bに対して一方的に接続確立を行う。
もちろん、装置Bも一方的に装置Aに接続確立を行う。
|
これだけだったら、TCP/IP通信のコネクションと、どう違うのか
わかりずらいので、比較として、TCP/IP通信のコネクションを載せます。
TCP/IP通信におけるコネクション確立
(3Wayハンドシェイク) |
|---|
 |
| 例としてWebサーバーへの接続を考える |
| (1) |
接続先のサーバー(MAYUMI)接続要求信号(SYN)を送る。 |
| (2) |
MAYUMIは、許可する場合、データが届いたという応答信号（ACK）を送る。
しかし、MAYUMIは、持っているコンテンツを送りたくても
接続を要求してきたONOが、そのパケットの受付許可をしていない。
そこで、MAYUMIはACKと一緒にSYNの信号をセットで送る。 |
| (3) |
もちろん、ONOは接続許可なので、返事として、ACKを送り返す
|
| (4) |
安心して、MAYUMIは、ONOに、コンテンツと一緒にACKを送る
|
こんな感じて、データをやり取りする時、最初はSYN信号で相手の反応を見て
それに対してOKの場合は、返答の意味のACKの信号を送り返す。
そして、お互いが「受け取りました」の返答のACKを送って、
確認をとりながら、通信が続けられる。
このような接続確立のやりとりを「3Wayハンドシェイク」と言う。
|
TCP/IP通信の場合、上図のように、片方が接続確立を行おうとすると、
相手側が「ほな、うちも接続させて」と言って、お互いが接続される。
だが、IPSeCの場合は、片方が接続確立を行おうとしても、
相手側は「ほな、うちも」という事はない。
なぜ、そうなっているかは、この時点では、わからなかった。
というより「ふーん、そうなの」で、読み飛ばしていたのだった (^^;;
もちろん、IPSeCの接続確立の話は、こんな単純な話ではないのだが、
この時点では、上に書いた感じの理解だけで終わっていた。
事務員だから、それでいいのだ！！ (^^)
で逃げ切ろうと考えたのだが、このままの内容だと、100％突っ込みが来るので
調べて書く事になりました。詳しい話は、後述しています。
さて、本を進めて行くと、接続の際に使われる認証パスワードの話が出ていた。
PPTPの場合、定期的にパスワードの変更を行う必要がある。
理由は、比較的、パスワードが解読されやすいからだ。
ここで、PPTPの場合の認証方法を挙げてみますと
| MS-CHAPv2によるパスワード認証の概略 |
|---|
 |
PPTPの場合、お互いが出した「ランダムな文字列」が盗聴されると
力づくで、色々なパスワードを発生させて、それを暗号化させる事ができる。
そして、盗聴した暗号化パスワードと一致させる作業を行えば
パスワードの解読ができてしまう。
そのため、PPTP方式だと定期的にパスワードを変更する必要がある。
しかし、IPSeCの場合は、パスワードは解読されない。
定期的にパスワードを暗号化する秘密鍵が自動生成されるためだ！
その仕組みは以下の通りです。
| 秘密鍵の自動生成 |
|---|
 |
お互いが交換した乱数を使って秘密鍵を生成する。
この際、乱数が盗聴されたら危険なのではと思われがちだが
離散対数問題という凄く難しい数学を利用して、お互いにしかわからない
パスワードを生成しているため、乱数を盗聴したぐらいでは
秘密鍵が解読される事はないという。
|
ここで読者の方は「秘密鍵を使ってパスワードを暗号化する話を理解しているな」
と思われるでしょう。
私自身も「そうです」と格好つけてみたいが、どーせバレるので暴露しまーす！
秘密鍵の事をコロコロ変更されるパスワードだと誤解した！
我ながら凄い誤解だと思う。
考えれば、いくらパスワードをコロコロ変更した所で、盗聴されてはおしまいだが
この奮闘記を編集するまでは、本気で信じてしました (^^;;;;
そんな誤解をした理由には「離散対数問題」という文字がある。
秘密鍵生成の部分で、「離散対数問題」と文字が目に入った瞬間・・・
事務員にはわかりませーん (^^;;
となり、思考が停止。その先の説明は読まなくなったのだった (^^;;
そのためか、秘密鍵とパスワードが頭の中でゴッチャになったと思う。
定期的に秘密鍵の生成の事を「定期的にパスワードを自動生成」と
誤解してしまった私なのだが、この誤解がVPNの方式を決める重大な
判断材料になったのだった。
私は、PPTP方式かIPSeC方式のどちらにするかで迷っていたのだが、
「自動的に定期的にパスワードの変更ができる」という誤解をしていたため
次のように考えた。
「PPTPだと定期的に手動でパスワード変更が必要だが、営業所の人には無理。
となれば、自動的に変更してくれるIPSeCを使う方が良い」と考え、
IPSeC方式にする事に決めた。
今、考えれば、結果オーライなのだが、非常に、いい加減な判断だったと思う (^^;;
我ながら、悪運の持ち主だと思った。
社内ネットワークの再設計
この時「これでVPNが、どんな物かわかってきた」と思った。
実際は、相当あやしい理解だったのだが、この時点では、わかった気になっていた。
さて、インターネットVPNの導入。
だが、世の中、すんなりと導入の方向へはいかない。
まず、立ちはだかったのは、シスコのルーターの問題だった。
フレームリレー回線の利用のため、シスコのルーターが鎮座している。
| J社に出した新しいネットワーク構成図 |
|---|
 |
東京支店をフレームリレー回線からインターネットVPNに変更するが
いきなり切り替えも危険なので、様子見という形で1、2ヶ月ぐらいは
両方の回線を使う事を考えた。ただし、東京支店でのネットワークは
フレームリレー回線とVPNの回線とは接続しない事にした。
そのため、IPも別々に割り当てる。
この時、私は本社のルーターのルーティングだけ変更すれば良いと思っていた。
|
だが、誰がシスコのルーターの設定変更を行うかが問題だった。
シスコのルーターは触りたくても、恐くて触れない。
基幹業務に使われているため、ネットワークが止まっては大変な事になる。
その上、下手に触ったために、止まってしまうと、設定の修正のために、
高い請求書がやってくる。
「生兵法は怪我の元」なので、J社に依頼する事にした。
まずは見積書を出してもらわねば、稟議を出しようがない。
そこで、上のネットワーク構成図をJ社に送り、ルーターの設定変更のための
見積もり依頼をする事にした。
J社に見積もりの依頼の電話をかける。
| J社とのやりとり |
|---|
| J社 |
本気でやるのですか。
帯域保証がないインターネットVPNは無謀ですよ。
当社のお客さんで、過去にいましたが、障害が起こったりしたため
お勧めできないです。フレッツADSLは無謀です。 |
| 私 |
でも、だいぶADSLは安定しているでしょ |
| J社 |
もし、キャリアさんを変えて導入した場合に
トラブルが起こったら、何が原因かが
切り分けできない問題があります |
フレームリレー回線の場合、J社が通信の状態などを監視しているため、
問題が発生した場合、すぐにJ社が把握できるが、J社と関係のない
キャリアの回線を使い、独自で設定したルーターで通信を行なうと
何か障害が起こっても、切り分けが困難になり、責任の擦りつけ合いが始まる。
J社の本音は・・・
責任の擦りつけ合いだけは嫌!
だった。
もちろん、J社の言い分もわからんではない。しかし、回線費用がバカ高い上、
速度の遅い回線を使い続けるのは無駄な気がする。
| J社とのやりとり |
|---|
| 私 |
別に、責任の擦りつけ合いなんてする気はないです |
| J社 |
別に、そういうわけではないのですが、原因の切り分けなどが・・・
技術者を連れて、説明に行きますので
|
| 私 |
それで良いから、まずはルーターの設定費用の
見積もりを出して |
| J社 |
... |
顧客の立場を利用して、なんとか押しきった。
だが、待てども、待てども見積を出してくれない。
10日経っても回答が来ないので、しびれを切らした私はJ社に対して
「ねぇ、まだなの」と催促の電話をかけた。
すると耳を疑う事を言い出した。
| J社とのやりとり |
|---|
| J社 |
ヤマハのルーターでSNAプロトコルを流せないので、技術者の人が
どうやって構成しようか悩んでいます
|
| 私 |
どうして、わからない事があれば、私に聞かないのですか。
意思疏通ができないと、いつまでたっても、前に進まないでしょ
全く意志疎通ができていない状態だった。
| ベンダーの技術者と顧客担当者は意思疏通をとるべし! |
|---|
私自身、別に技術力があるわけでもないし、間違いだってする。
そのため、ベンダーの技術者は「あれ?」と思った事は、聞いて欲しいと思う。
お互い話をして、どういう事を行なうのか、意思疏通を行なわないと
話は前に進まない上、間違えた方向へ進む危険性がある。
J社に設計からハード選定から設定まで、丸投げする気もない。
ユーザーが決める部分は、ユーザーが決めて、ベンダーに指示を出す必要がある。
お互い協力して、良い物を作っていくべきだと思う。
技術者の中には「顧客はド素人」と見下して対応する問題外の奴もいるが、
主体性のない丸投げ志向の顧客が「金を払っているのは、こっちだ。
お前ら、プロだから、考えろ」と言われるのが恐くて、顧客に聞けない
技術者がいる場合もあり得る。
お互いが意思疎通を図り、協力して、より良い物を作ろうという気がないと、
プロジェクトはうまくいかないと思う。
|
それから1週間して、ようやく見積もりが出てきた。
予想外の金額にビックリ！
私の予想を反して、東京支店のルーターの変更も必要だという。
思わず頭を抱えてしまった (--;;
J社から「もし、全国13ヶ所の営業所にインターネットVPNを導入する際は、
全拠点のルーターの変更が必要になります。もし、1ヶ所づつ変更の場合は、
その度に、本社のルーターの変更も必要なので高くつきます。
一気に全部のルーターを変更された方が安くなります」と言われた。
本社と13ヶ所の営業所分の合わせて、14ヶ所のルーターの設定変更だ。
ただでさえ、本社・東京間のインターネットVPNが可能かどうかも試してみないと、
わからない段階で、全拠点のルーターの設定変更という高い金額を出されても
とても稟議が降りない・・・ (--;;
私には、シスコのルーターを触れるほどの技術力は持っていない。
ここで、インターネットVPN導入は挫折かと思った。
だが、往生際の悪さは天下一品の私！
こんな所で、奮闘記のネタをボツにする気はない！
コンフィグが手元にない上、あったとしても、読めるわけがない。
そこで、シスコのルーターを触らずに、パケット送信の実験の繰り返しで
パケットの経路情報を全て調べる事にした。
その時、デフォルトゲートウェイに注目した。
| 私の頭の中で考えた事 |
|---|
 |
例え、シスコのルーターにVPN回線へのルーティング情報が記述されてなくても
上図のように、営業所のシスコのルーターのデフォルトゲートウェイが
本社のシスコのルーターであり、かつ、本社のルーターのデフォルトゲートウェイが
NATのマシンの場合、パケットの行き先が、割り当てているIPアドレス以外の
ネットワークの場合なら、全てNATのマシンを経由すると考えた。
そこで、NATのルーティングだけ、変更すれば、うまくいくと考えた。
|
早速、下図のような実験を行った。
| 実験内容 |
|---|
 |
上図のように、192.168.20.0/24のネットワークエリアを作って
そのエリアを、VPN回線超えしたネットワークのエリアに見立てた。
そして、実験端末を置いて、実験端末と営業所間が通信できるか確かめた。
|
私の予想は的中した。営業所から実験端末へ ping をした時、
見事に応答が返ってきたのだった (^^)V
これで、シスコのルーターの設定変更を行わなくても、
NATマシンのルーティングの変更をすれば、問題がない事がわかった。
詳しくは「システム奮闘記：その26」をご覧くださいね (^^)
(ネットワーク入門 デフォルトゲートウェイとルーティング)
この時、節分間近の1月末だった。
本当の所、営業所と本社のシスコのルーターのデフォルトゲートウェイの設定が
どうなっていたのか謎だったのだが、2004年12月にシスコのルーターの
コンフィグを見る事ができた。
| 本社に鎮座していたシスコのルーターの設定(抜粋) |
|---|
no ip classless
ip route 0.0.0.0 0.0.0.0 192.168.1.XXX
|
シスコのルーターのデフォルトゲートウェイの設定だ。
予想通り、NATマシンのIPアドレスを指定していた。
|
ただ、営業所にあったシスコのルーターに関しては・・・
コンフィグを見ても、わからへん (TT)
だった。
まぁ、フレームリレー回線のために使っていたシスコのルーターは、
今後は、不要になるため、無理にコンフィグを覚える必要はないと考え、
コンフィグを解読するのを、あっさりと諦めました。
事務員だから覚えなくても良いもーん (^^)V
話を戻します。
これで、ルーティングの状態がわかったお陰で、シスコのルーターの設定変更を
行わずに済む事がわかった。
フレームリレーの解約
これで、やれやれと思いきや、今度は、別の大きな壁が立ちはだかっていた！
それは、フレームリレー回線の長期割引プランの違約金問題だった。
さて、インターネットVPNを導入した後は、フレームリレー回線を解約する
必要がある。
そこで、通信会社のK社に解約の際の手続きについて、話を聞く事にした。
K社の人の話を聞いて、愕然とした。
フレームリレー回線は6年間の長期割引プランだった！！
1999年にK社と契約したという。この時、私は契約には関わっていなかった。
そのため長期割引プランに入っている事すら、知らなかった。
契約関係に関わった人達も忘れていた話だった。
このまま解約すれば高い違約金をとられる・・・ (--;;
そこで、契約を代行している、J社に問い合わせて、なんとかならない物かと
相談してみたが、違約金は発生してしまうと言われた。
6年プランが切れるまで、残り1年半。思わず呆然としてしまった。
なんで、そんな長いプランに入るのか、理解できない。
通信技術の日進月歩は凄まじい事は、1999年時点で、わかっている話。
長くても、せいぜい3年の間隔で見るべきなのに、6年契約をしているため
一体、何を考えているねん!
という感じだった。
当時、契約の際に担当していた人物に怒りの矛先を向けたいが、既に退職している。
やり場のない怒りで、一杯だった (--メ
やり場のない怒りと無力感。折角、七転八転しながらも、ここまで辿り着いたのに、
ここで断念とは、やりきれない気持ちだった。
N社のH子さんに違約金発生の問題が出たため、インターネットVPN導入の断念を
伝えるメールを書いた。
そして、部長には「違約金問題発生のため、インターネットVPNは断念します」
と伝えた。だが、部長は前向きな回答をした。
例え、違約金がかかっても、導入効果の方が大きければ払う
まさに、起死回生の言葉だった。
だが、違約金はかからない方が良い。
そこで、契約代行しているJ社に交渉の代行を行ってもらう事になった。
その結果、何百万もする違約金を払わずに済んだ (^^)
これで違約金問題が解決した。この時、桜が咲いている4月になっていた。
AS400のTCP/IP化
なんとか違約金問題が解決できた。これで前に進むと思った。
N社のH子さんに違約金の問題が解決できたので、インターネットVPNの導入を
進めましょうというメールを書いた。
インターネットVPNを導入する際に、大事な事は、AS/400本体で使える
通信プロトコルの追加だった。
SNAだけでなく、TCP/IP 通信も使えるようにしてもらう必要があった。
J社に依頼して、追加してもらう事にしたら、また、J社がゴネた。
「この機種ですと、IBMのサポートが切れていますので」だった。
私が「TCP/IPにすると、障害が頻繁に発生するのですか？」と聞いたら、
「そんなわけでないのですが、サポートがされていないので」と及び腰だった。
でも、顧客の立場を利用して、追加作業をしてもらうように押しきった (^^)V
だが、なかなか見積書を出してくれない。
仕様がハッキリ決まっていない場合なら、見積りが出しにくいのは、わかるが
AS/400の本体が TCP/IP通信ができるように設定を行うだけだ。
すぐに見積りが出て当然のはずなのだが・・・。
ようやく見積りが出たので、稟議を上げる。もちろん、あっさりと通った。
そして、念願だったAS/400に、TCP/IPプロトコルの追加を行なったもらった。
プラスして、パソコンに入れるAS/400のエミュレーター（P-COMM）の設定方法も
教えてもらうのも盛り込んでいた。
4月初め、J社の技術者の方が来て、AS/400に、TCP/IPの追加を行ってもらった。
そして、端末にインストールしているエミュレーターの設定方法も
教えてもらう。これで、新しく端末を入れても、J社に依頼しなくても、
自力でエミュレーターの設定が行える。
今まで、パソコン上でAS400のエミュレーターに障害が起こっても、
SNAがわかる人が社内にいなかったため、社内では対応できなかった。
自分達ではインストールできない上、何かあるとJ社頼みだった。
逆に言えば、J社の言いなりに、ならざる得なかった。
だが、この日を境に、J社の呪縛から解き放たれた。
例えば、パソコンにP-COMM（AS/400のエミュレーター）をインストールする時だが、
J社から長年に渡り「IBMのパソコンでしか動作保証できない」と言われ続けた。
自力でインストールできないため、IBMの高いパソコンを買わざる得なかった。
今回、自力でエミュレーターをインストールできる事になり、
自分達で確認する事ができる。
早速、私のシャープのノートパソコンでインストールしてみた。
問題なく動作したので、無理に、IBMのパソコンを買う必要もなくなった。
そして、自宅からVPNを使って社内LANにアクセスして、AS/400が
使えるかどうか確認をとる事にした。
帯域保証がない場合に、基幹業務への影響を調べる必要がある。
早速、私のノートパソコンを自宅に持って帰り、家からAS/400へ接続実験を行った。
無事、接続できた！！ (^^)V
もちろん、自宅から会社まではインターネットを経由して接続している。
そのため、帯域保証がないのだが、AS/400の通信が切れる事はなかった。
散々、J社から脅されて不安になっていた帯域保証の問題だが、
これで安心して使えると思った。
インターネットVPNのためのルーター選び
ようやく回線の切り替えのための環境が整ったので、次は、VPNを行うための
ルーターの選定だった。
これも、頭を悩ませる事になった。
ヤマハのルーターなら、シスコのルーターに比べ、価格的に安い上、
実績も出している。
だが、他社製品で安いルーターもある。経費節減の事を考えれば、
ヤマハより安い製品を買うという手もある。
候補にあがったのは、センチュリーシステムズの XR-410 だ。
だが、シスコに比べると安定性にちょっと不安があるという話も聞いていた。
シスコのルーターと比較する方が間違いなのかもしれないが、
今まで、シスコという高いルーターを使っていたため、ルーターが落ちないのが
当り前のようになっている。
他には、1万円を切るIPSeCルーターとして、パーソルの「persol BSR14」も
候補にあがった。
日経システム構築：2004年1月号の記事で、(株)寺岡精工が導入している事が
書かれていたのを見て、私は「これは安くて使える！」と思った。
だが、頭の中にあったのは「安定性」という問題だ。
あと、IPSeCの場合、コネクションの確立の方法で、他社製のルーターとの間で
互換性の問題が生じる事もある。
「安定性」と「互換性」の問題
4月のある日、知人の所でヤマハのルーターを実際に使っているので、
ヤマハのルーターの話をすると、RT105e や RTX1000 の安定性は
全く問題がないという。
それに、結構、互換性があるようで、シスコとの通信は問題なくできる。
将来、ルーターの変更などがあった場合、互換性があるルーターが望ましい。
そこで、少々高くても、ヤマハのRT105eを購入する事に決めた。
購入先を決めようとしていた所、H子さんから、次の提案がやってきた。
| H子さんからの提案 |
|---|
新規インターネットVPNでご利用になる予定の
ルータ(YAMAHA RT105e)の件ですが、当初、菅様のほうで
直接ご購入予定とお聞きしておりました。
私も、量販店で購入されたほうが料金的にも
お安いと認識していたのですが、最近は弊社からの
ご提供も値段がさがっておりますため、一度よろしければお見積りを
ご提示できればと思うのですが、いかがでしょうか。
|
この時、私は「H子さんには悪いけど、ソフマップよりも安い、
ぷらっとホームのネット販売より安くはできんやろ。これ以上、安く売れば、
原価割れするやろしなぁ。値段の駆け引きして、時間を無駄にするよりも、
ぷらっとホームの値段を教えて、諦めてもらった方がええやろ」と考えた。
そこで、H子さんに、ぷらっとホームのネット販売での
ルーターの価格をメールで伝えると、私の予想外の回答がやってきた。
なんと、それより安くできるというのだ！
これには驚いた。
ふと思った。ヤマハのルーターの製造原価は、一体、いくらなんだろう?
通信会社への卸値が、量販店よりも安いとしか思えない。
だが、いくら、そんな事を考えても、一般利用者に、わかるわけがない。
それに、安く入手できるのだから、利用者にとっては、ありがたい。
そこで、N社から見積もりを取ることにした。
本社のルーターだが、当初は、RT105eの予定にしていたが、
H子さんから次の提案があった。
| H子さんからの提案 |
|---|
弊社のSEが、御社の場合、本社のルーターが処理する通信データ量も
多くなる事が予想されますので、RTX1000の方をお薦めします
|
話では、RT105eは、ソフト的にIPSeCの処理を行っているが、
RTX1000では、ハード的にIPSeCの処理を行っているので、処理速度も違うという。
本社・営業所間のデータ通信量が増大しているため、本社のルーターは
強力な物を入れておいた方が賢い。
そこで、本社のルーターは、RTX1000を採用する事にした。
ただ、うちの会社の営業所で、電話局から離れている所が結構あるので、
ADSL回線が不安定で使えない場合は、ISDN回線を使う事で、RT105i にする事にした。
そして、5月半ばに見積もりが出た。
確かに、安い。迷う事なく、N社からの購入を決めた。
ルーター設定について
さて、ルーターの設定は誰が行うのかが問題になった。
ここで私の中で葛藤が起こる。
| 私の中で起こった葛藤 |
|---|
| (1) |
自分で設定してみたいという気持ち |
| (2) |
自分で設定するのは無謀なので
外注して楽したいという気持ち |
いつもなら、無謀な道を選んで失敗談の生産の準備にとりかかるのだが、
だが、自分で設定できる自信は全くなかった。今まで触った事がない上に、
もし、障害が生じた時には大変な事になる。
通信ができなくなると、基幹業務を止まるため、その危険は避けたい。
その上、N社のルーターの保守契約に入る時、設定はN社が行わないと
保守契約には入れないという。保守契約を考えると、外注した方が良くなる。
ワル知恵だけが得意な私は、危険を下げた上で、ちょっとは自分でも
ルーターを触ってみるという良い方法はないのか考えてみた。
そこで、私はN社に「数ヵ所の営業所は御社が設定を行い、
後は、私が行うのはいかがでしょうか。単にIPSeCだけの設定なので
誰が行っても同じ設定になると思います。設定した内容は御社に提出すれば、
問題はないかと思います」と提案してみた。
交渉してみたが、結果はダメだった (^^;;
自分でルーターの設定するのができないので、普段ならスネてしまいそうだが、
今回はそんな事はなかった。
これで何があっても、N社に責任を押しつけられる！！
何せ、今までのシステム構築と違い、基幹業務に関わる事だけに、
慎重さが要求される。ちょっと触ってみたいという誘惑のために
大失敗をしてしまったのでは、大変な事になってしまう。
という事で、私の頭の中では、ルーターの設定はN社に依頼する方向で考えた。
完全に・・・
丸投げIT担当者
に変貌してしまったのだった (^^;;
営業所のパソコンに入っているAS/400のエミュレーター(P-COMM)の
設定変更する必要がある。
SNAプロトコルからTCP/IPへの設定変更だが、外注に依頼するよりも
私が出張した方が安くつく上、営業所のパソコンの不具合対策が行える。
どんな不具合が出ていたのかを書きますと、次の通りです。
| ハードディスクのパーティション問題 |
|---|
 |
まだ、私がIT担当を行う前に購入したパソコンが営業所で使われている。
HDDの容量は8Gあるのだが、何を考えているのか、
2Gづつで、パーティションを切っている。
まだ、Windows95なら、わからんでもないが、FAT32を使えるWindows98で、
FAT16を使っているのだから、理解しがたいモノがある。
当時は、インストールしているソフトが少なかったため、問題なかったのだが、
どんどん入れるソフトが増えて、ディスクの容量不足の問題や
仮想メモリーをCドライブにしているため、Cドライブの容量不足のため
仮想メモリが不足して、印刷などでメモリ不足の問題が発生していた。
文句が言われるのは、当時、担当していない私なのだ (--;;
|
この問題を解消するには、次の方法しかない。
| 問題解決法 |
|---|
 |
2Gづつ区切っていたパーティションをやめて、1つにしてしまう。
システム領域とデータ領域を分けた方が良いという声があるかもしれないが
たった8Gしかないため、2つにわける余裕もない。
|
「一挙に問題を片付けてしまえ」という目論見だ (^^)
フレッツADSL契約で問題発生
7月5日、社長決済が降りて、正式に導入する運びになった。
そして、8日にN社のSEのYさんが来られ、打ち合わせ。
私の方で、どういうネットワーク構成にするのかで、あらかじめ、
私が設計したネットワークの構成図を見せる。
ルーティングをどうするのか、どんなIPの割り振り方をするのか説明をした。
N社のYさんは「これだと問題ないです」と言った。プロのお墨付きを得た！
数分で技術的な打ち合わせは終わってしまった。
社内のネットワークの構成を把握していると話が前に進みやすい (^^)
どこの営業所から、インターネットVPNを導入するかが問題になる。
そこで、確実に、ADSL回線が引ける所から設定を行なっていきたいため、
ADSLの伝送損失が小さい上、本社から近い場所という事で、
岡山・広島から回線の切り替えを始める事にした。
ADSL回線が開通できない地域に関しては、ISDN回線を使う話で進める事に
なっているので、回線開通のためのフローチャートは以下の通りだった。
| 回線切り替えの作業工程 |
|---|
 |
だが、この作業工程の通りにならないのが世の常なのだが、
この時は、作業工程通りに進むと考えた。
7月12日、フレッツADSLの申し込みをNTT西日本のホームページから
本社、岡山、広島分を申し込んだ。
何せ、インターネットVPNの試みは初めてだけに、慎重に行ないたい所。
NTT西日本から電話があり、岡山営業所の地域の電話局が光収容局のため
メタル回線でのADSL通信に不安があると連絡がきた。
光収容ってやねん?
だが、「光収容局」とは何かを調べる事をしなかった (^^;;
これはADSL回線を敷く際にクセ者になるのだが、この時は、クセ者になる事は
知る由もなかった。
さて、インターネットVPNの導入は、フレッツADSL回線を申し込んで
回線を敷くだけな上、ルーター設定はN社に外注しているため、
私は、楽できると思っていた。
奮闘記の読者からは「ヤマハのルーターで、ドツボにハマった部分が読みたかった」
という声があると思うが、
たまには、ラクさせて欲しい (^^)
そうなのです。ここまで辿り着くだけでも紆余曲折しながらも、
なんとか導入にこぎつけた。それだけでも、大変だったのに、
これ以上の問題発生だけは勘弁して欲しいのが本音だった。
だが、「そうは問屋が卸さない」のが世の常だ。
私の「楽したい」という願いも虚しく、この後も、次々と問題発生が
待ち受けていた。
というわけで、引続き、次々と立ちはだかる壁の話を書く事にしました。
ヤマハルーター調達の問題発生
7月13日、N社のYさんから電話が入る。
ヤマハがルーターの製造中止を発表！
なんと、RT105iと、RT105eの製造中止を発表したのだった！
特に、ISDN用のルーター(RT105i)は在庫が少ない。
そこで、N社のYさん、H子さんと話をした結果、ADSLルーター（ RT105e ）を
仮り押さえして、8月初旬までに、ADSLの開通が怪しい所を洗い出す事になった。
ルーターの製造中止の場合、肝心の保守契約はどれくらいやってもらえるのか
気になるため、N社のYさんに確認をとる事にした。
保守契約は5年間は大丈夫という回答があり、ホットした。
7月14日、ADSL回線開通が怪しい営業所の、フレッツADSLの申し込みを
行なう事にした。
| ADSL回線開通が怪しい営業所 |
|---|
| NTT東 |
新潟・埼玉・千葉 |
| NTT西 |
名古屋・福岡・金沢 |
計6ヶ所の営業所がADSL開通が怪しい所だ。
そこで、予定を大幅に変更して、上の6ヶ所のADSLの申し込みを行なった。
最初に、ADSL回線の大丈夫な地域から進めて行く作業工程が
簡単に崩れ去った。
予定通り進まないのは頭が痛い・・・ (--;;
フレッツADSLが引けない問題
だが、ルーターの製造中止の問題は、これから立ちはだかる数々の問題発生の
序曲にすぎなかった。
7月20日だった。NTT西日本から電話があった。
なんと・・・
本社にADSL回線が敷けない!!
これを聞いた時、「なんで、開通できへんねん!!」と思った。
現に、インターネット回線は、ADSL回線で行なっているため、
なぜ、ADSL回線が敷けないのか、理由がわからなかった。
私が「どうして、ADSL回線が敷けないのか！」と問いただした所、
NTT西日本は「本社は光収容局の地区で、メタル回線の空きがないです」と言う。
なんとNTTがADSL回線の縮小を行なっているというのだ！
NTT西日本に「現在、インターネットのために、ADSL回線を使っているのに、
どうしてサービス提供できないのですか」と聞いた。
NTT西日本側は「光収容局にして、どんどん光に切り替えをしていますため、
メタル回線は縮小しているのです。」という回答がきた。
まだ他の営業所なら、色々、手が打てるが、肝心の本社でADSL回線の
空きがないとなれば、話は進まない。
私は強い口調で「なんとか、ならないのですか！」と強く迫ったら、
NTT西日本側は「もう一度、確認してみます」と返事をした。
早速、N社のH子さんへ連絡をとった。
暫定的に本社をISDN回線を敷いて、後日、Bフレッツに切り替える案や、
現状のADSL回線を併用する話などをした。
だが、しばらくして、NTT西日本から「空きがありました。大丈夫です」と
連絡がきたので、安堵した。
だが、2日後の、7月22日、耳を疑う事態が発生した。
NTT西日本から「やはり本社の場合、メタル回線がありませんので、
ADSL回線を引く事ができません」と連絡がきた。
これを聞いた私はブチ切れそうになった （--メ
NTT西日本に強い口調で「なんで、今更、できないと言い出すだ。
最初からできないと言えば、こっちだって、それなりの対策をとるけど、
一昨日、おたくが『できる』と言ったから、それを信じて他の営業所の
ADSL回線の申し込みなどを行なったんだよ。どうしてくれるのだ！」と言った。
「ふざけるな！」と言いたかったが、しかし、担当者に怒鳴っても仕方ない。
そこで、私は「とりあえず、休止回線を復活させて、フレッツISDN回線で
開通させるから、どれくらいでできるのか、教えて欲しい」と言ったら、
NTT西日本側は「休止回線が、すぐに使えるか、どうか、わかりませんので、
来週まで時間をください」と言ってきた。
それを聞いた私は「どうして、調べるのに、時間がかかるんだ。
一度、開通できると、いい加減な事を言って混乱させたのだから、
責任とって早く調べろ！」と強い口調で言い放った。
電話を切った後、「NTTのアホが何を考えてんねん！」と言いながら
ISDN回線も引けない場合に備え、現在、使っているADSL回線を利用して、
インターネットVPNを行なうために、ネットワークの構成変更を考えるが
サーバーの構成やIPの割り振りなどを根本的に変更するのが迫られるので
考えたくもない。
こういう時は「業者に丸投げして楽したい」と思ってしまう ← 思わず本音 (^^;;
そして、N社のH子さんに連絡を入れる。
私は愚痴を言いたくなるので、思わず「ホンマ、NTTは詐欺だよ。
ホームページでADSLを宣伝しながら、空き回線がない状態だから
いい加減で、どうしようもない会社だよ」と言った。
| NTTは伏魔殿! |
|---|
NTTは、大々的にADSLを宣伝しながら、その一方で光ファイバー網の野望を
達成すべく、メタル回線を撤去しているのだから、その行動は理解できない。
元々、NTTはADSLには乗り気でなかった。1990年後半、アメリカで
ADSLのサービスが始まった。ADSLは、高速通信が既存のメタル回線を使って
低コストで導入できる技術だ。しかし、NTTは高く売れるISDN回線を売るため、
ISDN回線による干渉問題をとり上げて、ADSLの導入に抵抗したり、
旧・郵政省を騙して、時間稼ぎをしたりしていた。
東京めったくり通信が参入してきた時、NTTは、お得意のイジメ攻撃。
NTTの妨害工作に苦しめられ、最終的に、ADSLのパイオニアだった、
東京めったくり通信は身売りという形で姿を消した。
まぁ、救いはNTTの軍門に下らず、ソフトバンクへ売却されたという事だ。
NTTは独占という立場を利用して、エゲつない事をしている。
全ての通信会社は、末端の回線をNTTに頼らざる得ない。
そのため、接続料という上納金を納めないといけないが、金額が半端ではない。
通信会社は、売上の40％を接続料として、NTTに納めているのだ。
NTTは、同業他社が汗水たらして稼いだ売り上げを横取りする
エゲツない事をしている。
接続料を下げるために、バカ高い交換器や、光ケーブルなどの償却年数を
倍の長さにする案が出ていたりする。欧米では日本の倍ほど償却期間がある。
償却年数が短いと、それだけ減価償却費が増えるため、費用が増える。
ただでさえ、過剰投資が大好きなNTTなのに、減価償却期間が短いと
「損益計算書を良くするために、接続料などで稼ぐ必要がある」と言いだす。
その上、同業他社への嫌がらせはNTTのお得意な分野。
他の通信会社が電柱に回線を敷く場合がある。
電柱は電力会社所有の物と、NTT所有の電柱があるのだが、電力会社の場合、
対応が早いが、NTTの場合だと、たらい回しにされる話をよく聞く。
独占を強めると総務省から文句が出るので「生かさず殺さず」をするのが
NTTの常套手段。TTネットは、まさに、NTTの餌食になった良い例。
NTTの批判をしていると、NTTの職員が全て悪人と思われるが、そうではない。
実際に、対応の早い人もいるし、NTTの体質に批判的な人もいる。
「人は多いが働かん」でリストラが必要なNTTだが、組合が強すぎて
リストラができない状態になっている。
そのため、仕事ができないのに、給料だけが良い、オジサン、オバサンを養うため、
安月給の若手社員は激務を強いられる現実があるという。
知り合いのNTTの職員から「組合は厄介だ」という声も聞く。
NTTの組合は全電通という所で、魑魅魍魎の住む世界だ。
90年台の初め、政界の仕掛人と呼ばれた山岸章の出身母体でもある。
何十万もいる組合員から組合費を徴収しながらも、一度もストを起こしていないので
闘争資金が700億円と言われる。
NTTがストを起こすと、日本の通信がマヒするため、それを利用して
強力な圧力団体となっている。
NTTに関する話は次の本がお勧め。
「巨大独占 NTTの宿罪」（町田 徹：新潮社）
|
その日の夕方近く、NTT西日本から電話があった。
休止回線を使えば、ISDNだけでなく、ADSL回線を敷けるという。
だが、NTT西日本の言葉に、疑いを持つようになったので、
実際のADSLの工事日まで、開通できるのかどうか不安だった。
しかし、無事、工事終了したので、ADSL回線を敷く事ができた。
休止回線が1本余っていたお陰で、回線を敷く事ができた！
電話局の光収容局のため、空き回線がない問題は、他の営業所でも発生した。
7月27日、NTT西日本から電話があった。
名古屋も光収容局で、メタル回線に空きがないという。
本社でないため、慌てる事はなかった。というより、動じなくなった (^^;;
本来の予定なら、ADSLがダメなら、ISDN回線にする話だったのだが、
キャンペーン期間で工事費が無料で、ADSLと比較して通信費も変わらない上、
N社に払うプロバイダー料金が月額が3000円上昇だけに抑えられるため、
遅いISDN回線を入れるよりも、Bフレッツを入れた方が賢い選択だ。
それに、Bフレッツが開通まで2ヶ月みる必要があるのだが、
全国13ヶ所の設定を行うため、最終完了を11月ぐらいと考えていただけに、
2ヶ月後でも問題はない。
そこで、NTT西日本に、Bフレッツが可能かどうか調べさせたら、
サービス可能地域だという事で、名古屋をBフレッツで進める事に変更した。
| 光収容局について |
|---|
光収容とは、電話局から自宅（会社）までの電話回線の一部でも、
光ファイバーが使われている場合の事を言う。
ADSLを利用する場合、メタル回線で音声帯域よりも高い周波数帯域を使って
通信を行なうため、電話局から自宅（会社）までの回線が全てメタル回線でないと
サービスが受けられない。（通信ができなくなるため）
NTTは光ファイバー普及のために、どんどんメタル回線を撤去している。
そのためADSL回線を敷く事ができない事態に陥る。
フレッツモア40MなどのADSLの宣伝を行なっている一方で、
メタル回線の撤去を進めている矛盾を、NTTは何も説明しない。
|
あと、埼玉もBフレッツへの変更を行なった。
理由は別にあった。ADSL回線の工事が終わり、リンクが立ったのだが、
NTTの作業員の話では「リンクが不安定になる場合がある」と言われた。
電話局からの距離が離れているためだった。
不安定な回線だと、基幹業務に支障がでる。
それでADSLを解約して、Bフレッツに変更する事にした。
名古屋・埼玉は、2ヶ月後の10月ぐらいに回線切り替えと考えた。
だが、また、簡単に予定が狂う。
珍しく、NTTが早い対応を行う。3ヶ所とも、申込後、2週間後には、
Bフレッツの工事ができるという。
うれしい半面、コロコロ予定が変わるため、日程の調整を行うのが大変だ。
回線調達の問題はルーターの設定にまで影響が出てくる。
本社に設置されるRTX1000のルーターで設定できるVPNトンネルの数だった。
RTX1000の場合、トンネル数は30個が上限だ。
当初は、ADSLを引いても不安定な場合は、ISDN回線を使う予定だったので、
伝送損失が40以上の営業所のみ、ADSLとISDNのトンネルを設定しておく話だった。
そして、全ての営業所で設定が起こった後、最後に本社のルーターの
不要なトンネルを取り除くという話になっていた。
そのため、十分にトンネルの数はあった。
しかし、NTTがADSLを大々的に宣伝しておきながら、メタル回線を撤去するという
詐欺まがいの商売を行っているため、伝送損失が問題のない営業所でも、
ADSL回線を導入できない場合が出てきた。
おまけに、Bフレッツという選択肢もできたため、トンネルの数が足らなくなる。
トンネルの数で悩む理由だが、N社から設定変更の際は料金がかかりますという
話があったため、余分な費用をかけるわけにいかない。
トンネル数の確保のため、Bフレッツのサービスエリアでは、回線速度の遅い
ISDNの選択肢を捨てたり、どの回線が使えるのか、割出せる所は割出して
トンネル確保の問題を回避した。
インターネットVPN切り換え作業開始
8月5日、いよいよインターネットVPN導入だ。
第一号になる営業所は、岡山営業所だった。
私は現地のルーターの設定の立ち合いと、パソコンの不具合対策のため、
岡山へ出張となった。
そして、本社のルーターの設定のため、N社のYさん、H子さんが
本社で来る事になた。
さて、神戸市民の私は、新神戸から新幹線で岡山へ行く事になった。
のぞみの自由席だったので、座れるかどうか心配だったが、無事、座れた。
青春18切符が体に染み付いているため、新幹線に乗る度に、
あまりの速さに、いつも感激してしまう (^^;;
出張前に、部長に「経費削減のため、18切符を使ったらどうや」と言われた。
社内では「18切符男」と言われている。別の意味での「電車男」かも (^^;;
そして岡山営業所に着く。
10時近くになり、N社の委託を受けた地元業者の方が来る。
しかし、パソコンとルーターを接続するRS232Cのケーブルで
ストレートとクロスを間違えて持ってきたため、取りに帰るという
問題が発生。
作業が1時間半ほど遅れる。
その間、私は営業所のパソコンの不具合対策と、設定変更の作業をしている。
そして、業者の方が戻ってきて、本社との接続作業を行なう。
本社には、N社のYさんが本社のルーターを設定を行なう。
午後2時になり、本社と岡山との間の通信が確立した。
そこで、導通確認のため、本社のパソコンへ ping を打つのだが・・・
ping の応答があらへん・・・
| 本社のマシンに ping が通らない事態発生 |
|---|
 |
なぜか、わからなかった。
しかし、反対に、本社から岡山のマシンには ping が飛んでいる。
| 本社から岡山には ping が問題なく飛ぶ |
|---|
 |
全く理解不能な状態だ。
実は、この時、岡山と本社の間のパケットの経路は下図のように考えていた。
| 岡山と本社の間のパケットの経路 |
|---|
 |
シスコのルーターは、本社のマシンのデフォルトゲートウェイ。
NATはシスコのルーターのデフォルトゲートウェイの上
本社のVPNルーターのデフォルトゲートウェイでもある。
|
ルーティングの設定上、上図のようにパケットが飛んでいると考えていた。
実は、上図のパケット経路とは違う、パケットの動きをしていたのだが、
この時は、上図のような経路でパケットが飛んでいると思い込んでいた。
そのため、岡山から本社へ ping が飛ばないのに、反対に、
本社から岡山へ ping が飛ぶのが理解できなかった。
しかも、もっと話がややこしくなったのは、他の営業所には ping が問題なく飛ぶ。
| 他の営業所には ping が問題なく飛ぶ |
|---|
 |
この時、他の営業所だけでなく、社外のマシンにも ping を飛ばしたが
問題なく応答が返ってきた。
|
本社にだけ ping が飛ばない！！
謎としか言い様がない状態に陥った。
そこで、ネットワークの状態を思い浮かべる事にした。
| 社内のネットワークの状態 |
|---|
 |
N社のYさんと話して、どうやら、戻りのパケットのルーティングが
うまくいっていないようだ。
N社のYさんが「これで、ping を飛ばしてみてください」と言ったので、
Yさんが持ってこられたパソコンへ ping を飛ばすと、応答が返ってきた。
本社パソコンのデフォルトゲートウェイを
ヤマハのルーターにした時 |
|---|
 |
今まで、本社のパソコンのデフォルトゲートウェイは、全てシスコのルーターに
なっていた。
そこで、新しく設置したヤマハのルーターをデフォルトゲートウェイにすると
問題なく通信できるという。
シスコのルーターか、もしくは、NATが悪さをしている感じだ。
だが、悪さをしているのが、本社のシスコのルーターに問題があるのか、
NATのマシンにあるのか、全くわからない。
しかも、シスコのルーターの設定ファイル（コンフィグ）を持っていないため、
原因の切り分けができない。頭を抱えてしまう・・・ (--;;
NATのルーティングも何度も確認しているから設定ミスは考えにくい。
パケット経路だが、本当の所は勘違いをしていたのだが、この時は
全て把握していると思い込んでいた。
「システム奮闘記：その26」(ルーティング・デフォルトゲートウェイ)で
ルーターを構築してテストも行なっているため、
全て理解したと思い込んでいた。
| NATのルーティング |
|---|
ernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
XXX.YYY.ZZZ.A * 255.255.255.248 U 0 0 0 eth0
192.168.90.0 192.168.1.252 255.255.255.0 UG 0 0 0 eth1
192.168.0.0 * 255.255.0.0 U 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default XXX.YYY.ZZZ.R 0.0.0.0 UG 0 0 0 eth0
|
|
赤い部分が岡山行きのパケットの行き先はヤマハのルーターだという事を表している。
|
どう考えても、おかしいとは考えにくい。
午後3時、私は、埒があかないと判断した。
そこで、N社のYさんに「引き続き、こちらで原因を調べます」と言って、
とりあえずは、N社のYさん、H子さんには、帰ってもらう事にした。
さて、原因はルーティングにあると考えた私は、上司に依頼して、
NATマシンのルーティングを変えてもらう事にした。
もちろん、私の上司にルーティングの設定なんぞできるわけがないので、
メールでコマンドを説明して、コマンドを打ってもらう事にした。
| NATのルーティング |
|---|
ernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
XXX.YYY.ZZZ.A * 255.255.255.248 U 0 0 0 eth0
192.168.90.0 192.168.1.252 255.255.255.0 UG 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default XXX.YYY.ZZZ.R 0.0.0.0 UG 0 0 0 eth0
|
赤い部分が岡山行きのパケットは行き先を表している。
青い部分は「192.168.0.0」から「192.168.1.0」に変えた。
これにより、岡山行きのパケットが青い部分に反応して、
ヤマハのルーターへパケットが飛ばない事態になるのを防いでみた。
|
だが、何も起こらなかった・・・。
後でわかった話、上司は綴り誤りをしていたため、エラーを吐いて
何も変化が起こらなかったのだが、そんな事は、私には、知る由もない。
相当深刻な事態がNATで起こっていると想像してしまう。
もしかして、Linux のセキュリティーパッチが悪さをしているのではと思った。
だが、明日は広島営業所へ出張のため、帰る事もできない。
だが、フレームリレー回線を解約していないため、インターネットVPNが
使えなくても、フレームリレー回線を使えば、業務には支障はでない。
取り合えず、本社には事態報告のメールを送った。
幸い、岡山営業所には、2台のパソコンがある。
本社に戻ってから、VNCを使った遠隔操作で、 ping を始めとする
通信テストを行なうため、1台をインターネットVPNの回線につなげ、
もう1台は、基幹業務の関係から、フレームリレー回線に、つなげたままにした。
でも、ここで私の岡山での仕事は終わりではない。
AS/400と営業所のP-COMM（AS/400のエミュレーター）との通信を、
TCP/IPへ切り替える作業と、営業所のパソコンの不具合の解消などがある。
バックアップをとって、データを私のノートパソコンに移して、OSごと入れ替えて
ソフトを全部入れ替えていくと、時間がかかる。
何せ、Celeron333MHz RAM64M。遅い。
晩の10時近くになり、「こりゃ、終わりそうもない。」と思った私は
ホテルに電話をかけて予約を取り消した。
営業所で寝泊まりする覚悟をしたのだった。
作業が終わったのは、深夜2時だった。営業所のソファーで寝る事にした。
広島でも障害発生
8月6日の午前5時、ソファーから起きた。
ソファーだと熟睡はできないが、寝た事で体力温存はできた（と思う）
広島へ出発する準備などを行なう。
午前6時になり、タクシーを呼んで、岡山駅へ行く。
そして、新幹線に乗り、広島へ向かう。
朝、早いので自由席でも座れるかなぁと思ったが満席で座れない。
そこで、地べたにビニールを敷いて座った。
初めて乗るレールスター。時速285キロという高速運転する「ひかり」だ。
東海道新幹線の場合、「のぞみ」でも270キロが最高速度だけに、
山陽新幹線のレールスターは速い！
広島駅に着いて在来線に乗り換える。そして、最寄り駅についてから徒歩15分。
ノートパソコンから色々な装備を携えているため、車輪付きのバッグで、
転がして歩いていても、やはり重い。それに睡眠不足のため、体にこたえる。
そして、8時半に営業所に着く。
営業所のパソコンの不具合を解消するために、作業にとりかかる。
10時近くになって、N社の委託を受けた業者のSさんが来られた。
ルーターの設定作業を開始するが、Sさんは、手こずっている様子。
Sさんが四苦八苦されている所を、側で見ていると「大変な作業だなぁ」と
思ってしまう。多分、「早く設定を済ませないと」という焦りを感じていると思う。
私自身、今まで、システム導入のために、色々な設定を行なってきたが、
「はよ、してくれ！」と言われると、焦るし、プレッシャーになるのは
身を持って体験している。
そこで、缶コーヒを買ってきて、Sさんに、ごちそうをする。
色々、世間話をしながら、ネットワークの話をすると、驚くべき事実を知る。
なんと、Sさんはネットワーク技術者でなかった！！
話を聞けば、電話交換器の技術者の方で、ネットワークには詳しくない。
今回のIPSeCの設定で、使う暗号の種類が「3DES」なのか「AES」なのかも
知らないという。
上手に話をして、色々な事を聞き出す ← 誘導尋問かい！
どうやら、ネットワーク技術者でないのに、マニュアルだけを渡されて、
「設定してこい」と言われた感じだ。
| ネットワーク技術者は相当不足している実態を目の当たりにした |
|---|
私はSさんの事を「技術力がなさすぎ!」と言って批判する気は全くない。
むしろ「マニュアルを渡されて設定してこい」と言われ、不安になりながら
設定している姿を見ていると、同情したくなった。
私が、Sさんの立場なら「なんで、俺が、設定せんとアカンねん」と思うからだ。
マニュアルだけで設定できるのは、そのマニュアルが、非常にわかりやすくて
かつ内容が正確な場合だけだ。
少しでも不明な点があると、初心者の場合は、そこで立往生する上
例外処理が起こると混乱してしまう ← 経験者は語る (^^;;
そのため、マニュアルさえ渡せば、設定できるという安易考えを業者は改め、
ネットワーク技術者として、キチンと教育すべきだと思う。
そうでないと、いつまで経っても、ネットワーク技術者は育たないだけでなく
同じ事の繰り返しで、顧客からの「あそこは素人が設定しているのか」と思われ
顧客からの信頼を失う結果にもなると思う。
|
さて、IPSeC通信に、どういう種類の暗号が使われているのか、わからない。
すなわち、私の方で設定の状態は何も知らないという事になる。
そういえば、Yさんと打ち合わせの時、暗号は何を使うのか、
認証の時のハッシュは何を使うのかの話をしていないのを思い出す。
これでは、J社にシスコのルーターを握られるのと同じ現象だ。
設定内容は、私もある程度は知っておかないとマズイと思った。
さて、昼すぎになり、N社のYさんから電話がかかる。
Sさんは次の予定があるので、Sさんを帰らせて、N社の人が本社にやってきて
本社のルーターの設定の見直しと、遠隔操作で広島のルーターの設定を
行なうというのだ。
そこで、Sさんを見送って、昼飯を食べに行く。
近くの「お好み焼き屋」へ入る。広島風お好み焼きを食べる。
イカ天が入った物は初めてだが、なかなか美味しい。
15時くらいに、N社のYさんが本社に乗り込む。
そして、本社と遠隔で広島のルーターの設定を行う。
岡山と同じで、「広島→本社」への通信ができないままだったが、
他の通信は問題なく行えた。
私は、Yさんから進捗状況を聞きながら、営業所のパソコンの設定などを行なう。
午後6時に作業が終わる。だが、そのまま家には帰るわけにいかない。
「岡山→本社」、「広島→本社」への通信ができない原因を調べるため、
本社へ戻らねばならない。
普通なら、前日、ロクに寝ていないので、翌日に原因究明をする事を考えるが
NATが絡む話で、しかも、DNSなど重要なサーバーも兼ねている。
下手に日中に止めると、社内だけでなく、顧客にも迷惑がかかるため、
夜中の作業にせざる得なかった。
帰りは「のぞみ」を使う。
睡眠不足で、時々、睡魔が襲ってくるが、寝てはいけない。
なぜなら、新幹線で寝過ごしたら、大変な事になるからだ。
気がつけば、名古屋や東京だったら、シャレにならない。
さて、車内の掲示板に「ただ今、300キロ運転」と出ると、速いなぁと思う。
長時間、持続して高速走行する新幹線こそが、私は世界一だと思う。
それも正確なダイヤな上、安全性が抜群な新幹線こそ、世界一だと思う。
| フランスTGVはインチキ |
|---|
 |
上の写真は、だいぶ前に、私がフランスへ旅行した時の写真です。
時速300キロ走行というから速いと思いきや、ノロノロ運転をする。
不思議に思って、横にいたフランス人に、私のお得意のデタラメ英語を
駆使して聞いてみた。その人の話では、TGV専用線以外では
スピードが出せないため、ノロノロ運転をするという。
偉そうに新幹線より速いと言いながらも、300キロ運転は、
一部の区間だけで、その他の区間では、JRの在来線並の速度なのだ！
TGVのノロノロ運転は阪急宝塚線並です。知っている人は知っている
電車の遅さを表す表現技法(?)です。
|
なんとか熟睡せずに、新神戸を降りた。そして、一度、神戸の自宅に帰る。
なにせ、前日、ホテルに泊まれず、営業所に宿泊したため風呂に入っていない。
汗で体がベタベタ。夏なので悪臭を放ちかねない。
シャワーを浴びて、さっぱりする。しかし、前日から、ほとんど寝ていないため
胃が重たくて、晩飯を食べる気がしない。
そして、本社に向けて出発した。
iptablesを外して一時的に解決
8月6日、午後11時すぎ、フラフラの状態で、なんとか本社に到着する。
ほとんど寝ていないため、気力で持っている感じだ。
睡魔との戦いだが、精神が昂ぶっているのか、なぜか眠くなかった。
岡山出張時に、上司に依頼して、ルーティングを変えてもらったが
うまくいかなかった原因がわかった。
なんと、スペースを入れる所に、入れていなかったのだ！
すごく力が抜けた。これを正しく打てば問題解決だったのにと思いながら
ルーティングの変更を行なった。
| NATのルーティングを変更した |
|---|
ernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
XXX.YYY.ZZZ.A * 255.255.255.248 U 0 0 0 eth0
192.168.90.0 192.168.1.252 255.255.255.0 UG 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default XXX.YYY.ZZZ.R 0.0.0.0 UG 0 0 0 eth0
|
赤い部分が岡山行きのパケットは行き先を表している。
青い部分は「192.168.0.0」から「192.168.1.0」に変えた。
これにより、岡山行きのパケットが青い部分に反応して、
ヤマハのルーターへパケットが飛ばない事態になるのを防いでみた。
|
しかし・・・。
やはり通信ができない (TT)
紙を書いて、パケットの経路を考えて、あーでもない、こーでもないと考える。
だが、通信ができない原因が何なのか、全く掴めない。
解決できない焦りだけが生じる。そして、無気力感から激しい睡魔が襲ってきた。
床に寝そべって・・・
もう、アカン。このまま、寝てしまいそう・・・
と思った。
まどろみの中で、ぼんやり考えが浮かんだ。
「何か、ルーティングの設定がおかしいのは変な所をいじったせいだ。
それなら一度、NATマシンのOSごと入れ替えてみよう」
半分寝ている状態なので、メチャクチャな発想が浮かぶのだが、
追い詰められた時は、しらみつぶしの如く、何事も挑戦する必要がある。
何もしない場合だと何も得られないが、行動を起こすと、
解決への手掛かりが掴めるかもしれない。
床から起き上がって「よっしゃ、やったろか！」と気合いを入れ直した。
そして、OSから全て入れ替える。
iptablesの設定だが「めんどくさい」と思って、ザルの状態にした。
そして、簡単なルーティングの設定を行なって、岡山のマシンを遠隔操作で
動かして、本社にある AS/400 へ ping を飛ばしてみた。
見事、通信ができるようになっていた！
「iptablesの設定をしないと、マズイなぁ」と思い、設定を行なうと
また、岡山のマシンから、本社の AS/400 へ ping が飛ばなくなった。
この時、iptablesの設定に問題がある事がわかった！
まどろみの中、「OSを入れ替えてしまえ」というメチャクチャな発想と、
横着して、iptablesの設定をしなかったお陰で、原因になっている物を突き止めた。
拳法で「酔拳」があるが、これもまさしく「眠拳」だ。
時計の針は午前4時を指していた。
元気があれば、なぜ、iptables が悪さをしているのか調べる所だが、
2日間、ロクに寝ていないため、調べる気力がない。気力を使い果たした。
少し机の上で寝て、始発電車で帰る事にした。
フラフラの状態で家に帰りついて、その日は、一日中、ゴロゴロしていた。
原因はパケット経路にあった
さて、iptablesが悪さをしている所までは解明できたが、どの部分が悪さを
しているのかは不明だった。しかし、下手に、NATマシンを止める事ができない。
社内のネットワークが止まるため、盆休みまで何も触らなかった。
8月11日〜15日までは盆休みだが、私は11日〜14日まで電話当番で出勤。
盆休み中は、ある程度、システムを止める事ができる。
そこで、盆休みを利用して、原因の追求を始める事にした。
前日に、岡山営業所に頼んで、盆休み中は、岡山営業所のパソコンを1台だけ
立ち上げたままにしてもらった。
そして、なぜ、iptablesが悪さをしているのか、徹底調査を行なう事にした。
最初、SYNフラッド攻撃などの設定が悪さをしていると思い、
個々の設定を外して、岡山から本社の AS/400 へ ping を飛ばしてみたが
全く応答がない。
一体、何が悪さをしているのだろうかと考え込んだ。
そこで最小構成のファイヤウォールの設定を行なった。
| iptables の最小構成のファイヤウォールの設定 |
|---|
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT
iptables -A INPUT -p tcp --sport 53 -j ACCEPT
iptables -A FORWARD -i eth1 -s 192.168.0.0/16 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth1 -s 192.168.0.0/16 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/16 -j SNAT --to-source XXX.YYY.ZZZ.RRR
|
|
「 eth0 」はグローバル。「 eth1 」はプライベート側を表す。
|
最小構成のファイヤーウォールの状態にして、項目を追加していき
ひっかかる所で、原因を特定しようと考えた。
だが、最小構成でもダメだった (--;;
ここで、あーでもない、こーでもないと考えるが、全く何も浮かんでこない。
そこで、ふと閃いた。
本社のパソコンのデフォルトゲートウェイは、シスコのルーターだ。
VPN回線を使って岡山へ行くパケットは、シスコのルーターとNATを
経由して、VPNルーターへ運ばれる。
そのため、NATを通った際に、VPNルーターへ転送するから、例え、
内部へのパケット転送でも「 FORWARD 」を追加する必要があるのではないかと考えた。
そこで、次の設定を行なった。
| iptables の最小構成のファイヤウォール＋αの設定 |
|---|
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT
iptables -A INPUT -p tcp --sport 53 -j ACCEPT
iptables -A FORWARD -i eth1 -s 192.168.0.0/16 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth1 -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -i eth1 -s 192.168.0.0/16 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/16 -j SNAT --to-source XXX.YYY.ZZZ.RRR
|
「 eth0 」はグローバル。「 eth1 」はプライベート側を表す。
赤い部分は追加した項目。プライベート側のパケットをプライベート側へ
転送する際は、全て許可するという意味だ。
|
これで、成功するかどうかは、半信半疑だが、設定するのはタダでできる。
そこで、上の設定を行なって、岡山から本社へ向けて ping を飛ばすと
見事、応答が返ってきた！！
ようやく岡山から本社へ通信ができるようになった。
上の赤い部分を入れれば、問題なく通信ができるようになった。
だが、まだ問題が残っていた。
岡山から本社のパソコンへ tracert コマンドを使うと、
NATの部分だけ表示できない問題がある。（下図）
| 岡山から本社へtracertコマンドを使った場合 |
|---|
C:\WINDOWS>tracert 192.168.1.100
Tracing route to 192.168.1.100 over a maximum of 30 hops
1 1 ms 2 ms 2 ms 192.168.90.252
2 40 ms 39 ms 38 ms 192.168.1.252
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
このまま永遠に続く
|
岡山から他の営業所へtracertコマンドを使った場合は、
途中の経路が表示されない。（下図）
| 岡山から他の営業所へtracertコマンドを使った場合 |
|---|
C:\WINDOWS>tracert 192.168.3.254
Tracing route to 192.168.3.254 over a maximum of 30 hops
1 1 ms 2 ms 1 ms 192.168.90.252
2 38 ms 39 ms 39 ms 192.168.1.252
3 * * * Request timed out.
4 41 ms 42 ms 41 ms 192.168.1.254
5 141 ms 139 ms 139 ms 192.168.3.254
Trace complete.
|
|
青い部分が全く見えていない
|
そこで、上で書いた iptables の設定に追加設定をしてみた。
| iptables の最小構成のファイヤウォール＋αの設定 |
|---|
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT
iptables -A INPUT -p tcp --sport 53 -j ACCEPT
iptables -A FORWARD -i eth1 -s 192.168.0.0/16 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth1 -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -i eth1 -s 192.168.0.0/16 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o eth1 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/16 -j SNAT --to-source XXX.YYY.ZZZ.RRR
|
「 eth0 」はグローバル。「 eth1 」はプライベート側を表す。
赤と青の部分は、追加した部分。
赤は発信元と送信先がプライベートアドレスのパケットは転送を許可する部分。
青は、NATから発信されるパケットで、送信先がプライベート側の場合、
全てを発信できるようにしている。
|
すると、予想通り
見事、表示できた (^o^)V
| 岡山から他の営業所へtracertコマンドを使った場合 |
|---|
C:\WINDOWS>tracert 192.168.5.254
Tracing route to 192.168.5.254 over a maximum of 30 hops
1 1 ms 1 ms 2 ms 192.168.90.252
2 40 ms 41 ms 40 ms 192.168.1.252
3 43 ms 42 ms 40 ms 192.168.1.253
4 42 ms 39 ms 39 ms 192.168.1.254
5 113 ms 111 ms 158 ms 192.168.5.254
Trace complete.
|
これで原因が解決と思いたい所だが、まだ、解決できていない。
なぜなら、この設定を行なわなくても、「岡山→外部」、「岡山→他の営業所」
「本社→岡山」へは通信ができたからだ。
なぜ、「岡山→本社」に限って通信ができなかったのか、原因を探る必要がある。
そこで「岡山→本社」の通信ができなかった原因を探る事にした。
この時、私の頭の中では、パケットの流れは下図のようになると考えていた。
| 私の頭の中にあったパケットの流れ図 |
|---|
|
本社側のVPNルーターのデフォルトゲートウェイは、NATマシンなので、
VPNで結んでいる営業所以外のパケットは全てNATマシンへ行くと思っていた。
本社のマシンのデフォルトゲートウェイはシスコのルーターで、
シスコのルーターのデフォルトゲートウェイは、NATマシンなので、
上の図のようなパケットの流れになっていると思い込んでいた。
実際には、岡山からのパケットが本社のVPNルーターに到着した時、
同じネットワーク内の本社のマシンにパケットを飛ばすため、
NATへ飛ばす必要はなく、直接、本社のマシンにアクセスするのだが、
行きも帰りも同じ経路を通るという思い込みから、上図のような考えを持っていた。
実は、この編集を行なっている時に、「これは思い込みだ」に気がついたのだが
気がつかなかった場合、堂々と「理論的には上図のようになる」と書いていただろう。
|
だが、ふと、本社のパソコンのルーティングの状態を見てみる。
| 本社のパソコンのルーティングを見た時 |
|---|
C:\WINDOWS>route print
Active Routes:
Network Address Netmask Gateway Address Interface Metric
0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.133 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.1.0 255.255.255.0 192.168.1.133 192.168.1.133 1
192.168.1.133 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.1.255 255.255.255.255 192.168.1.133 192.168.1.133 1
192.168.90.102 255.255.255.255 192.168.1.252 192.168.1.133 1
224.0.0.0 224.0.0.0 192.168.1.133 192.168.1.133 1
255.255.255.255 255.255.255.255 192.168.1.133 0.0.0.0 1
|
岡山行きのパケットは、デフォルトゲートウェイのルーターを経由せずに、
直接、VPNの本社側のルーターへ飛ぶようになっている。
となれば、本社から岡山へ通信を行なった場合、通信パケットは、
デフォルトゲートウェイのルーターとNATマシンを経由していない事を意味する。
岡山に出張中、N社のSEのYさんが「戻りのパケットのルーティングが
うまくいっていないようです」の言葉を思い出した。
さて、本社から接続すると、最小経路で通信を行なう事を頭に入れて考えてみた。
そこで、岡山から本社のマシンへパケットを飛ばした場合、次のような
振る舞いをすると考えてみた。
| 岡山から本社へパケットを飛ばした際のパケットの振る舞いを仮定してみた |
|---|
 |
黄色は行きのパケット。水色は戻りのパケットの動き。
シスコのルーターは、本社のデフォルトゲートウェイの事です
|
岡山から出発したパケットは、本社のVPNルーターに入ると、
本社のマシンへ直接、パケットが飛ぶようになる。
そして、戻りのパケットは、本社のマシンに記録されている
デフォルトゲートウェイのルーター(シスコのルーター)へパケットが飛び、
そこからNATを経由して、VPNルーターへパケットが飛ぶという
振る舞いをしているのではと考えた。
さて、上の仮定が正しいかどうか確かめるために、NATの設定の変更を行なう。
| iptables の最小構成のファイヤウォール＋αの設定 |
|---|
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT
iptables -A INPUT -p tcp --sport 53 -j ACCEPT
iptables -A FORWARD -i eth1 -s 192.168.0.0/16 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth1 -s 192.168.1.0/24 -d 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -i eth1 -s 192.168.0.0/16 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/16 -j SNAT --to-source XXX.YYY.ZZZ.RRR
|
「 eth0 」はグローバル。「 eth1 」はプライベート側を表す。
赤い部分は、発信元のパケットが本社の場合で、送信先が社内の場合
全てのパケットを転送許可する設定。
|
さて、上の設定を行なって、岡山から本社に ping と飛ばしてみた。
見事に通信ができた!!
どうやら、予想が当ったようだ。
つまり、岡山からやってきたパケットは、NATを経由せずに、
直接、本社のマシンに届いているが、戻りのパケットは、デフォルトゲートウェイと
NATを経由している事を意味する。
なんだか、奇妙なパケットの経路だなぁと思ってしまった。
| 岡山から本社へパケットを飛ばした際のパケットの振る舞い（結果論） |
|---|
|
よくよく考えると、こういうパケットの動きになるのが普通だと気がついた。
最初、本社へ行くパケットは、NATのマシンを経由すると思っていたが、
あくまでも、VPNルーターのデフォルトゲートウェイがNATであって、
同じエリア内（本社のネットワーク内）へ向かうパケットは、
NATへ飛ばす必要がないため、直接、接続先へ行く事になる。
そして、接続先から応答のパケットを返す場合は、デフォルトゲートウェイの
シスコのルーターと、シスコのルーターのデフォルトゲートウェイのNATを
経由して、VPNルーターへ行く仕組みになる。
よく考えれば、上の図のようになるのは、当然の事だったが、
それに全く気づいていませんでした (^^;;
|
この時点では、iptablesの設定で、パケットの転送部分に問題があったと
考え、これで解決したと思った。
だが、iptablesの設定を見て、おかしい事に気づいていなかった。
それは、注意深く見ると、転送を表す設定が2つあった事だ。
| ここを見落としていた! |
|---|
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT
iptables -A INPUT -p tcp --sport 53 -j ACCEPT
iptables -A FORWARD -i eth1 -s 192.168.0.0/16 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth1 -s 192.168.1.0/24 -d 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -i eth1 -s 192.168.0.0/16 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/16 -j SNAT --to-source XXX.YYY.ZZZ.RRR
|
青い部分と赤い部分がパケットの転送に関する設定。
青い部分を見落としていたのだ。というよりも、この部分をプライベートから
グローバル側へのパケット転送の設定としか頭になかったため、
青い部分の意味を考える事はしなかった。
|
この見落としていた部分だが、この部分は、岡山と広島から本社へ接続できないが、
他の営業所には接続できる謎に大きく関係した部分だったが、
この時は、全く気づいていなかった。
この謎が完全に解明できたのは、事件が発生した4ヶ月後の12月だった。
このシステム奮闘記は、できるだけ時間の流れに忠実に書いているのだが、
あっちこっち話が飛ぶと、読んでいる人も混乱してくるので、
この問題を解消した経緯を先に紹介したいと思います。
さて、この原因を探るべく、8月以降も、全国行脚の合間に行う事にした。
まずは、「岡山→本社」への通信の場合、以下のようなパケットの動きを行う。
| 岡山から本社へパケットを飛ばした際のパケットの振る舞い |
|---|
|
そのため、NATの部分で、内部から内部への転送を許可する設定を行った。
しかし、「岡山→他の営業所」の通信は、NATの設定を行わなくても
通信が問題なくできていた。
| 岡山と他の営業所との通信のパケットの振るまい |
|---|
 |
ルーティングを考えれば、上図のようなパケットの流れになる。
だが、内部同士の通信で、iptablesの転送の設定ができていなかったと
思い込んでいた私は、NATを飛ばして、VPNルーターとシスコのルーター間で
直接、通信が行われていたのではと考えた。
|
さて、NATを飛ばして、ルーター同士が直接、通信を行っていると考えた。
そう考えると、NATを飛ばしてパケットのやりとりができるのかを考える事になる。
この時、RIPに目をつけた。
RIPというのは最短の経路を見つけ出すネットワークの機能だ。
さて、上の文章を見ると、いかにも知っているような書き方をしているのだが、
ミエを張っても、すぐメッキが剥がれるのがバレるので正直に書きますと
RIPなんて知りませんでした (^^;;
いつもの如く「知りませんでした」という、お決まり文句になってしまう。
RIPを知ったのは、実は、広島に、VPNを導入してから、数日後だった。
広島のVPNルーターに、ping を飛ばしたら、通信ができないというエラーが
返ってきた。
「なんで、ネットワーク的につながっている物なのに」と不思議に思ったので
N社に理由を聞くと「ルーターは30秒に1度の割合でRIPという機能が働いて、
最適経路を見つけ出すため、端末やハブが、ルーターについていないと、
経路検出ができずに、休止状態になってしまうので、ハブをつけてください」
と言われた。
そのやりとりで、私は「RIP」という言葉がある事を知った。
そして、あまり頼りにならない勘を働かせて、原因は「RIP」にあると考えた。
そこで、google先生を使って調べる事にした。
ルーター同士でルーティング情報を交換している話が書いていた。
そして、メトリック（ルーターのホップ数）が、より小さい経路が最適経路に
なるように、ルーターの情報が更新されていくという。
ちなみに、ホップ数とは「途中経由するネットワーク数」の事を言う。
もちろん、google先生で調べるまで、ホップ数が何か知りませんでした (^^;;
そういえば、以前から、本社の Linux から営業所へping を飛ばした時、
奇妙な表示が出ている事を思い出した。
そこで、本社から岡山まで ping を飛ばしてみた。
| 本社のLinux から岡山のマシンへ ping を飛ばすと・・・ |
|---|
[suga@server]# ping 192.168.90.102
PING 192.168.90.102 (192.168.90.102) from 192.168.1.149 : 56(84) bytes of data.
From 192.168.1.254: icmp_seq=1 Redirect Host(New nexthop: 192.168.1.253)
From 192.168.1.254: icmp_seq=1 Redirect Network(New nexthop: 192.168.1.253)
64 bytes from 192.168.90.102: icmp_seq=1 ttl=126 time=47.9 ms
From 192.168.1.253: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.252)
64 bytes from 192.168.90.102: icmp_seq=2 ttl=126 time=41.6 ms
64 bytes from 192.168.90.102: icmp_seq=3 ttl=126 time=41.2 ms
64 bytes from 192.168.90.102: icmp_seq=4 ttl=126 time=39.5 ms
|
赤い部分は Linux 側で設定しているデフォルトゲートウェイである
シスコのルーターよりも、NATマシンへパケットを飛ばす方が
ホップ数が少ないという意味。
青い部分では、NATへパケットを飛ばした場合の結果が出ている。
ピンク色は、VPNルーターへ直接、パケットを飛ばす方が
ホップ数が少ないという意味。
|
どうやら最適な経路を探している様子が伺える。
ここで、ふと似た例を思い出した。Windows98 で、routeコマンドを使った場合だ。
| 私の端末のルーティングテーブル(Windows98) |
|---|
C:\WINDOWS>route print
Active Routes:
Network Address Netmask Gateway Address Interface Metr
0.0.0.0 0.0.0.0 192.168.1.100 192.168.1.110
XXX.YYY.ZZZ.A 255.255.255.255 192.168.1.AAA 192.168.1.110
AAA.BBB.CC.DDD 255.255.255.255 192.168.1.AAA 192.168.1.110
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
192.168.1.0 255.255.255.0 192.168.1.110 192.168.1.110
192.168.1.110 255.255.255.255 127.0.0.1 127.0.0.1
192.168.1.255 255.255.255.255 192.168.1.110 192.168.1.110
AAA.BBB.CC.DDD 255.255.255.255 192.168.1.AAA 192.168.1.110
AAA.BBB.CC.DDD 255.255.255.255 192.168.1.AAA 192.168.1.110
224.0.0.0 224.0.0.0 192.168.1.110 192.168.1.110
255.255.255.255 255.255.255.255 192.168.1.110 0.0.0.0
|
デフォルトゲートウェイを設定しているのにも関わらず、
外部へ接続する場合、勝手にNATマシンがゲートウェイになっていたりする。
はじめ、これはMicrosoftの奇妙な現象かと思っていたが、もしかしたら、
正直にルーティングの状態を表示しているのかもしれないと思ったりもする。
|
LinuxとWindows98の現象を見て、最初、「これがRIPか」と思ったが、
そうでない事を知る。
ICMPのtype5の機能で、途中で最小経路を見つけた時に、Redirectという
応答が返って来る仕組みだ。
ping に限らず、最短経路が見つかった場合、ルーティングテーブルの
キャッシュに、一時的に、ルーティング情報が追加される。
Linuxの場合は、routeコマンドだけでは出てこないが
route -Cというオプションを付ければ、キャッシュの情報も出てくるようになる。
| route -Cコマンドを打った結果 |
|---|
Kernel IP routing cache
Source Destination Gateway Flags Metric Ref Use Iface
192.168.1.171 192.168.1.255 192.168.1.255 ibl 0 0 1 lo
192.168.1.131 192.168.1.255 192.168.1.255 ibl 0 0 1 lo
192.168.1.33 ccwww.kek.jp 192.168.1.253 0 0 1 eth0
192.168.1.33 dsp1211.toyosei 192.168.1.253 0 0 1 eth0
|
思わぬ発見をしてしまった (^^)
ところで、既存のシスコのルーターにRIP機能がついているのか
もしくは、RIPの設定がされているのか、知りたくなった。
そこで、コンフィグを入手するため、設定してもらったJ社に
「ネットワーク上で、何か障害が発生しても、責任の擦り付けになると
良くないので、早期解決と原因の切り分けのため、シスコのルーターの
コンフィグをください」と依頼した。
全然、コンフィグが送られて来ない。10月になっても来ないのだ (--;;
だが、イライラはしなかった。VPNの設定のため、全国行脚をしていたため、
RIPの事なんぞ、頭から離れていたからだった (^^;;
10月に、N社のFさんからパケットキャプチャの無料ソフト「 Ethereal 」を
紹介してもらった。
本社のパケットキャプチャをしてみると、偶然、シスコのルーターが
RIPのパケットを出しているのを発見した！！
| シスコのルーターからRIPのパケットが出ている様子 |
|---|
 |
ここで、本来ならヤマハのルーターからも、RIPのパケットが飛んでいる事を
確認しておく必要があるのだが、FさんからRIPの話を聞いていたため、
確認もせずに、本社のVPNルーターからもRIPのパケットが飛んでいる物だと
思い込んでしまった (^^;;
そのため、下図のように、ヤマハのルーターと、シスコのルーターが
経路情報の交換を行っていると考えた。
| RIPの働き |
|---|
 |
そのため、岡山と他の営業所との通信の場合、パケットは、
わざわざNATを経由しなくて大丈夫という最適経路を通っているのだ！
| RIPのために、NATを経由しなくても通信ができる |
|---|
 |
ここで、もう一つ、わからなかった事がわかった。
「メトリック」の意味だった。
NATマシンで、routeコマンドを使うと、ルーティング情報が出てくる。
| Linuxルーターのルーティングテーブル |
|---|
[root@penguin root]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
192.168.20.0 * 255.255.255.0 U 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
|
ここでは、直接、LAN内で接続されているため、メトリックは「0」になっている。
メトリックとはルーターを越えた場合に出る数字なので「0」になっています。
本社とインターネットの間にあるヤマハルーター（RTA55i）のコンフィグを見ると
メトリックが「1」になっている。
| RTA55iのコマンド設定の一部 |
|---|
ip lan1 intrusion detection in on reject=on
ip lan1 intrusion detection out on reject=on
ip lan2 routing protocol none
ip lan2 rip listen none
ip route default gateway pp 1 metric 1
provider type isdn-network
provider lan1 name LAN:
provider lan2 name PPPoE/1/3/4:
|
|
赤色の部分がルーティングの部分。メトリックが「1」になっている。
|
メトリックの数字は変更できる。数を大きくする事により、最適なネットワークの
経路を指定する事ができる話は、本で読んで知識としては知っていたが、
それが「なぜ、最適なネットワーク経路になるのか?」が理解できていなかった。
だが、今回、次の例を見て「なるほど！」と納得できた！！
| メトリックの数が変更できる理由(1) |
|---|
 |
上図のような場合、全てのルーターに設定されているメトリック数が「1」なら
ルーター越えの少ない経路を選んでしまう。そのため、遅いISDN回線を
選んでしまう事になる。
|
上図のネットワーク経路の場合、どう考えても、100Mの光回線を使う方が、
通信速度が速いはず。だが、ルーターのメトリック数が「1」で固定してしまうと
ISDN回線を選ぶ現象が起こってしまう。
そこで、下図のように、メトリック数を状況に応じて変更する事ができる。
| メトリック数が変更できる理由(2) |
|---|
 |
この場合、ISDN回線を使う場合、メトリック数を「5」にする事により、
遅いISDN回線を使ってしまう事を防いでいる。
光回線の場合、ルーターを3つ越える必要があるが、メトリック数の合計が「3」
なので、ネットワーク的には「5」よりも良い事を意味している。
|
RIPがあるお陰で、目的地までのメトリック数を把握でき、
しかも、最適な経路を通る事ができるので、凄い技術だと感心する。
ちなみに、RIPは動的ルーティングの部類に入る。
これまで、私は「うちの会社は静的ルーティングのみで十分」と思っていたし
動的ルーティングとは無縁だと思っていたが、今回のRIPの話で、
知らず知らずのうちに、動的ルーティングの恩恵を受けていると思った。
うーん、ネットワークの世界は奥が深い
これで謎が解明できたと思った私。
だが、重大な事を調べていないままだった。
前述しましたが、VPNルーターが、RIPのパケットを送受信しているかだった。
実は、本社でパケットキャプチャをしている時に、シスコのルーターからは
RIPのパケットが飛んでいるのに、VPNからは飛んでいないのが不思議に思った。
だが、RIPで動的ルーティングが成り立っていると解釈した場合、
辻褄が合うので、調べようとしなかった。
だが、いい加減な調査結果を載せるわけにいかない！！
話の辻褄を合わせるために、その場をゴマ化すため、適当な理由を書いてしまい、
あとで間違いだとわかると・・・
ツッコミの集中砲火にあうのは確実！！
あとで訂正や再調査を行う方が手間なので、調べる事にした。
そこで、本社のVPNルーターのコンフィグを見てみると・・・。
VPNルーターは、RIPのパケットの送受信を拒否している
| RIPのパケットの送受信をしない設定 |
|---|
ip lan1 address 192.168.1.252/24
ip lan1 mtu 1500
ip lan1 rip send off
ip lan1 rip receive off
|
赤い部分がRIPパケットを送信しない設定。
青い部分はRIPパケットの受信しない設定。
|
これを見た瞬間、RIPのお陰で「岡山→本社」への通信ができていたという
仮説は完全に崩れ去った (TT)
色々、時間をかけて、RIPの事を調べたのに、全てが水の泡になってしまった。
これで話は、完全に振り出しに戻った。
しかし、調べたくても、手がかりがない。
いい加減な事を書くとツッコミが来るが、逃げるだけならツッコミが来ないので
そこで、伝家の宝刀として「事務員だから、わかりませーん」ということで、
逃げ切る事を考えた。
しかし、謎のまま残しても気持ちが悪いだけなので、調べる事にした。
google先生で調べると、Linuxの設定で、次のファイルがある事を知った。
/proc/sys/net/ipv4/conf/*/rp_filter
そのホームページの内容によれば、パケットの行きと帰りの経路が違う場合に、
パケットの受け取りを拒否する設定らしい。「0」は無効で「1」が有効だ。
文脈から、どういう事を意味しているのか考えてみた。
そこで考えついたのが、「岡山→本社」への通信のパケットが、行きと帰りでは
別経路を通っているため、NATの部分でパケットの受け取り拒否をしている
可能性があるという事だ。
| 私が立てた仮説 |
|---|
 |
eth0側から出たパケットがインターネットのサーバーへ接続して
戻りのパケットがeth1側についた場合、行きと帰りの経路が違うため
上図のような場合、パケットは破棄されると考えた。
|
上図で解決の糸口を考え付いたのは、中継しているサーバーでも、
行きのパケットだけが通らず、帰りのパケットだけが通過する場合も
パケットを破棄しているのではと考えた。
詳しくは、RFC1812にあるのだが、早く結論を見たい私は、RFC1812を読まずに、
実験を行う事にした。
プライベートアドレスのデバイスは、eth1なのだ、
そこで、/proc/sys/net/ipv4/conf/eth1/rp_filterの
設定の状態を見ると「1」の有効になっていたので、「0」の無効にする。
そして、iptablesの設定を、8月の岡山で「岡山→本社」の通信ができなかった
状態にして、実験を行った見たが・・・
それでも、通信ができへん (TT)
この仮説もハズレだった。
あとで、わかった話だが、実は、rp_filterの設定の意味は、
次のような事だった。
| rp_filterの設定の本当の意味とは |
|---|
 |
rp_filterの設定は、IPスプーフィング対策の設定だった。
上図のように、eth0側のネットワークアドレスが 192.168.3.0/24の場合、
反対側にある、eth1側からマシンにやってくるパケットで、
発信元が192.168.3.10のようなIPだった場合、明らかにおかしいはず。
そこで、eth1側からマシンやってくるIPで、192.168.3.0/24に該当するIPの場合
パケットを破棄する事を、IPスプーフィング対策という。
|
さて、話は、また、振り出しに戻った。
全く考えられる原因が思いつかないし、google先生で調べても、
同じような症例が見つからない。諦めかけた時だった。
ふと、iptablesの設定を見てみたら、「あれっ？」と思った。
iptables の最小構成のファイヤウォール＋αの設定
「岡山→本社」が通信可能になった場合の設定 |
|---|
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT
iptables -A INPUT -p tcp --sport 53 -j ACCEPT
iptables -A FORWARD -i eth1 -s 192.168.0.0/16 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth1 -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -i eth1 -s 192.168.0.0/16 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/16 -j SNAT --to-source XXX.YYY.ZZZ.RRR
|
「 eth0 」はグローバル。「 eth1 」はプライベート側を表す。
青い部分は、元々、設定にあった内部から発信されたパケットの転送許可の部分。
赤い部分は、「岡山→本社」の通信を可能にするために追加した部分。
|
これを見て、「なんで、最初から内部から発信されたパケットは、青い部分で
転送許可しとるのに、赤い部分を追加せんとアカンねん」と思った。
だが、青い部分の設定を、よーく見ると、気になる部分を発見した。
| 私が気になった場所 |
|---|
iptables -A FORWARD -i eth1 -s 192.168.0.0/16 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
|
ピンク色の部分が、私が気になった場所だ。
この場合、内部から内部へのパケットの転送でも、ピンクの部分の条件を
満たさないと、転送されない事になる。
|
この時、「岡山→本社」の通信パケットの振るまいは次のようになっている。
| 岡山から本社へパケットを飛ばした際のパケットの振る舞い |
|---|
|
「岡山→本社」の通信の際、NATにやってくるパケットは、
戻りのパケットしかなく、最初の接続確立のパケットは通っていない。
もしかすると、戻りのパケットしかNATを通らないのが問題ではないかと考えた。
そこで、iptablesの設定で、ESTABLISHEDの意味を調べ直した。
すると、私の予想は当っていた。
ESTABLISHEDは、接続確立要求のパケットに対する応答のパケットの意味だ。
この設定は、接続確立要求のパケットが通過していないのに、
応答のパケットだけがやってくると、おかしいという事で、
パケットを破棄するようになっている。
| 「岡山→本社」の通信ができなかった真相 |
|---|
 |
NEW,ESTABLISHED,RELATEDのパケットを転送させる設定だったため、
応答パケットのみの通過は、NATで破棄されるようになっていた。
そのため、応答のパケットを通過させるために、以下の設定が必要だった。
iptables -A FORWARD -i eth1 -o eth1 -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT
これを追加する事により「岡山→本社」への通信が可能になった。
|
これにより、謎だった事が解明できた。
そして、「岡山→他の営業所」の通信ができていた理由も、わかった。
| 「岡山→他の営業所」の通信ができた真相 |
|---|
 |
本社のVPNルーターの場合、デフォルトゲートウェイがNATになっているため
本社以外へ行くパケットは、NATを経由するようになっている。
岡山から他の営業所へ通信を行う場合、一度、接続確立要求のパケットが
NATを通過しているのチェックしている。
そのため、戻りのパケットがやってたら、パケットの通過を許可している。
|
凄く回り道をしたものの、真相がハッキリして良かったと思う (^^)
それにしても、もう少しで、RIPが原因と断言して、大ウソを書く所だった。
粘り強く原因の究明は行うものだと思う今日この頃。
一難去って、また一難の繰り返し
話は、「岡山→本社」と「広島→本社」の通信ができるようになった
8月の時点に戻します。
さてさて、なにはともあれ、パケットの経路の問題は解決した。
N社のYさんは「今後は、円滑にいくと思います」と言った。
だが、Yさんは東京へ転勤になった。後任にFさんが担当になった。
Fさんは幸か不幸か、仕事とはいえ、なんと問題発生の疫病神に呪われた
私の相手をしないといけなくなった。
しかも、私にとりついた疫病神は伝染するらしく、Fさんにも取り憑いたのだ！
というわけで、まだまだ問題発生から解放されない話を紹介していきます (^^)
千葉営業所
8月27日、千葉営業所の設定を行う。
所長曰く「NTTの人によれば、ここはADSLがギリギリ開通できた所だったよ」
今、思えば「伝送損失が56dB」なので、ホントにギリギリだ。
伝送損失の話は、後述しています。
ここでVPN通信で奇妙な事が起こった。
千葉から ping を使って、1000バイト以上の大きなパケットを、
うちの会社のDNSサーバーにパケットを飛ばしても返答がない・・・。
岡山・広島では見られなかった現象だった。
（実際は、たまたま岡山・広島で確認できなかっただけなのだが・・・）
N社の依頼で来ていた作業員の方が「どうしましょうか」と言ってきた。
この時、私は「NATに原因があるかも」と自分を疑ったので、
作業員の方には「うちに原因があると思いますし、ネットワークの接続には
支障が出ていませんので、大丈夫です」と答えた。
しかし、色々、触っている間に、ヤフーやMSのサイトが見れなかったりした。
所長に「少し問題があります」と、見れないサイトがある話をしたら
「キャッシュに入ってないから遅いだけやろ。放っといたら大丈夫」と答えた。
この段階では「NATに原因があるから調べておこう」と軽く考えていた。
千葉出張で「IT担当者は現地へ行かないとアカンなぁ」と思った。
営業所のパソコンの設定状況が、遠隔操作のVNCだけだと把握できないからだ。
以前から千葉のプリンターが印刷できなかったり、メモリ不足になって
稼働しない現象が起こっていた。
以前から、何度も所長から「なんとかならんのか」と言われたので、
その度に、VNCを使って遠隔操作を行い、仮想メモリのディスクパーティションを
変更したりしたが、未解決のままだった。
しかし、OSの入れ換えの時に、プリンターが認識しないため、
おかしいなぁと思い、パソコンのBIOS設定を見てみると
なんと、USBの設定がオフになっていた！！
だった (^^;;
BIOSの設定内容は、VNCでは、わかるわけがない。
その前に、BIOSの設定がオフになっているのに、よくプリンターが動いていたと
思うと妙に感心してしまう。非常に謎な現象だった。
謎の接続困難が続く
千葉から帰ると、岡山から「時々、Webが見られへんけど」と電話がかかってきた。
この時点では「NATが原因」と思っていたので、考えられる原因を考えた。
そこで、SYNフラッド攻撃の設定が悪さをしていると考えた。
実際、この設定を行っていると、ホームページへの接続に時間がかかる。
そこで、iptablesの設定で、次の設定を外す事にした。
| iptablesの設定で、外した部分 |
|---|
iptables -N syn-flood
iptables -A syn-flood -m limit --limit 1/s --limit-burst 8 -j RETURN
iptables -A syn-flood -j LOG --log-prefix "iptables syn-flood : "
iptables -A syn-flood -j DROP
iptables -A INPUT -p tcp --syn -j syn-flood
iptables -A FORWARD -p tcp --syn -j syn-flood
|
|
SYNフラッド攻撃の対策の部分を外した。
|
これを外した時、岡山では「見れるようになった」と言ったので
私は「これが原因だったのか」と思った。
確かに、この設定を外せば、外部のサイトへ接続するのに早くなった。
実際に、iptablesのログを見ると、社内から社外へ接続する際に、
SYNフラッド対策のフィルターにひっかかっているケースが結構あった。
実は、本当の原因は別にあったのだが、この時点では解決できたと思った。
これで安心だと思いきや、今度は、千葉から「インターネットにつながらないぞ」
という連絡がやってきた。
千葉の話を聞くと、メールの接続も遅かったり、つながらなかったりするという。
問題なく接続できるのは、AS/400 だけだという。
インターネットの閲覧は社外で、メールサーバーはグローバル側にある。
ここまでの報告を聞いて共通していえる事は、グローバルアドレスのホストへの
接続ができない事があるといえる。
そこで、私は次のように考えた。
「プライベート同士の通信は問題はないが、グローバルへ通信を行なうと問題がが発生する」
早速、N社のSEのFさんと連絡を取り合う。
Fさんは遠隔操作で、千葉のルーターを調べてくれたが、原因が掴めない。
そこで、詳細なログをとる事にした。
今回は外注しているため、営業所から「つながらないぞ」と言われても、
「今、業者に調べてもらっています」という逃げが使える ← おい (^^;;
だが、無責任な態度をとり続けるわけにいかない。対処療法を考える必要があった。
通信ができない問題が、すぐに解決できるとは限らない。
解決が遅れれば、それだけ業務に支障が出てくるからだ。
この時点で、わかっていた事は、「営業所 ⇔ 本社」の通信は
問題なくできている事だった。
実は、「営業所 ⇔ 本社」の通信も時々、問題が出ていたのだが、
この時点では、営業所から連絡がなかっただけに、問題に気がつかなかった (^^;;
そこで考えたのが、メールゲートウェイの構築と、プロキシーサーバーの構築だ。
この時点では私は社内（プライベート同士）の通信は問題なくできると
考えていたので、ならば、メールサーバーをLAN内部に移設して、
グローバル側にメールゲートウェイを設置する事と、LAN内部にプロキシーを設置し
プライベート同士の通信にしてしまえば、問題が解決できると考えた。
| メールゲートウェイ構築の内容 |
|---|
 |
メールゲートウェイの話は「システム奮闘記：その32」をご覧ください。
(Postfixでメールサーバー構築)
これでメールが読めない問題は、とりあえずは大丈夫だろうと思った。
プロキシーサーバーの構築といきたかったが、ここで自然災害の影響を受ける。
台風が近づいていたので、電車が止まるまでに帰らざる得ない！
翌日は、広島・福岡出張なので、プロキシーサーバーの構築をしたかったのだが
台風には勝てずに、この時点での構築を断念した (--;;
広島・福岡
9月7日、福岡営業所のVPN設定のため出張する事になった。
その前に、広島でプリンター関連の不具合が出たという事で、
まずは、広島へ立ち寄る事にした。
広島で、AS/400で使っているプリンターの不具合を見た。
どうやらセンサーがやられているみたいで、とても私では対応できない内容だった。
しかも、経費節減で保守契約を切っているため、修理を依頼するのに費用がかかる。
本社に稟議を上げるしかないと思い、不具合対策を断念した。
さて、広島で、VPNの通信を見てみる事にした。
なんと、広島でも千葉と同じ現象が起こっていた。
それも、ホームページで見れる所と、見れない所があった。
なぜか、http://www.microsoft.com/japan が見れない！！
いくら私が反MSの人間だからといって、うちの会社からMSへアクセス
できないようになっているとは、到底、考えられない！！
N社のSEのFさんとやりとりが始まる。
見れたり、見えなかったりで、原因が全くわからない。
Fさんは色々、ルーターの設定を変更したみたいだが、それでも解消されない。
Fさんから「本社からインターネットに接続されている RTA55i のルーターの
設定を見てよろしいでしょうか」と申し出があった。
私の設定した内容が見られるの・・・ (^^;;
しかし、私は本職でもないし、ましてやネットワークの専門家でもないので、
高度な設定ができていなくても、おかしな設定があっても・・・
本職に見られて恥ずかしい事はないのらー！！
むしろ、おかしな設定があった場合は、タダで指摘してもらえるので
Fさんに設定を見てもらう方が得策だ。
Fさんが遠隔操作で、RTA55i のルーターの設定を見る事になった。
そして、Fさんから「LAN側で侵入者検知の設定になっていますが」という
電話がかかってきた。
| RTA55iの設定状態(Web上での設定画面) |
|---|
 |
確かに、WAN側で侵入者検知の設定をして、LAN側でも設定を行うのも変な話だ。
Fさんは、この設定の部分に問題があると思ったようだ。
Fさんが「設定を外しても構いませんか」と聞いてきたので、
私は「どーぞ、お願いします」と答えた。
しかし、設定を外したのにも関わらず、何も改善されなかった。
そこで、Fさんが「RTA55iで、ログを採りたいのですが」と言ってきたので、
私は「どーぞ、お願いします」と答えた。
我ながら、丸投げIT担当者ぶりには感心してしまう (^^;;
そして、Fさんは「今度、名古屋の設定の時に、御社の方へ行き、
パケットキャプチャを行って、調べてみます」と言った。
私は「これで解消できるかも」と思った。
心の中では「私が原因だったら、人騒がせな話になるなぁ」と思いつつも
「どっちが有罪でも原因がわかって解消できれば良い」という気持ちが強かった。
例え、私の設定が原因だったとしても
事務員に難しい設定は、わかりませーん (^^)
という手段を使って逃げる事ができるからだ。
広島での作業を終えて、そして、福岡へ行く事にした。
「のぞみ」がなかったので、レールスターに乗る。
車内掲示板に「時速285キロ」と表示される。速い！！
それに指定席や自由席でも、通路をはさんで2席と2席で、ゆったりした
感じがする。山陽新幹線に乗る時は、レールスターに乗ろうと思った。
夕方、博多に着いた。
| 「博多」と「福岡」についての余談 |
|---|
博多っ子に対して「福岡」を強調してはいけない。
なぜなら、福岡という地名は、博多固有の物でないからだ。
「福岡」の名前の由来は、黒田如水(官兵衛)が博多の地を治めた時に始まる。
元々、黒田家は岡山の武将だった。そして、郷里の地名「福岡」をとって
「福岡藩」と勝手に決めた事に始まる。
福岡市の市名を決める際も、どちらにするかでモメた経緯がある。
明治22年に、当時の福岡知事が「福岡市誕生」と告示した事が発端だった。
それに対して、博多っ子が「福岡」という名前に反発。
福岡市議会で「博多市」への改名の投票が行われる事となったが、
票が真っ二つに割れたため、当時の市議会議長の職権で「福岡」に決めた事がある。
この問題の1年前に、九州鉄道(現・JR)は駅名に、固有の地名の「博多」をとった。
市名は「福岡」で駅名は「博多」で、仲良く2つを立てている感じがあるのだが、
「博多」と「福岡」の論争は、今でも受け継がれているみたいだ。
|
広島で昼飯を食う余裕がなかったので、空腹だった。
福岡駅付近の魚介類の美味しそうな店に入って、刺身定食を食べる。味はまぁまぁ。
そして、福岡営業所に向かった。
既に、N社によるルーターの設定は終わっているので、後は、パソコンの設定だ。
だが、OS入れ換えから行うため、時間がかかる。
事務員さんのいる営業所なので業務に支障が来ないように、夜中作業だ。
晩の9時すぎ、所長夫妻がやってきた。
ドリンク剤、おやつなどの差入れをしてくださった。
IEのバージョンアップの際、MSのサイトからダウンロードを行うのだが、
VPN回線だと、広島同様、MSのサイトに接続できない。
仕方がないので、フレームリレー回線でダウンロードするのだが・・・
メチャクチャ遅いのら！！
1時間ぐらい、別の作業もできないので、他の事をして時間を潰すしかない。
だんだん、睡魔にも襲われる。夜勤になる場合は、夕方から出社するのだが
その日は、広島で作業が入っていた事もあって、朝早くに家を出ている。
さすがに、眠い・・・。
そこで、板張りの部屋へいき、横になって、仮眠をとる。
2時間ぐらい寝て、起き上がる。そして、作業の続きを行う。
朝になった。睡眠不足でフラフラだった。
こういう時は、無理にでも、気分を高めないと、ぶっ倒れてしまう。
営業所の人達が出社してきた。高揚した気分で対応するので、
みんな「えらくテンション高いなぁ」と言う。
10時になっても、AS/400などで、問題が起こっていないので、
大丈夫だと思い、営業所を出る事にした。
体自体はフラフラだが、このまま帰るのは、もったいない。
そこで、この奮闘記をキッカケで知り合いになった石本エージェンシーの
山田さんにお会いする約束をしていた。
山田さんと会い、黒豚のしゃぶしゃぶを、ごちそうになる。
豚肉が旨い！！ 九州まで来た甲斐がある。
その後、システムの話、AS/400から、VPNの話など、色々な事で盛り上がった。
そして、のぞみに乗って神戸の自宅まで帰った。
営業所でホームページが閲覧できない問題点の整理と確認作業
営業所から、MSなどのサイトへアクセスできない問題が解決できない。
さて、N社のFさんが来社して、パケットの流れを確認する事になった。
ここまででハッキリしている現象は次の通りだった。
| 明らかになっている現象 |
|---|
| (1) |
プライベートアドレス同士の通信は問題なし |
| (2) |
営業所から閲覧できないホームページがある |
以上の事から、本社のVPNルーターとNATの間に問題が発生しているという
感じだった。
私は「どっちが原因でも、ええから、はよ解決してくれ！！」と祈りながら
Fさんの様子を見守る事にした。
Fさんは、本社のルーター間の部分に原因があると考えていたので、
次の2つのパケットキャプチャを行った。
まずは社内LAN内(プライベートIP領域)での採取をする事にした。
| パケットキャプチャー：その1 |
|---|
 |
グローバルIP領域でのパケットを採取してみる。
| パケットキャプチャー：その2 |
|---|
 |
上の2つの事を行いながら、営業所から見れないホームページを
開いてもらい、パケットの流れをキャッチする事になった。
そして、NATに原因があるかもしれないという事で、NATで設定している
iptablesのファイヤーウォール機能を全て外して、営業所からホームページを
見てもらった。私は「ついに最後の審判の時がやってきた」と思った。
そして結果は・・・
大天使ミカエルが私に微笑んだ！！
NATが原因ではなかったため、私の無罪が確定した。
だが、うれしくない無罪だった。なぜなら、原因がわからずじまいだったからだ。
「有罪でも、ええから解決してくれー!!」と思っていただけに、
がっかりだった。
Fさんは「とりあえず、今日のキャプチャの結果を解析します」と言った。
続けて「明日、名古屋へ行かれました際は、MTUのサイズを変更して、
通信ができるかどうかの、ご確認をお願いします」と言われた。
犯人はMTUにあるようだ。
だが、私の無罪が確定した事により、全てが振り出しに戻った。
そのため、一体、どこから原因を探れば良いのか、わからなくなった (--;;
| 私はキリスト教徒か? |
|---|
最後の審判や大天使ミカエルの話題を出したので、
私の事をキリスト教徒と思う方がいても、おかしくないだろう。
実は、12月24、25日だけ、キリスト教徒です！！ ← 典型的な日本人。
普段は、旧約聖書や新約聖書にツッコミを入れる所を探していたり、
路上でしつこく勧める宣教師に対して「イヴって、アダムの肋骨からできた
クローン人間やけど、キリスト教ではクローン人間はOKなの」とか
「ロトは近親相姦で子孫を増やしたけど、キリスト教って、
近親相姦を認めているの?」と言って、宣教師を困惑させて追い払う。
特に、旧約聖書は、キリスト教以外にも、ユダヤ教、イスラム教の聖書でもある。
私の旧約聖書に対するツッコミに、知り合いのイスラム教徒も爆笑していた。
もちろん、仏教の事にもツッコミを入れたりしている。
ただ、神道は止めておいた方が無難かも。軍歌を鳴らした緑の宣伝カーがやってきて
「神国日本の・・・」という抗議を受けるかもしれないから (^^;;
|
プロキシーサーバーでごまかす
私の無罪が確定しても、営業所から外へ通信できないとなると
業務へ支障がでてくる。
この時点では「営業所 ⇔ 本社」の通信は、問題なくできていると思っていた。
そこで、本社のプライベートアドレスのエリアに、プロキシーサーバーを
構築して、外との通信が行えるように設定を行った。
| プロキシーサーバー構築の内容 |
|---|
 |
これだと「営業所 ⇔ 本社」の通信になるので、問題が解決できると考えた。
ここで暴露！！
もちろん、設定は本の丸移しでーす！！
実際は、じっくりと設定内容を見たりしたいのだが、時間がなかったので
突貫工事（要するに本の丸移し）を行った (^^;;
まぁ、問題なく稼働するので「事務員は、これでいいのだ！！」と逃げます。
そして、見れないホームページがあると言ってきた営業所に
「プロキシーの設定をしてください」と言って、設定方法を説明した。
この時点では、これで一時的に回避できると思っていたので、
一段落ついたと思った。
名古屋営業所
9月11日、名古屋営業所へ向かう。
日中に不具合対策のため、OSの入れ替え作業を行うと業務ができないが
徹夜は辛いので、土曜日に作業をする事にした。
これだと業務を止める事もなく、しかも、徹夜をしなくても大丈夫だ。
名古屋営業所のパソコンのMTUを変更してみる事にする。
ping を使って、外部へパケットを飛ばす際の最適値を求めると「576」だった。
「これって、Windows98のMTUの初期値やん」と思った。
しかし、この時は、MTUを色々変えても問題なく通信ができたので
MTUの最適値が、いくらなのかわからない。困ったもんだと頭を抱える。
この時、もしかして PMTUブラックホール問題が起こっているのではと考え始めた。
しかし、ADSL回線やN社のネットワーク上で、MTUサイズの小さい部分が
あると考えにくい。
そのため、PMTUブラックホール問題が起こっている事までは考慮していなかった。
PMTUブラックホールとルーターの設定対策
いくらN社に丸投げしていても、問題が解決できないと、営業所に迷惑がかかる。
そこで、ついに私も動く事にした。堕落した「丸投げIT担当者」から
厄介(?)な・・・
口出しIT担当者!
に変身する事になった。
だからといって、自力で解決できる実力はない！ ← キッパリと断言！ (^^)
そこで、困った時のBLUE頼みで、BLUEのMLに質問する事にした。
| 私が投稿したメール |
|---|
菅＠Linux好き事務員です。
こんにちは。
困った時のBLUE頼みです m(--)m
実は、本社と営業所間の回線をフレームリレー回線から
インターネットVPNへの切り替え作業を行っています。
方式は、IPSeC方式で、本社はヤマハの RTX1000
営業所は、 RT105eを使っています。
営業所から本社や外部のホームページなどへ
時々、アクセスできない事態が発生しました。
ネットワークの構成ですが、
営業所 ←（IPSeC）→ 本社 ←(ADSL)→ 外部
という感じで、必ず外部へ出る際は、本社を経由させています。
MTUが怪しいということで、営業所から本社に、うまくつながらない時に
ping を使いまして、MTU最適値を調べましたら、576でしたので、
営業所のパソコンのMTU値を 576にしました所、トラブルが起こらなくなりました。
しかし、はっきりとしました原因がわからないため、MTUが犯人なのか
それとも、たまたまMTUを変更した後、つながっているだけで
また、通信エラーがでる可能性があるのか、わかりません。
営業所のパソコンは Windows98 で、MTU自動調整機能はついていません。
もし、よろしければ、同じようなトラブルを、ご存知の方で、
原因や対処法を教えていただけませんでしょうか m(--)m
|
すると、後藤さんからお返事をいただいた。
| 後藤さんからのお返事 |
|---|
VPN トンネル自身はきちんと張れているのに、外部との通信ができない
時があるという事でしょうか？
特定の相手とだけうまく通信できないのか、または同じ相手に対して
うまくいく場合とうまくいかない場合があるのかなどで話が多少違って
くるかとは思いますが、以下の FAQ に該当するのかも知れません。
http://www.rtpro.yamaha.co.jp/RT/FAQ/IPsec/faq_4_b.html
rt100i-users ML で過去メイルを検索すると、似たような話題がいくつか
出てきます。'RTX1000', 'MTU' をキーワードにしてアーカイブ検索すると
出てくるのではないかと思います。
個々の PC の設定をいじるという対処方法もあるでしょうが、rt100i-users
の過去メイルにあるように、VPN トンネルの MSS サイズを調整するなどして
VPN 機材側で調整した方が、PC の複数設置とか、今後の PC の入れ替えを
考えた場合には運用上、楽ではないかと思います。
ところで、Path MTU Discocvery では、私も数年前にドはまりした事が
あります。(^^;
RT シリーズも IPSec も関係ないのですが、とある顧客先でメイルサーバの
OS を 2000年問題対応のためにバージョンアップしたところ、メイルが
問題なくやりとりできるサイトと、パケットが糞詰まりを起こして、
事実上通信できないサイトがでてきたのです。
他は何も変更していないのだから、お前のところの問題だろう。と、なった
のですが、私にしてみれば「そんなバカな」状態で、とても苦労しました。
この時の問題の原因は、OS をバージョンアップした事により Path MTU
Discovery が有効になっていたのですが、途中に挟まっていた帯域制御用の
製品で Path MTU Discovery 用のパケットがはたき落とされていたのです。
この時は、OS のパラメタを変更して Path MTU Discovery を無効にする
ことにより対処しました。
この場合では、帯域制御機材その他のアプライメント機材は、こちらの管轄
ではなかったので、手が出せませんでしたし、問題になっていたのはメイル
サーバだけだったのでこうしました。
|
後藤さんからのお返事を読んで「やはり、PMTUブラックホール問題が発生している」
と思った。
詳しい人から、PMTUブラックホール問題を指摘されると、そうかもしれないと思う。
須山さんからも、お返事をいただいた。
| 須山さんからのお返事 |
|---|
Path MTU Discovery Blackholeというやつかもしれないですね。詳しくは，ぐぐっ
てみてください。
単純に解決策としては，ppインタフェース（ISPへの接続の設定）の設定で次の
ような設定を追加します。
ip pp tcp mss limit auto
また，IPSecのトンネルインターフェースでは次のような設定を追加します。
ip tunnel tcp mss limit auto
こうすれば，ルータの方で，適切なMSSに書き換えてくれるので，こういった問
題を回避することができるはずです。
なお，ヤマハのルータの場合，IPSecでのMTUは1280とかなり小さくなってしまい
ます。ヤマハのサイトにこの辺のことが書いてあるところがあったはずですが，
URIは失念してしまいました。
また，このコマンドは，ファームウエアのバージョンアップで追加されているの
で，ファームエアのバージョンが古いと対応していないかもしれませんので，ご
注意を。
# ファームウエアのリリースノートを見ればわかるのですが，ちと面倒なので。
もしかしたら，RT105eにはなかったかもしれません。RTX1000には間違いなくあ
ります。
|
須山さんのメールを読んで、IPSeCだとMTU値が1280になる事を知り
びっくりした。
ヤマハのルーターの設定集には、MTU値が1454となっている。
なのに、IPSeCの場合、MTU値が1280だという事が一切書かれていない。
その事について、投稿すると、須山さんから以下のお返事をいただいた。
| 須山さんからのお返事 |
|---|
須山です。
> この話は知りませんでした。
> ヤマハのルーターの設定事例のマニュアルでは、
>PPPoE + IPSeC の場合、MTUが1454になっていました。
> もちろん、業者が行った設定も、MTUが1454になっていました。
1454というのは，フレッツADSLにおけるPPPOEのMTUのことだと思い
ます。IPSecではIPパケットをさらにIPパケットでカプセリングす
るので，さらに，MTUが小さくなってしまいます。
> 実は、MTUが576でも、エラーが発生しました。
> 頭を抱えています。 MTUをもっと低くして、様子を見てみます。
なかなかうまくいきませんね。
|
須山さんのお返事を見て、頭が混乱した。
編集している今だと、確かに、フレッツADSLのPPPoEは1454だし、
IPSeCでカプセリングする場合は、IPSeCのヘッダーが色々ついてくるので、
MTU自体がヘッダーの影響で小さくならないと、パケットが通れなくなる事が
わかるのだが、この時は、頭の中が混乱に陥っていた (^^;;
さて、後藤さん、須山さんの助言を読んで、PMTUブラックホールの問題が
起こっている可能性が高いと思った。
そんな時、千葉から電話があった。
「メールが遅いんだよ。なんとかならないのか」と言われた。
この時、はじめて、プライベート同士の通信でもトラブルが起こっている事がわかった。
福岡から「データ転送が遅い」という電話がかかってきた。
P-COMM（AS/400のエミュレーター）についているデータ転送の事だが、
営業所のパソコンにデータを落とし込むのに、やたら時間がかかるという。
AS/400 から営業所のパソコンへデータ転送ができないのは、
VPN間の通信に問題がある事が確実だと思った。
実は、データ転送の問題ルに関しては、これだけが原因ではなかったのだが
この時は、データ転送が起こる原因として、PMTUブラックホール問題だと思った。
（データ転送の問題の話は後述しています）
これでPMTUブラックホール問題が起こっている事が確信した。
| この時、私が考えついた通信ができない原因 |
|---|
 |
この時、私はVPN回線の経路途中に、MTUサイズが小さい部分があると考えた。
経路途中に小さい部分があると、分割不可能なパケットは通る事ができず
結果的に、通信ができなくなるからだ。
|
そして、PMTUブラックホール問題以外にも、次の原因があると考えた。
「IPSeCを行う場合、MTUサイズを1280にする必要があるにも関わらず、
ルーターの設定で、MTUサイズを1454にしているのが原因」という事だ。
今、思えば、後藤さん、須山さんのお返事の内容を理解していない感じだが、
この時は、PMTUブラックホールと、MTUサイズを1280にする2点が原因だと
思い込んだ (^^;;
そこで、問題解消にはルーターのMTUサイズの変更が必要という事で、
N社のFさんに次のメールを送った。
| 私がFさんに送ったメール |
|---|
あと、外部への接続だけでなく、社内間でも、
接続できない問題が起こっています。
どうやら、営業所と本社間の部分で問題が起こっているようです。
色々、検索サイトを使って調べてたり、MLに聞いてみましたら、
PMTUブラックホール問題にハマった可能性が高いみたいです。
MSSの値を小さくして、逃げる方法があります。
MSS自動調整のコマンド 「 ip tunnel tcp mss limit auto 」
ですと、Windows98の場合は、NGが出るため、固定長で、
逃げるの無難のようです。
MSSを、538に固定すれば、問題がなくなった話もあります。
ヤマハのルーターで IPSeCを行う場合、MTUは1280より
小さいという話も聞きました。
設定事例マニュアルでは、MTUは 1454になっていますが、
その人の話ですと、以前は、ヤマハのホームページにも
掲載されていたようです。
|
わかったような、わからん内容のメールなのだが、
でも、PMTUブラックホール問題の解消の依頼は書けている (^^;;
しばらくして、Fさんからメールの事で電話がかかっていた。
Fさんが「VPN間の通信で、PMTUブラックホールは考えにくいのですが」と言った。
私は「でも、社内間の通信でも、通信ができない現象が出ています」と言った。
考えにくい事でも現象として起こっているからには、誰も反論できない。
そのため、Fさんは「では、DFフラグを『0』にする設定にします」と言った。
実は、この時、私は「DFフラグ」が何か忘れていた。
DFフラグは、パケットの分割の可能・不可能を示すビットで、
「0」だと分割可能で、「1」だと分割不可能になっている。
「システム奮闘記：その27」でも取り上げたのだが、忘却の彼方だった (--;;
(LinuxでVPN通信。PPTPサーバー構築)
私は、PMTUブラックホールの問題解決するには、ルーターのMTUサイズを
小さくする方法しかないと思い込んでいたが、ルーターの設定で、
DFビットを「0」にする設定がある事を知った。
| パケットのDFフラグを「0」にする設定 |
|---|
ip filter 10000 pass * *
ip fragment remove df-bit filter 10000
|
1行目は、フィルター10000は全てのパケットを通過させる部分
2行目は、フィルター10000を通過するパケットに関しては
DFフラグを「0」にする設定
|
もちろん設定したのは、Fさんだ。
DFフラグの設定以外に、MTUとMRUの値を1280にする設定も、Fさんが行った。
| MTUとMRUの値を1280にする設定 |
|---|
ip pp mtu 1280
ppp lcp mru on 1280
|
1行目はMTUの値を1280にする設定
2行目はMRUの値1280にする設定
|
DFフラグと、MTU、MRU値の設定変更した結果、通信のトラブルが解消された。
これで、やれやれと思った。
ここで暴露しまーす！！
この時点では、私は「MRUが何か」を全く知りませんでした (^^;;
実際に、私がMRUが何を意味するのか理解したのは、後になってからだが、
MRUの意味について触れる事にします。
| MTUとMRUについて |
|---|
 |
最大送信パケット長がMTU値である事は知っていたのだが、
最大受信パケット長がある事は、全く知らなかった。
その前に、受信できるパケットサイズの事は意識した事すらなかった (^^;;
|
実は、このMRU値は凄く曲者で、鹿児島で思わぬ問題を生む原因になった。
だが、この時点では、誰も知る由もなかった。
さて、トンネル前のMTUサイズが1280の意味が、この時点ではわからなかった。
FさんもDFビットの問題が原因なのか、MTUサイズの設定が問題なのか
わからない状態だった。
そこで、私はヤマハのサポートセンターに電話をして聞いてみる事にした。
「IPSeC化のヘッダーの付いていないパケットサイズが1280」だった。
| RTX1000、RT105eなどは、デフォルトで次の設定がされている |
|---|
ip tunnel mtu 1280
|
上の設定が自動的に行われているため、マニュアルの方で、ADSLのPPPoEの
MTU値の設定が1454になっていても、問題がないという。
この話は、Fさんも知らなかったという。
だが、これで解決したわけでなかった。
問題の症状は抑え込んだものの、どこの部分でMTUサイズが足かせに
なっているのか断定できなかったからだ。
N社のFさんも「なぜなのか、わからない」という感じだった。
全然、原因が特定できないため、次の文章を書いて逃げようとした。
| 編集している時点では、こんな事を書く予定にしていた |
|---|
考えられる原因としては、おそらく、地域IP網の中で
MTUサイズの小さい部分があると思われる。
|
だが、原因追求は、思わぬ所から解明される事がある。
事件発生から3ヶ月後の12月に、別の問題が表面化した。
その問題を解決するために、NATマシンのパケットの流れを、記録する事にした。
ふとした事で、Webパケットの流れを tcpdumpコマンドで記録を取る事にした。
| tcpdump -i -eth0 -S port httpの出力結果 |
|---|
10:26:05.056994 xxxx.yyyy.co.jp.1195 > 64.4.21.221.http:
P 10282270:10282624(354) ack 1603625906 win 8107 (DF)
10:26:05.222008 64.4.21.221.http > xxxx.yyyy.co.jp.1195:
. 1603625906:1603627320(1414) ack 10282624 win 64686 (DF)
10:26:05.223725 64.4.21.221.http > xxxx.yyyy.co.jp.1195:
. 1603627320:1603628734(1414) ack 10282624 win 64686 (DF)
10:26:05.225719 64.4.21.221.http > xxxx.yyyy.co.jp.1195:
. 1603628734:1603630148(1414) ack 10282624 win 64686 (DF)
10:26:05.227276 xxxx.yyyy.co.jp.1195 > 64.4.21.221.http:
. ack 1603628734 win 8484 (DF)
10:26:05.227633 64.4.21.221.http > xxxx.yyyy.co.jp.1195:
. 1603630148:1603631562(1414) ack 10282624 win 64686 (DF)
10:26:05.229473 64.4.21.221.http > xxxx.yyyy.co.jp.1195:
. 1603631562:1603632976(1414) ack 10282624 win 64686 (DF)
|
xxxx.yyyy.co.jpは、うちの会社のNATマシン。
64.4.21.221は、MicrosoftのサイトのIPアドレス。
Microsoftのサイトから送られたパケットを見ると、パケット長が1414になっている。
しかも、分割不可能な「DF」ビットをつけている事がわかる。
|
ここで暴露！！
私は、Webサイトから送られるパケットが分割不可能だとは知りませんでした
もちろん、Webサーバーから送られる際に、DFビットが立てられるのか
途中の経路で立てられるのか、全く、わからないが、少なくとも、NAT上を
通過する時に、分割不可能なパケットになっている事は知らなかった！！
さて、分割不可能な1414バイトのパケット長。これで謎が解けた！！
ヤマハのルーターで、IPSeCを行う場合、IPSeCのヘッダーのため、
暗号化前の最大パケット長は1280に制限されている。
という事は、次のような現象が起こっている事が言える。
| Webサイトが見れない理由 |
|---|
 |
ヤマハのルーターで、IPSeCを行う場合、トンネルの中は最大で1280バイトの
パケットしか送信できないようになっている。
しかし、Microsoftのサイトからやってくるパケットが、1400を越えるパケットな上
分割不可能な「DFビット」のパケットのため、VPNルーターの所を
通る事ができず、通信ができなくなっていた。
|
最初、ホームページやメールが使えない現象が起こった時、上図のような
現象が起こっているとは、考えもしなかった。
だが、BLUEのMLでのアドバイスを見て、PMTUブラックホール問題だと考えた私は
Fさんに依頼して、パケットのDFビットを「0」にして、パケットが分割可能にする
設定をしてもらった。下図のように、パケットが分割できるようになったため
ホームページやメールが使えない現象が解消した。
| パケットのDFフラグを「0」にする設定をしてもらった後 |
|---|
 |
VPNルーターに到着したパケットは、分割可能なパケットに生まれ変わる。
そして、分割できるため、例え、1280バイト以上のパケットがやってきても
ルーターの中を通過できるように分割され、通信ができるようになる。
|
さて、頭の中で「これだ！」と考えても、実際に、自分の目で確かめないと
気が済まない私なので、下図の実験を行った。
| NATのMTUサイズをプライベート側とグローバル側で変えてみた |
|---|
 |
プライベート側のMTUサイズを576にして、グローバル側のMTUサイズを
Linuxのデフォルトの1500の状態にして、社内からMicrosoftのサイトを見てみた。
すると、全く閲覧できない現象が起こった。
これは、プライベート側の送信パケットの最大長が576バイトなのにも関わらず、
576バイトを越える分割不可能なパケットを送ろうとして、
パケットが詰まったためだ。
|
この現象が、ルーターの部分で起き、パケットが送信できないため、
営業所で見れないWebサイトがあったというわけだ。
同様に、メールサーバーからメールを取り込む際のパケット長を調べると
1280バイトを越えるパケットが見つかり、これが原因で、メールが読めない
現象が起こったという。
どうも、パケット長さを決定する仕組みがわからない。
そのため、アマノジャクのように、パケットサイズが短くなる事もあるみたいで
同じサイトでも、見れる時と、見れない時が発生する。
この事が、わかった後、Fさんに連絡すると、Fさんは「なるほど」という感じで
反応していた。
私と同様、メールやWebサイトから送られるパケットが、分割不可能な状態で
送られていた事を知らなかったようだ。
ここで謎が生まれる。営業所〜本社間の通信ができない状態だった時も、
AS/400の通信は問題なくできていた。その時は、謎だったが、
これも12月になり、その理由がわかった。
| AS400のパケットを採取する方法 |
|---|
 |
パケットキャプチャの Etherealだと、DFビットの存在までは見れない。
そのため、Linuxを経由させて、tcpdumpコマンドで、パケットをとらえる必要がある。
上図のようにすれば、AS400のパケットも採取できる。
|
Linuxでルーターの構築なんて、今の私には難しくない。
そのため、失敗談はありません (^^)
その結果は以下のようになりました。
| AS/400のパケット(tcpdumpコマンドを使った結果) |
|---|
11:09:35.130117 192.168.20.1.1029 > as400.xxx.co.jp.telnet:
S 356128:356128(0) win 8192 <mss 1460,nop,nop,sackOK> (DF)
11:09:35.141219 as400.xxx.co.jp.telnet > 192.168.20.1.1029:
S 3921690219:3921690219(0) ack 356129 win 8192 <mss 536>
11:09:35.141565 192.168.20.1.1029 > as400.xxx.co.jp.telnet:
. ack 3921690220 win 8576 (DF)
11:09:35.208770 as400.xxx.co.jp.telnet > 192.168.20.1.1029:
P 3921690220:3921690223(3) ack 356129 win 8192
11:09:35.267965 192.168.20.1.1029 > as400.xxx.co.jp.telnet:
P 356129:356132(3) ack 3921690223 win 8573 (DF)
11:09:35.517536 as400.xxx.co.jp.telnet > 192.168.20.1.1029:
P 3921690223:3921690226(3) ack 356132 win 8192
|
as400.xxx.co.jpは、AS400のドメイン名
192.168.20.1は、端末(Windows98)のIPアドレス
Windows98から出ているパケットは、DFビットを出しているのだが、
AS400から出ているパケットを見ると、DFビットはない。
つまり分割可能なパケットを出しているという事だ。
そのため、VPNルーターのMTUサイズが小さくても、ルーターの所で
パケットが分割されて、問題なく送信されている事を意味する。
|
Linux、Windows98から出るパケットには、DFビットがあるが、
AS/400から出るパケットには、DFビットがない。
これは、私にとっては発見だった！！
さて、話は、9月の時点に戻します。
今まで私は楽するために、「丸投げIT担当者」に堕落していたのだが、
今回、私が動いた事をキッカケに「口出しIT担当者」へと変貌してしまったのだ。
さて、口出しIT担当者に変貌した私の振る舞いを書いていきまーす。
ルーターの設定ファイルを見てみる
通信がうまくいかない事件があったため、私自身、
設定ファイルのコンフィグを読めるようになる必要があると感じた。
そこで、Fさんに「もし何か問題が発生しても、責任の擦り付け合いは
避けたいので、原因の切り分けが私でもできるように、コンフィグを
出してください」と依頼した。
Fさんは客の方からコンフィグの提出を求められるのは、初めてみたいで
ちょっと戸惑っていた感じだったが、コンフィグを提出してもらう事になった。
これだと、各営業所のルーターの設定状況をすぐに見る事ができるのだが・・・
コンフィグの内容がわからへん (TT)
だった。
今まで、コンフィグなんぞ読む機会がなかったのだ。
インターネットに接続するため、ヤマハのRTA55iを使っているのだが、
設定はWeb上で可能なため、コンフィグを読んだ事がないのらー！！
だが、RT105e や RTX1000は、コマンドで設定を行うため、コマンドが読めないと、
設定なんぞできるわけがない。
さて、コンフィグを貰ったのだが、当初は「私も設定を把握した」と、
自己満足してコンフィグの中身を解読しようとしなかった (^^;;
だが、貰っただけで満足していたのでは、次のトラブルが発生した場合、
原因の切り分けなんぞ、できやしない。
そこで、付属でついていたルーターの説明書や解説書を読んで、
現在の状況を把握する事から始まった。
広島で「何の暗号方式を使っているのか」と、業者の人に聞いたが、
業者の人も把握していなかったので、知る事ができなかった。
だが、コンフィグを見ると、IPSeCに使っている暗号方式もわかる。
| ルーターのコンフィグ |
|---|
ipsec sa policy 1 1 esp 3des-cbc md5-hmac
|
この設定を見て、IPSeCに使っている暗号方式は、3DES方式だとわかる。
そして、認証のために使うハッシュ関数は、MD5が使われている事もわかる。
（注意）
ここで「3DESでなく、3DES-CBCやろ。MD5でなく、MD5-HMACやろ」という
ツッコミはしないでくださいね。それについては後述していますので (^^;;
|
このコンフィグを見て「なんでハッシュをSHA1にせずに、MD5にしたのやろか。
暗号の種類をAESにせずに、3DESにしたのやろか」と疑問に思った。
だが、この設定を行ったYさんは東京に転勤してしまったため、
事情が聞けない。それに、3DESだって暗号を解読するのに、太陽の寿命よりも長い
時間が必要だという事は簡単な計算で弾き出したので、問題視しなかった。
さて、コンフィグとルーターの設定マニュアルとを照らし合わせて、
設定内容を把握していく事にした。
そこで「あれっ?」と思う設定を発見した。
| NetBIOS over TCP/IP のパケットを通さない設定 |
|---|
ip lan1 secure filter in 1 2 92
ip filter 1 reject * * tcp,udp * 135,netbios_ns-netbios_ssn,445
ip filter 2 reject * * tcp,udp 135,netbios_ns-netbios_ssn,445 *
|
最初、ネットワークポリシーを決める時、営業所から本社との間で
ファイル共有できるように、NBT(NetBIOS over TCP/IP)のパケットを
通す話をしていた。
だが、この設定だと、NBTのパケットは、全てはじく設定になっている。
実は、営業所のパソコンの設定で、どうも本社のパソコンの共有フォルダーが
見れないので、おかしいなぁと思っていた。
最初は、WINSサーバーの設定などに問題があると考えていたのだが
どうも、そうでもないので、首を傾げていた。
しかし、コンフィグを読んで、その原因がハッキリわかった。
そこで、Fさんに連絡すると、どうやら、Yさんとの引き継ぎの際に、
NBTのパケットを通す話は聞いていなかったという。
Yさん、もっとしっかりしてよ〜 (^^;;
それにしても、Fさんは、問題発生の疫病神に取り憑かれただけでなく、
私という「口出しIT担当者」の相手をしなければならなくなった。
SEにとって、やりづらい環境になったのではと思ったりもする (^^;;
埼玉営業所
9月16日、埼玉営業所へ向かう。
日中に作業すると業務が止まるため、埼玉でも夜勤作業だ。
夕方4時ぐらいに営業所に到着。夕方から作業を開始する。
晩8時くらいに、営業マンが戻ってきた。
東京支店の部長も一緒だった。私が埼玉に出張で来ている事を知らなかったため
なんで、おまえが埼玉におんねん?
とビックリした様子だった。
そして、部長が・・・
はよ、東京をなんとかしてくれ!
と言ってきた。
確かに、インターネットVPN計画が始まった時は、最初に東京支店の回線の
切り替えを行うはずだった。それが色々な事情により、どんどん東京が後回しに
なっていった事もあり、部長にとっては「なんで、後回しにされるねん」という
不満を持っていた。
部長が「東京も光を入れてや」と言ってきたので、私が「光をいれても
あまり速度は変わらないですよ。」と答えると、部長が「そういう風に言えと
本部に言われとるんとちゃうんか。」と言われる (^^;;
夜間作業なのだが、大変な事が起こった。
P-COMMのソフトがあらへん (TT)
AS/400のエミュレーターソフトの、P-COMMがないというのだ。
営業所保管のため、営業所にあるはずなのだが、営業所の人は誰も知らないという。
高いソフトだけに、なくしたとなれば、一大事だ。
夜中に、システムの入れ換え作業などを行う所なのだが、それどころではない。
結局、夜中に倉庫などを探して、P-COMMを探すハメになった。
なんとか発見する事ができたのだが、見つけた時は時間切れ。
とても、始業時間までに、システムの入れ換えを行う時間がない。
幸い、メモリ不足などの不具合が出ていないため、ディスクのファイルシステムを
FAT16からFAT32へ変更したり、仮想メモリの容量を大きくして
将来の不具合を抑える対策だけはとった。
睡魔に襲われるが、寝れる場所がない。
でも、野性児化してきた私なので、大きな机の上にバスタオルを敷いて
仮眠をとる。9月なので、被る物がなくても、風邪はひかない。
17日の朝10時、N社から依頼された業者の作業員の方が来た。
問題なく、ルーターの設定が終わった。
3時くらいに問題が起こっていないようなので、引き上げる事にした。
徹夜明けでも、珍しく元気だった私。そのまま秋葉原へ行く。
そして、晩は築地へ行き、江戸前寿司を食べる。3000円もしたのだが、
本場の江戸前寿司を食べた。タコの白子焼きを初めて食べた。
この日は、帰宅せずに、東京に泊まった。
翌日、東京FORTで、長尾さんにお会いする。
データマイニングのMUSASHIプロジェクトで、長尾さんも私も、
ユーザー会の設立発起人なのだが、お会いするのは、初めてだった。
東京FORTの集まりは、マンションの一室を借りている。
ゆっくり、くつろぎながら、色々な話をしたり、大の字になって
昼寝をしたりなど、のんびりと過ごした。
晩は、大学時代の先輩2人に会い、有楽町の居酒屋へ行き、
お得意のエロトーク炸裂で盛り上がる。そして、最終の、のぞみで帰った。
金沢営業所
9月22日、金沢営業所へ向かって出発する。
サンダーバードに乗る。東海道本線、湖西線では高速運転だが
北陸線に入ると、あまり速くない。大阪から2時間半かけて金沢に着く。
2時間半かかるので、まるで東京へ行く感覚だ。
営業所に着いて一息。
N社の依託を受けた業者の人が来たので、VPNの設定を開始する。
ADSLモデムの設定をしていないので、モデムの設置をしたのだが・・・
リンクが確立してへん (--;;
ADSL回線がつながっていないのだ。
NTT西日本に問い合わせるが、電話が込み合っていて、つながらない。
ようやく、電話がつながると、「ADSLだから不安定かもしれない」と
言い訳し出す始末 (--;;
NTTに「原因を調べて復旧してくれ」と要請をする。
12時近くになり、モデムに接続のランプが点灯。しかし、NTTから連絡は来ない。
だが、N社の依頼を受けた作業員の方が午前中に作業という事もあり、
とりあえず、ルーターの設定をする事になった。
問題なくVPNのリンクが張れ、通信する事ができた。
NTTに「原因は何か? なぜ、開通したのに、連絡をしないのか」と言うと
「部署が違うので」という上、「不安定だったのでは」と言い訳するのみ。
N社のFさんの話では「おそらくNTTの局内回線の接続誤りだったのでは」
だった。NTTなら十分にあり得る話。
図体だけがデカくて、いい加減で動かないNTTに、他の通信会社の人達が
頭を抱えるのがよくわかる。NTTは「ウドの大木」かと思ってしまう。
新潟へ移動
翌日（23日）、新潟へ向かう。この日は祝日なので新潟で一日観光をする。
新潟市立博物館で新潟の歴史などを見る。海上交通の要所として栄えた歴史。
市場の焼き魚屋で、サバの塩焼を食べる。なかなか旨い！！
私の勤務先の場所を言うと、店主のおじさんが「うちの嫁の友人が
そこに住んでいるよ」となり、意気投合となる。
そこの店主の紹介で、美味しい魚介類の店として、寿司屋を紹介してもらった。
晩になり、焼き魚屋のおじさんの紹介してくれた店に行くが・・・
しかし、メチャクチャ高いやん！！ （ＴＴ)
刺身の盛り会わせを頼む。確かに、新鮮で旨いのだが、1800円は高い。
たまには、思いっきり贅沢も良いかなぁと思いつつも、大食いの私が
値段を気にせず食べると、とんでもない金額になりかねないので、
刺身の盛り合わせだけにした。
お腹は空いたままなので、新潟風カツ丼の発祥の店「とんかつ太郎」で
カツ丼を食べる。カツ丼と言えば、豚カツの上に、卵とじをかけるのが一般的だが、
新潟では、卵とじではなく、ソースをかけるという。なかなか美味しい。
料理マンガでお馴染みの「クッキングパパ」にも紹介された店だという。
新潟のグルメを満喫した感じだった (^^)
新潟営業所
24日、新潟営業所へ行く。
作業中、金沢営業所から電話がかかってきた。
AS400のプリンターの印刷に不具合が出ている!
だった。
原因は何かわからない。とりあえず、不具合が出た印刷物を
新潟にFAXしてもらう事にした。
ルーターの設定は問題なく進む。
パソコンの不具合対策を行うが、問題が発生した。
それは金沢と同様、プリンターの印刷の不具合という問題だった。
そこで、購入先のJ社のサポートセンターへ電話をかけて聞く事にした。
色々、やりとりをした結果、AS/400のエミュレーター（P-COMM）の
バージョンが古いため、パッチを当てる必要があるだった。
P-COMMの設定を、J社の人から教えてもらった際、プリンターの不具合があるから
パッチを当てるが必要という事は一言も聞いていない。
幸い、TCP/IP通信で、P-COMMのデータ転送を行うにはパッチが必要という事で、
今までの営業所では、パッチを当てていた。
しかし、金沢と新潟はデータ転送の必要がないので、パッチを当てていなかった。
早速、パッチを当てると、プリンターの不具合が解消された。
金沢でもパッチを当てる必要があると思った。
翌日、金沢へ行く予定が入っているので、現地でパッチを当てることにした。
それ以外は順調に進んだ。
晩、古町の商店街を散策。美味しそうな店を見つけたので入る事にした。
新潟名物の「わっぱ飯」、「神馬藻」、「のっ平」を食べる。美味しい。
新潟は食い物が旨い所だと思った。
再度、金沢営業所
25日、金沢営業所へ向かう。
元々は、代休をとっていて、帰る途中、金沢で観光して帰ろうと目論んでいたが
22日のADSLのリンクが立たない問題が発生した事や、プリンターの不具合対策のため
代休を取り止めて、金沢営業所へ向かう事にした。
だが、そこに立ちはだかった壁があった。
それは自然現象だった！！
新潟駅で、特急・北越2号に乗ったのだが、定刻になっても発車しない。
車内アナウンスで「前日の大雨で電車のダイヤが乱れています。
そのため、3分遅れで発車します」と流れた。
まぁ、3分だったら問題なしだと思っていた。
見附駅に着いた。だが電車は発車しない。車内アナウンスが流れた。
「次の長岡駅が前日の大雨のため、ホームに電車が埋まっていて入線できません。
そのため関係各所と協議しています」だった。
この時「これやと、一体、いつ金沢に着くんか、わからへん」と思った。
そこで、車掌さんに「数分は発車しませんよね」と確認をして、
見附駅にある公衆電話から会社に電話をかけた。
上司に「新潟は大雨のため、電車が立往生してしまい、金沢の何時に着くのか、
わからないので、その事を所長に伝えてください」と言ったら、
「どれくらい大雨なの」とか「なんで立往生なの」と色々聞かれた。
後で、わかった話。本社のある関西はカンカン照りだったので、
新潟が大雨だったのが信じられなかったという。
| 新潟は近いと思い込んでいる関西人は結構いるみたい |
|---|
上司は新潟は関西から近いと思い込んでいたため、新潟が大雨の話は
信じられなかったという。
そこで、会社に戻った時に、金沢〜新潟まで特急でどれくらいかかると
聞いてみたら、富山の隣だから、すぐちゃうという解答が返ってきた。
金沢〜新潟間が3時間40分かかる話をしたら、みんな「ホンマか」と驚いていた。
|
20分ぐらい経って、見附駅を出発した。これで大丈夫かなぁと思いきや
今度は、長岡駅で電車が立往生。
車内アナウンスで「只今、線路巡回のため、安全が確認でき次第、発車します」と
流れた。自然災害となれば、どうしようもない。
システム奮闘記の問題発生で、自然災害といえば、落雷による停電は考えられるが、
大雨のための移動ができないのは、予想もしていなかった。
15分経ち、ようやく電車が長岡駅を発車した。直江津でまた5分停車。
だが、直江津を出るとスムーズに進み、結局、40分遅れで金沢に着いた。
ようやく金沢駅に着いた。金沢営業所に向かう。
回線の問題が起こっているかどうか確認をする。
どうやら無事、回線はつながっているようだ。
プリンターの問題の解消を行う。パッチを当てたら問題なく解消できた。
その晩、きんねこさん、吉田さんご一家、宮越さん、竹田さん、堀尾さんと
駅の近くの居酒屋で飲み会を行う。
初物のカキを主賓という事で、食べさせてもらう事になった。
生ガキは旨い。もうカキの季節かと思った。
きんねこさんと吉田さんのお子さんが、「レモンはすっぱいか」で
意気投合して、みんなから「良いお友達」と言われる。
ハイパーターミナルでヤマハのルーターに接続
とりあえず9月の出張の予定は全て終わった。
次の出張までの2週間、普段通り内勤だった。
N社のFさんから連絡が来る。
RT105eのルーターで、セキュリティーホールが見つかったため、
ファームウェアーを入れ換える話だ。
岡山・広島・千葉のルーターが以前のバージョンのファームウェアーを
使っているため、攻撃される危険性がある。
そこで、Fさんが「手元にあるルーターを設定して、各営業所に送りますので、
今まであったルーターを返却してください」と言ってきた。
ここで悪知恵を考えた。
今までは稼働しているルーターを、私が変に触って問題が起こるとマズイので、
設定を触らないという事にしていた。
だが、これだとルーターの操作などが覚えられない。
そこで、千葉のルーターだけ本社に送ってもらい、しばらく無断でお借りする。
Fさんから催促があるまで、ルーターを触る事にした。
千葉からルーターが届いたので、早速、触ってみる事にする。
telnet を使ってルーターにログインしようとしたが・・・
だが、接続できへん (TT)
telnet で接続しようとすると、接続拒否されるのだった。
そこで、コンフィグを見てみる事にした。
特定のIPアドレス以外からは接続できない設定になっていた。
| 特定のIPだけ telnet を認める設定(RT105e のコンフィグ) |
|---|
telnetd service on
telnetd host XXX.YYY.ZZZ.10-20 AAA.BBB.CCC.DDD
|
コンフィグに、telnetでアクセスできるIPアドレスがわかったので、
パソコンのIPアドレスに、そのIPを割り当てて、再度、telnet を行ったが
だが、接続できへん (TT)
今度は、パスワードを受け付けてくれないのだ。
8月に、Yさんと話をした時、ルーターのパスワードは私の方で決めたのだが
そのパスワードが入らないのだ。
N社め、勝手にパスワードを設定して・・・
と思ったが、これをネタに因縁をつける気もないし、
まして、無断でルーターを借用しているため、声を大にして、
N社に文句を言う事はできない。
そこで、ルーターのマニュアル本を読むと、パスワードを忘れた時の
対処方法が書かれていた。
RS232Cケーブルで接続すれば、管理者でログインできるという。
早速、RS232Cケーブルを買いに行く。
RS232Cケーブルにも、ストレートタイプとクロスタイプがある事を知る。
ここで私はストレートケーブルを買おうと考えた。なぜなら、外付けのモデムに
接続する際、RS232Cのストレートケーブルで接続する事がケーブルの説明書きに
書いていたので、ルーターもモデムと同様、ストレートケーブルだと思った
しかし、嫌な予感がしたので、安全のため、両方購入した。
そして、翌日、会社でルーターのマニュアルを読んで、クロスタイプを使う事が
わかった。ストレートケーブルだけ買っていたら、買い替えに行かなくては
いけなかっただけに、今回は、運が良かったと思った (^^;;
早速、Windowsについている、ハイパーターミナルを選んだ。
| ハイパーターミナルでの設定・その1 |
|---|
 |
|
ここで接続名を決める。
|
次に接続方法を決める。
| ハイパーターミナルでの設定・その2 |
|---|
 |
|
ここで接続方法を「COM1」を選ぶ
|
各種設定値を決める
| ハイパーターミナルでの設定・その3 |
|---|
 |
|
ビット／秒を9600にする。他は初期値で問題なし。
|
すると、RS232Cでルーターに接続できる環境が整った。
パスワードの認証画面が出てきたので、ハイパーターミナルから
管理者でアクセスできるパスワード「 w,lXlma 」を入力する。
このパスワードは秘密でも何でもない。パスワードを忘れた際に、
ログインする方法として、ヤマハのマニュアルに書いてあるので、
掲載しても問題はないはず。
ようやくルーターに接続する事ができた！！ (^^)
| ハイパーターミナルでルーターに接続した様子 |
|---|
 |
|
この画面上からコマンドを入力したりする。
|
ヤマハのRT105eを触るのは初めてだ。
それも、コマンド操作でのルーターを触るのも初めてだ。
だが、手元に入門書がないので、手探りで必要なコマンドを覚えていく必要がある。
最初に覚えたのが、show configコマンドだ。コンフィグを見るコマンドだ。
しかし、ゆっくりと触っている時間がなかった。
しばらくして、Fさんから「千葉のルーターはまだでしょうか」と催促が
やってきたので、「そろそろ返さねば」と思い、あまりルーターで遊ぶ事が
できないまま、返却する事になった (--;;
P-COMMの動作が遅い問題発生
埼玉営業所から電話がかかってきた。P-COMMのデータ転送が遅いという。
P-COMMのデータ転送。
取引先の指定伝票発行や運送便の送り状発行などを発行させる時、
AS/400から納品データや、住所データなどをパソコンに落とし込んで、
そのデータを元に、伝票発行用のソフトを使って、印刷させている。
業務にはなくてはならない物だ。
データ転送が遅い問題。
既に、PMTUブラックホール問題は解消できたため、何が原因かわからない。
「一体、何が原因なんやろ」と考えたが、全く、思いつかない。
ふと、私の勘が働いた。
パケットが渋滞を起こしているのではないか？
結果的には、この勘は大ハズレだったのだが、この時は、とりあえず、
物は試しでやってみようと思った。
そこで、AS/400のデータ転送（P-COMM）のポートを購入先のJ社に聞いた。
ポートは制御ポートが449で、データ転送が8478だという。
ftpのポートに、制御ポートとデータ転送ポートがあるのと同じ発想だという。
そして、Fさんにパケットに優先順位をつける設定をしてもらうように依頼した。
Fさんから電話があった。
「RTX1000でしたら、帯域の優先制御ができるのですが、RT105eだと、
コマンドが入らないのですが」と言ってきた。
私は「そんなバカな！ 設定事例集にも書いてあるのに」と思ったが、
Fさんに「どんなコマンドを使っていますか？」と尋ねると、
トンネル側で制御をかけようとしたが、コマンドが受け付けない状態だという。
そこで私は「でも、設定事例集に書いてありますよ。トンネル側でなくても、
LAN側だと制御がかけれますよね」と言ったら、Fさんは「そうですね」と言って
設定変更をしてくれた。
| 物事を円滑に運ぶためにはユーザーの技術力向上は必要 |
|---|
私が前もってルーターの設定事例集を見て、勉強していたおかげで、
Fさんに別の設定方法を言う事ができた上、Fさんも納得してくれた。
もし、私が何も知らずに「できるはずだ！」と押しつけては、
「できる、できない」の押し問答になるだけで、前には進まない。
だが、私はこれを声高らか言う気はない。だって、しんどいもん (^^;;
|
さて、優先制御のコマンドですが、以下の通りです。
| 優先制御のコマンド |
|---|
queue lan1 class filter list 1 2 3 4 5 6
queue class filter 1 4 ip * * udp,tcp * 449
queue class filter 2 4 ip * * udp,tcp 449 *
queue class filter 3 4 ip * * udp,tcp * 8478
queue class filter 4 4 ip * * udp,tcp 8478 *
queue class filter 5 4 ip * * tcp * telnet
queue class filter 6 4 ip * * tcp telnet *
|
1行目は、LAN側で優先制御を行うためのコマンド。
2行目以降は、ポート449、8478、telnetの3つのパケットを
優先的にルーターで通過させるための設定だ。
この設定だと、3種類のパケットには順位の差がないのだが、
3種類の中でも、青い部分の数値を変更する事によって
優先順位をつける事も可能だ。数値が大きければ順位が上になる。
|
しばらく、これで様子を見てみる事にした。
埼玉からは「今まで通りに戻った」という連絡が来た。
この時、埼玉から「元に戻った」という知らせを受けたので、
P-COMMのデータ転送の原因は、パケットの渋滞だと思った。
さて、パケットの渋滞が原因だと思った私なのだが、何のパケットが原因で
交通渋滞を起こしているのか全く見当もつかない。確かめる必要がある。
東京出張が入っているので、ついでに埼玉にも行って調べる事ができる。
だが、無料のパケットキャプチャのソフトを知らないので、
Fさんに聞いてみたら、Etherealを紹介してくれた。
偶然なのか、このソフトが鹿児島出張で、すぐに役に立つとは思わなかった。
鹿児島営業所
10月13日、鹿児島へ出張。
2年半振りに飛行機に乗る。私は高所恐怖症のため、飛行機は好きではない。
何せ、遊園地の観覧車や、ロープウェイに乗るのが嫌なくらいだ。
しかし、高速バスで行くと、しんどい上、時間もかかる。
伊丹空港（私は兵庫県民なので、大阪空港とは言わず、伊丹空港と言う）に
スターバックスがあるのを発見する。
カフェラテが大好きなので、フライト中の贅沢として、飛行機に持ち込む事にした。
鹿児島空港に着く。南国なので10月でも暑いと思っていたら、
気温が19度で涼しかった。鹿児島でも10月の朝は涼しいのだと感心する。
営業所に着くと、既に、N社の依頼を受けてルーターの設定を行っている業者が
来ていた。だが、ここで問題が発生した。
なんとインターネットにつながらない問題だ。
N社のMさんから電話が入る。Fさんの上司だ。
この日は、Fさんの代わりにMさんが対応する事になった。
Mさんが「NTTの認証サーバーで接続が切られているらしく、
弊社の認証サーバーまで届いていないです」と言った。
私は、NTTの認証サーバーと言われも、どういう事がわからないので、
MさんにフレッツADSLの接続の仕組みを簡単に説明してもらった。
その時、ルーターのコンフィグの部分で、わからなかった部分が、わかった。
| コンフィグで、わからなかった部分 |
|---|
pp auth accept pap chap
pp auth myname abc@xxxx.nnn.ne.jp kaisha
|
|
2行目の設定部分で、なんで「メールアドレスが書いてあるねん」と思っていた。
|
だが、Mさんの説明で、これがメールアドレスの意味でなく、
フレッツ網で使われる2段認証のIDとパスワードの意味だという事がわかった。
| フレッツ網で使われる2段認証の概略とコンフィグについて |
|---|
 |
フレッツ網の場合、一度、NTT側の認証装置を通して、
その後、個々のプロバイダーの認証を受けてから、
インターネット接続が可能になるという。
|
これで1つ賢くなった。
だが、接続ができない状態が続く。
Fさんが「もしかしたら、ルーターが運送中にやられた可能性がありますので
代わりのルーターを送ります」と言った。
幸い、私は翌日の夕方まで営業所にいるため、代わりのルーターを受け取って
通信確認をとる事ができる。
そこで、その日は切り上げる事になった。
ホテルに向かう途中、鹿児島中央駅へ出る。
以前は、西鹿児島駅という名称だったが、新幹線が開通してから、
「鹿児島中央駅」に駅名が変わっている。
だが、現地でも受け入れる人は少なく、相変わらず「西駅」と言ったりする上、
駅の近くでは、「＊＊西駅前店」の表記のままの所もある。
長年、鹿児島の玄関口として親しまれた「西鹿児島駅」という名称が
簡単には消えるはずもない。
JR九州の駅名変更の失敗事例だと思った。
中央駅の駅ビルを見て、ビルの上に観覧車が回っている。
思わず「大阪のパクリやん」と思った (^^;;
さて、ビジネス向けのパック旅行。普通に航空券を買うよりも安くて、
しかも良いホテルに泊まれる。
私が泊まったのは、鹿児島でNo1と言われる「城山観光ホテル」だった。
ホテルに着くと、ボーイさんが荷物を運んでくれる。
そんな高級なホテルとは無縁な私は、丁寧な接客に戸惑ってしまう。
鹿児島に親戚がいるので、親戚の人とホテルで食事をする。
薩摩料理をごちそうになる。旨いなぁと思いながら、贅沢な気分になる。
そして、のんびりと温泉に浸かりながら、鹿児島の夜景を見る。
夜の鹿児島を満喫した。
翌朝、ホテルの朝食を取る。バイキング形式で、しかも、料理が豪華だ。
さすがは高級ホテル。朝から黒豚のスペアリブや、刺身などを食べる。
こんな贅沢を味わう機会なんぞないので、感激してしまう。
そして、鹿児島営業所へ向かった。
まず、NTTの工事の人を呼んで、モデムなどの点検を行ってもらうが
正常に動く。パソコンから直接、ADSLモデムにつなげた場合、問題なく通信が行える。
私がルーターをつけると、通信ができない話をすると、作業員の人は
「わからない」と答える。
そこで、Fさんと作業員の人とやりとりしてもらったのだが
NTTの作業員の人は「私、そこまで難しい話は、わかりません」だった (--;;
さて、14時くらいにN社から設定済みの予備のルーターが届いた。
そこで、送られて来たルーターをADSLモデムに接続してみたのだが・・・
やはり接続できへん (TT)
どうやらルーターの故障は考えにくい。これは絶対、NTTに原因があるはず。
N社のFさんは「NTT側での接続ができないため、弊社の接続装置で
接続が確認できていません。なぜ、NTT側で拒否されるのか調べてみましょう」
と言った。
Fさんから原因を探るために、Ethereal を使って、以下の図のように
パケットキャプチャを行って欲しいという依頼がきた。
| パケットキャプチャを行う |
|---|
 |
接続確立を行う時に、ルーターがどんなパケットを飛ばしているのか
確認するために、ルーターとモデムの間で、パケットキャプチャを行った。
|
数日前に、Fさんに無料で使えるパケットキャプチャのソフトを
紹介してもらったばかりだ。まさか、すぐに役に立つとは思わなかった。
早速、パケットキャプチャを行った。
だが、接続確立を求めるパケットぐらいしか出ていない。
そこで、Fさんからの依頼で、ルーター側のログを取る事になった。
そして、ログの内容をFさんにメールで送った。
| ルーター側のログ |
|---|
Kagoshima:# show log
2004/10/14 15:16:41: PP[01] RECV LCP ConfReq in REQSENT
2004/10/14 15:16:41: c0 21 01 2f 00 13 01 04 05 ae 03 05 c2 23 05 05
2004/10/14 15:16:41: 06 48 ed 64 e8 00 00 00 00 00 00 00 00 00 00 00
2004/10/14 15:16:41: 00 00 00 00 00 00 00 00
2004/10/14 15:16:41: PP[01] SEND LCP ConfAck in REQSENT
2004/10/14 15:16:41: c0 21 02 2f 00 13 01 04 05 ae 03 05 c2 23 05 05
2004/10/14 15:16:41: 06 48 ed 64 e8
2004/10/14 15:16:42: PP[01] RECV LCP ConfAck in ACKSENT
2004/10/14 15:16:42: c0 21 02 01 00 0e 01 04 05 00 05 06 05 6a 33 c5
2004/10/14 15:16:42: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2004/10/14 15:16:42: 00 00 00 00 00 00 00 00
2004/10/14 15:16:42: PP[01] RECV CHAP Challenge in CS_LISTEN/SS_CLOSED
2004/10/14 15:16:42: c2 23 01 19 00 1f 10 53 0d d3 95 84 ce 8f 67 83
2004/10/14 15:16:42: f4 9e 83 6f a2 8f 67 62 72 61 30 38 6b 69 6b 6e
2004/10/14 15:16:42: 31 00 00 00 00 00 00 00
2004/10/14 15:16:42: PP[01] SEND CHAP Response in CS_LISTEN/SS_CLOSED
2004/10/14 15:16:42: c2 23 02 19 00 30 10 ba 3e bb 0b ab 0b 65 d1 64
2004/10/14 15:16:42: c7 d5 43 82 9d 9d 2f 61 65 6b 31 38 37 36 30 40
2004/10/14 15:16:42: 61 6c 70 64 73 6c 30 31 2e 6f 64 6e 2e 6e 65 2e
2004/10/14 15:16:42: 6a 70
2004/10/14 15:16:42: PP[01] RECV LCP TermReq in OPENED
2004/10/14 15:16:42: PPPOE[01] RECV PADT
2004/10/14 15:16:42: c0 21 05 30 00 04 00 00 00 00 00 00 00 00 00 00
2004/10/14 15:17:07: c0 21 06 ab 00 04
2004/10/14 15:17:07: PPPOE[01] RECV PADT
2004/10/14 15:17:07: 11 a7 10 20 00 00
2004/10/14 15:17:07: PPPOE[01] SEND PADT
2004/10/14 15:17:07: 11 a7 10 20 00 00
2004/10/14 15:17:07: PPPOE[01] Disconnected, cause [No error.]
|
|
全く接続確立ができずに、PPPoEが切断されている記録が残っている。
|
なぜ、パソコンから直接、モデムに接続した場合は、インターネットへ
接続できるのに、ルーターの場合は、接続できないのか、謎だった。
Fさんからの依頼で、ルーターの状態を見る事にした。
| ルーターの状態 |
|---|
Kagoshima:# show status pp 1
PP[01]:
PPPoEセッションは接続されています
接続相手: bra08kikn1
通信時間: 0秒
受信: 5 パケット [238 オクテット] 負荷: 0.0%
送信: 5 パケット [179 オクテット] 負荷: 0.0%
|
|
パケットのやりとりが全然ない。
|
接続が確立できない事以外、何もわからない。
Fさんは「せめて、NTT側で接続が切られる原因を教えてもらえば
対策が考えられるのですが」と言った。
そこで、私はNTTに電話をかける。NTTのお得意の責任逃れに出た。
「ルーターに問題があるのでは」とか、「プロバイダーに原因があるのでは」と
責任転嫁ばかり言い、「ログは、他のISPさんには公表しない取り決めがあります」
とまで言い出した。
しかし、ここで引き下がっては、NTTの思うツボだ。
私は「でも、契約者は、うちでしょ。だったら、公表しても問題ないやろ。
どうして原因追求に非協力的なの！」と言った。
畳み掛けるように「ログそのものは出さなくても、接続が拒否される
原因を調べて教えてくれ」と言った。
NTT側は原因を教える事を約束した。
だが、「認証装置のログを見ましたが、正常終了になっていました」という
回答しか来なかった。
NTTに対して相当不信感を抱いている私は、NTTの言う事を信じる気はない。
だが、NTTのように肥大化した組織で、しかも、縦割りの組織だと、
たらい回しにされるため、NTTとケンカする気が失せる (--;;
結局、原因がわからず時間切れを向かえた。
そう、私が帰らざる得ないからだ。ビジネス向けパック旅行で申し込んだため
飛行機の変更ができないからだ。
予約していた最終のフライトに乗らねばならないからだ。
N社に、鹿児島にあるルーター2台を返却するのだが、ここで私はFさんに
「私もルーターを触れた方が良いかと思いますので、1台、お借りして
よろしいですか」と言ったら、Fさんは「良いですよ」と言った。
これでN社公認(?)で、しばらくルーターが触れる。
Fさんが「NTTに原因調査の依頼をしました所、NTTが調べるという事で
原因がわかるまで、時間をください」と言ってきたので、
私は、Fさんの依頼で集めたルーターのログなどを製造元のヤマハへ送り
原因の調査依頼をした。
そして、鹿児島営業所を後にして、最終の飛行機に乗るため空港に向かった。
空港バスの中で桜島を見る。
自宅に帰ってメールを読むと、ヤマハから回答がやってきた。
| ヤマハからの回答 |
|---|
お送りいただきました設定内容を確認させていただきましたが、特に問題ないと
思われます。また、お送りいただきましたログの内容では、下記の通り"No
error"というメッセージで正常終了されルータ側での問題は見受けられませんで
した。終端装置であるモデムとルータを再起動して、しばらく様子をみていただ
けますでしょうか。その後、症状に変化が見受けられない場合、お手数ですが
一度プロバイダ様へご確認いただけないでしょうか。
2004/10/14 15:17:07: PPPOE[01] Disconnected, cause [No error.]
以上、よろしくお願いいたします。
|
ヤマハも、鹿児島での問題の原因がわからないようだった。
さて、私が鹿児島から帰った数日後、Fさんから連絡があった。
Fさん曰く「NTTが公開しているフレッツADSLの仕様書に、MRU値が1454以下の
場合、一部の地域で接続ができない場合がある」という事だ。
PMTUブラックホールの問題を解消するため、MRU値を1280にした事が
トラブルの原因になった可能性が高いという。
もちろん、この時点では、可能性であって、確証が得られたわけではない。
だが、他に考えられる原因がない以上、MRU値の問題が原因だという前提で
物事を進めないと、いつまで経っても前に進まない。
ADSL フレッツ網の仕組み
鹿児島での問題発生で、Fさんの話や、NTTの人の話を聞いても、
チンプンカンプンの部分が多くて往生した。
そのため、電話局内が、どんな仕組みになっているのか、ADSLの仕組みが
どうなっているのか、キチンと理解しておく必要があると感じた。
そこで、ADSLに関する本を購入して、読む事にした。
「わかりやすいADSLの技術」（次世代ネットワーク研究会：オーム社）
「体系的に学び直すADSL」（川村潤、梅村新：日経ＢＰソフトプレス）
この2冊を読んでいく事にした。
| フレッツADSLでの接続形態 |
|---|
|
家庭や会社からプロバイダーまでのネットワーク網の事をフレッツ網という。
電話局からプロバイダーまでのネットワークの事を「地域IP網」という。
|
実は、この時まで、フレッツ網の仕組みを正しく理解していなかった。
それまでは以下の図のような、とんでもない理解をしていた。
| 私が誤解していたフレッツADSLでの接続形態 |
|---|
 |
家庭や会社から電話局までの回線の事をフレッツ網（地域IP網）と
思い込んでいた。そして、電話局からプロバイダーにつながっていると
思い込んでいたのだった。
|
フレッツ網を使うとインターネットの利用が安くできる仕組みを理解するには
フレッツ以外の接続形態と比較する必要がある。
| フレッツが登場する以前の接続形態 |
|---|
 |
フレッツ網が登場する前、プロバイダーは電話局内に接続装置を置いて
電話局からプロバイダーへつながっていた。
だが、これの場合、各プロバイダーは市単位（電話局単位）で
接続装置を置き、回線を敷かないといけないため、費用がかかるという
問題が発生していた。末端の回線もNTTから借りるため、高くつく。
もちろん、利点もある。自宅や会社からプロバイダーまでの間、
プロバイダーが管理を行うため、帯域保証のサービスをしてくれたり
窓口が一本化できたりするため、この方式は今でも活用されている。
|
フレッツ網の場合、管轄の範囲が変わってくる。
| フレッツ網での管轄範囲 |
|---|
 |
フレッツの場合、電話局からNTT東西が各県単位に構築している
地域IP網を経由して、プロバイダーとの接続地点まで回線を結んでいる。
この場合、プロバイダーは県単位で1つの接続箇所を設けるだけで済むため
プロバイダーの投資は安く済み、プロバイダー料金も安くなるという仕組みだ。
しかし、問題点としては、料金窓口がNTT東西とプロバイダーと
別れてしまうだけでなく、障害が発生した時も、責任範囲が違うため、
どちらが原因なのか調べないと、うやむやにされる恐れがある。
それだけでなく、地域IP網は帯域保証をしていないため、
ベストエフォート(Best effort)という「努力します」という形になっている。
そのため、通信速度がでなくても、文句が言えない状態になっている。
さて、NTT東西は「足回りサービスを提供」と言われている。
それは、NTT東西がNTT法で、プロバイダー事業に参入できないため
プロバイダーまでの接続サービス（足回りサービス）を行うためだ。
地域IP網は県をまたぐ事ができない。県単位で存在する。
これは、NTTが独占してしまう危険を排除する措置で私は賛成だ。
厳密には、2003年に多少緩和されて、一部の地域では県をまたぐ事が
可能にはなっている。
下手に規制を緩めて、NTTの独占の足掛かりにならねば良いと思うが・・・
|
これで、フレッツ網が何なのかを正しく理解する事ができた。
さて、Fさんの話を理解するために、よりフレッツ網の事を知る必要がある。
そこで、フレッツADSLの場合、NTT内には、どんな装置があるのかを調べてみた。
| フレッツ網でのNTT局内の装置 |
|---|
 |
ここで鹿児島でのフレッツADSLに接続できない問題の話が見えて来た。
網終端装置で、リンクが切られているため、N社の認証サーバーまで
パケットが届かないというのだ。
これで、Fさんが言っていた意味が、ハッキリとわかった。
東京支店
10月18日、東京支店へ出張。ようやく東京支店にVPNを導入する事になった。
問題なくVPNの設定が終了した。
これで部長から「はよしてくれ！」と言われる事がなくなったと思いきや
部長から思わぬ苦情がやってきた。
どこが早いねん。うちの家より遅いぞ！
部長は続けて「菅ちゃん、なんで、光を入れんかったんや。ADSLにしたから
こんなに遅いんやろ」と言ってきたので、私は「部長、データを暗号化している上
本社の回線が太くないので、光を入れても意味がないですよ」と答えたのだが、
部長も負けずに「せやけど、これがADSLでも遅いで。うちの家、ADSLの12Mだけど、
もっと早いで。これ、24Mやろ。なんか、おかしいで」と言ってきた。
他の営業所では「速くなった」と言われるが、部長だけは「遅い」だった (--;;
その晩、部長と一緒にパスタを食べに行った。
仕事の話は一切せずに、色々な話などで盛り上がる。
再度、埼玉営業所
翌日、埼玉営業所へ向かう。
P-COMMのデータ転送が遅い理由を探るためだ。
埼玉の事務員さんに話を聞くと、QoSの設定をしてもらったにも関わらず、
遅い時があるという。
私は「どのパケットが悪さをしているのだろうか」と思いながら、
Ethereal を使って、パケットキャプチャを行った。
すると、P-COMMが、接続先のAS/400のIPアドレスのDNS検索を行っていたのだ。
| パケット採取の結果 |
|---|
 |
青で塗りつぶされた所が、DNSサーバー。グローバルIPなので秘密にしています。
ピンクで塗りつぶした所は、AS400のIPアドレスです。これも秘密 (^^)
これを見ると、なぜか、P-COMMが、IPアドレスをホスト名だと思い込んで、
IPアドレスの正引きを行うという奇妙な現象を起こしている。
|
これを見たら「なんで、IPアドレスを正引きするねん？？」と思う。
だが、この時、P-COMMが、IPアドレスをホスト名と間違えて、正引きするとは
夢にも思わないので
この時は、P-COMMがIPの逆引きを行っている
と思い込んでしまった (^^;;
| AS400のエミュレーターの設定に、なぜIPを使っていたのか |
|---|
 |
上は、AS400のエミュレーターソフト(P-COMM)の設定画面。
ここの部分をホスト名にせずに、IPアドレスを入力していた理由だが、
特に、理由はなかった。購入先のJ社から設定を教えてもらった時、
IPアドレスを入力する事を言っていたため、何も考えずに接続先である
AS400のIPアドレスを入力していたのだった。
|
この時点では、IPアドレスの逆引きができないのが原因で、
データ転送が遅くなっている要因の一つと考えた。
例えば、クライアントが、メールサーバー（sendmailの場合）にアクセスする際も、
クライアントのIPが逆引きできないと、接続が遅かったり、または、
接続できなかったりする。
詳しくは「システム奮闘記：その22」をご覧ください。
(BINDでDNSサーバー設定)
J社のサポートセンターに問い合わせると、P-COMMがDNS検索をしている話は
知らなかったみたいで、J社の人は「そうなのですか」という感じだった。
さて、昨日、東京支店の部長に「なんで光を入れへんねん」と言われたので、
光を入れても大幅に速度が向上はしない事を証明しないといけない。
「触ってみましたが、あまり変わりませんでした」と言った所で、
「菅ちゃん、そう言えと、上から言われたんやろ」と言われるだけだ。
そのため、部長が納得するように数値として出す必要がある。
そこで、以下の方法を考えていた。
| 回線速度の測定法 |
|---|
回線が一番細い部分に影響されるはず。
一番、回線の遅い部分はVPN回線になってくるため
本社〜営業所間の速度比較ができると考えた。
|
「BNRスピードテスト 回線速度計測ページ」のサイトを使って回線速度を求めた。
http://www.musen-lan.com/speed/
正しく測定する場合は、キチンとした方法を行う必要があると思うが、
あくまでも簡易的な測定には使えると思う。
|
ちゃっかりと、東京と埼玉で、回線速度を測定していたのだった。
その結果が以下の通りだ。
| 東京支店と埼玉営業所の回線速度の比較 |
|---|
| 東京支店 |
------ BNRスピードテスト (ダウンロード速度) ------
測定サイト： http://www.musen-lan.com/speed/ Ver3.4001
測定日時： 2004/10/18 17:50:28
回線/ISP/地域：
--------------------------------------------------
1.NTTPC(WebARENA)1： 509.045kbps(0.509Mbps) 63.61kB/sec
2.NTTPC(WebARENA)2： 582.5kbps(0.582Mbps) 72.69kB/sec
推定転送速度： 582.5kbps(0.582Mbps) 72.69kB/sec
------------ Broadband Networking Report ------------
＜アップロード速度＞
データ転送速度: 470.91kbps (58.86kB/sec)
転送データ容量: 600kB
転送時間: 10.193秒
-----------------------------------------------------
測定日時: 2004年10月18日(月) 18時00分
測定サイト: http://www.musen-lan.com/speed/
利用ブラウザ: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
-----------------------------------------------------
|
| 埼玉営業所 |
------ BNRスピードテスト (ダウンロード速度) ------
測定サイト： http://www.musen-lan.com/speed/ Ver3.4001
測定日時： 2004/10/19 09:06:17
回線/ISP/地域：
--------------------------------------------------
1.NTTPC(WebARENA)1： 527.07kbps(0.527Mbps) 65.86kB/sec
2.NTTPC(WebARENA)2： 599.724kbps(0.599Mbps) 74.71kB/sec
推定転送速度： 599.724kbps(0.599Mbps) 74.71kB/sec
------------ Broadband Networking Report ------------
＜アップロード速度＞
データ転送速度: 676.06kbps (84.50kB/sec)
転送データ容量: 600kB
転送時間: 7.100秒
-----------------------------------------------------
測定日時: 2004年10月19日(火) 09時17分
測定サイト: http://www.musen-lan.com/speed/
利用ブラウザ: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
-----------------------------------------------------
|
確かに、東京支店の方が、若干、回線速度が遅い結果が出たのだが、
これぐらいの差で、劇的な違いがあるとは考えられない。
部長に「埼玉と速度は変わらないですよ。ウソだと思われるのでしたら、
証拠をお見せしますよ」と言ったら、部長が「わかった。もうええ」と
ようやく納得してくれた (^^)V
埼玉でパケットキャプチャで、P-COMMがDNSの逆引きをしていると思い込んだ私。
（実際は、IPをホスト名と勘違いを起こして、IPを正引きをしているのだが）
そこで、DNSサーバーに、AS/400を登録する事にしたのだが、
そもそも、AS/400にホスト名なんて付けた覚えがない。
そこで、J社のサポートセンターに電話をして、ホスト名の付け方を聞いた。
すると「ログイン画面に、デフォルトで出ているシステム名をホスト名にしても
問題ないですよ」と回答をもらった。
これで、埼玉でのP-COMMのデータ転送の遅さは完全に解消できたと思った。
しかし、数日後、埼玉から「データ転送が遅くなったりする」という報告を受ける。
データ転送の遅さは解消できなかった。一体、何が原因か、わからない・・・。
そこで、本社のマシンを使って、P-COMMのデータ転送中のパケットキャプチャを
行ってみる。
ここで、ようやくP-COMMの設定で、IPアドレスを入力すると、
IPのDNSの逆引きでなく、IPアドレスをホスト名と間違えて認識して、
IPアドレスの正引きを行う事に気づいた。
そこで、埼玉のパソコンを遠隔操作を行って、P-COMMの設定で、
接続先のAS400の部分を、IPアドレスからホスト名に変更した。
| AS400のエミュレーターの設定に、ホスト名を入れる事にした |
|---|
 |
こうすれば、IPアドレスをホストと勘違いして、IPアドレスの正引きをしなくなるし
これが原因で、P-COMMのデータ転送が遅くなっていた可能性もあると考えた。
|
今度こそ、解消してくれと思った。
あと、埼玉には2台、P-COMMの入ったパソコンがあるのだが、
よく使う1台のみ、設定変更を行った。
もう一台は、データ転送が遅いという話を聞いていないので、変更しなかった。
1台だけホスト名で設定して、もう1台はIPアドレスで設定を行う。
別々の設定をしたのだが、これが、12月に発覚する問題の解決の糸口になる事を
この時点では知る由もなかった。
高松営業所
10月29日、高松営業所へ出張。
実は、7月にも私的で高松へ行ったため、観光する気は起こらない。
うどん三昧はしたし、女木島（鬼ヶ島）へ探検もしているからだ。
もちろん、親切青鬼君ともご対面している。
| 香川県の観光マスコットキャラ「親切青鬼君」 |
|---|
 |
香川県の観光マスコットの親切青鬼君。
各地を旅行していた青鬼が香川の地で親切にしてもらい、青鬼君が感激して
香川の地を第2の故郷にした事から、観光客には親切にしようという事から
観光マスコットになりました。
2000年9月に高松営業所へ行く機会があった時、駅前で親切青鬼君と初めてご対面。
高松の知人は「あれは謎のキャラだ」といって、あまり好きでないみたいだが
私は結構、気に入っている。
鬼といえば、高松は鬼と縁のある場所で、桃太郎伝説の舞台になった
鬼ヶ島（女木島：高松市鬼無町）があります。
桃太郎伝説は、大昔、大和朝廷の命を受けて、海賊を退治した事に由来します。
当時は、海賊や異国人の事も「鬼」と言っていました。
そして平安時代、讃岐の国司として赴任した菅原道真が伝説を集めていた時に
海賊退治の伝説に遭遇し、現在の桃太郎の話の原型を編集しました。
|
高松は鬼と由来しているためか、ここでも困難が待ち受けていた。
本社に置いている営業所の所在地の地図だった。現地についてビックリ！！
縮尺はメチャクチャ、建物などの位置はメチャクチャ。
しかも、電柱には町名や番地が載っていない。30分ぐらい同じ所を
グルグル回りながら、ついに営業所の場所がわからず、降参した。
営業に電話をかけて「迷子になったので、迎えに来てください」と助けを呼んだ。
私が持っていた地図を見た営業所の人が「よくこんな地図で、あそこまで
辿り着いたね」と驚いた感じで言った。
さて、ルーターの設定の方だが順調に終わった。
あとは、徹夜でパソコンの設定変更。
うちの会社で、一番IT化が進んだ営業所だけに、パソコンに何のソフトが
入っているのか、私も把握していない。
CD-Rはあるし、スキャナー付プリンターなどがあるため、OS入れ換えを行う前に
それらのドライバーがあるか確認をする必要がある。
営業所の人に「菅くん、CD-Rのドライバーとかは、こっちでやっとくから、
P-COMMの設定やOSの入れ換えを頼むね」と言ってきたので、
最低限の作業だけで済む。
さて、どんなファイルがあるのか見て行くと、面白いゲームを発見した。
フリーのソフトで「8強対決コスプレバトル（ノリコ編）」というゲームだ。
思わずハマってしまった (^^;;
ゲームの内容は、プレイヤーはコスプレトレーナーで、ノリコという女子高生が
コスプレ大会に参加すべく、コスプレを制作するのだが、プレイヤーは
より良いコスプレが完成できるように、ノリコを指導し、全国コスプレ大会で優勝を
果たすのが目的というゲームだ。
プレイヤーの設定年齢は36才。ノリコは16才。
だが、なんと2人は恋仲に陥って行くのだ。
コスプレ大会で優勝した後、2人はキスをするという。
プレイヤーはロリコンかい！！
しかも、プレイヤーは、過去に、ノリコの母親とつき合っていたという。
これって、親子ドンブリ (^^;;
なんて青少年に対して教育上、悪いゲームなんだ！！
16才から36才を見れば、ただのオッサンのはず。なのにゲームでは
とんでもない事が成り立ってしまう。
現実世界では、31才の私が、22、23才のピチピチギャルが良いなんて言うと
ただのエロオヤジ扱いされるのに・・・ (--;;
3時くらいに作業が終わる。睡魔が襲ってくるのだが、仮眠する場所がない。
大きな机はないし、床はカーペットでないため、硬くて冷たくて寝れない。
そこで、暖房をつけて、椅子を並べて、そこに寝る事にした。
だんだんと逞しくなっていく感じだ。
岡山では寝る場所はソファーと上等だったのだが、福岡では板張りの床で寝て、
埼玉では机の上にバスタオルを敷くという硬い簡易ベッドだった。
高松では、高さの違う椅子を並べて凸凹ベッド。
どんどん仮眠する所の程度が落ちている気がする・・・。
朝を向かえ、事務員さんが出勤してきた。
パソコンの動作に問題がない事を確認できたので、帰る事にした。
徹夜明けでも、元気だったら、坂出や丸亀、琴平などを旅行したいのだが、
そんな元気がない。さすがに椅子をベッドにしたのでは疲れがとれない。
珍しく素直に帰る事にした (--;;
IPsecと暗号化の通信の仕組み
さて、高松から帰って来てホッとするのも束の間。
10月の時点で、既に、この原稿を書いているののだが、問題が発生する。
IPSeCの事を書くのだが、IPSeCについて何もわかっていない。
「事務員だから、わかりませーん」で開き直って、IPSeCの内容について
触れないのも一つの手なのだが、今まで書いた部分で、間違いがないか
もし、誤った事をかけば、必ず、ツッコミがあると思ったので、
ツッコミを防止するために、IPSeCを勉強しなおす事にした。
さて、今までは助っ人として以下の本を利用していた。
「最新VPNハンドブック」（伊藤幸夫、紫藤政義、野口修：秀和システム）
だが、もっと強力な助っ人を用意した。
「IPsec徹底入門」（小早川知昭・著：西田晴彦・監修：翔泳社）だ。
まずは、カプセリングの部分を見てみる事にした。
| IPSeCのカプセリング(暗号化) |
|---|
 |
データの内容の信頼性をチェックするために、ESPによって
暗号化された部分にハッシュ関数を使って、ハッシュ値を出す。
そのハッシュ値が「ESP認証データ」となる。
|
本を読んでいると「鍵つきハッシュ関数」という文字があった。「HMAC」とも言う。
HMACって、どこかで見たぞ！
思い出してみると、それはルーターの設定にあった。
| ルーターのコンフィグ |
|---|
ipsec sa policy 1 1 esp 3des-cbc md5-hmac
|
確かに、ルーターのコンフィグでも、HMACが設定されている。
一体、これが何なのか知るために、本で調べる事にした。
| 「鍵つきハッシュ関数(HMAC)」とは |
|---|
 |
通常、認証データを作成するため、データの中身をハッシュ関数を使って
ハッシュ値を出す。
しかし、ハッシュ関数に使われるMD5やSHA1は、よく知られた方法なので、
送信するデータの中身を改竄してから、それに対するハッシュ値を出して、
改竄した内容がバレないようにする事もできる。
そこで、IPSeCでは、データに秘密鍵を足して、それのハッシュ値を出して
改竄されないように工夫をしている。
|
なかなか奥が深いと感心する私。
次に秘密鍵の生成を見る事にした。
お互いの乱数の交換だけで、誰にもわからない秘密鍵を生成できるのだから
凄いとしか思えない。
だが、難しい「離散対数的問題」という分野なので、私は逃げようと
考えたのだが、どんな風に秘密鍵が生成されるのか、キチンと説明できれば、
カッコ良いので、理解しようと頑張ってみる事にした！
秘密鍵の生成の原理
(Diffie-Hellman交換) |
|---|
 |
上の式を使えば、お互いが平文で乱数を交換しても、
お互いにしかわからない秘密鍵が生成できる。
お互いに交換する乱数以外に、お互いが独自で持っている乱数（x,y）があり
このx,yの解を求めるために、上の方程式を解く必要があるのだが、
この方程式を解く計算量は尋常でないため、スーパーコンピューターを
使っても簡単には解けないという。
もし、秘密鍵の交換が定期的に行われれば、半永久に暗号を
解読できない事を意味する。
この乱数交換の事を「Diffie-Hellman交換」ともいう。
|
さて、具体的に数値を当てはめると、わかりやすいので、
早速、電卓を用意して、実際に計算して確かめる事にした。
| 秘密鍵の生成 |
|---|
 |
最初に、装置Aで乱数9を生成する。それを元にして5を生成し装置Bへ渡す。
次に、装置Bで乱数11を生成する。それを元にして7を生成し装置Bへ渡す。
そして、生成した乱数と、交換した数値を式に当てはまると、
お互いにしかわからない「8」という数字が生成される。これが秘密鍵になる。
この例の場合、私が計算を楽するために、「n=13」にしたのだが、
実際には、もっと大きい数字が使われている。
nの値が大きければ、暗号化の強度も増す。nの大きさに、一応、規定があり、
大きさによってグループ番号が割り振られている。
多くのルーターに採用されているのはグループ2と呼ばれるものだ。
ちなみに、「g=2」は、どのIPSeCルーターでも同じのようです。
|
これが「離散対数的問題」と呼ばれる技を使った秘密鍵生成の話だ。
秘密鍵の生成原理を知ると「名前だけ難しいだけか」と思ってしまう。
確かに、公式丸暗記・当てはめる方法だと難しい話ではないが、
この方程式を解くのが難しい。
実は、この時、トンデモナイ誤解をしていた事を発見した。
前述していますが、IPSeCの事を軽く勉強した時、この乱数交換はコロコロ変わる
秘密鍵の生成ではなく、定期的にコロコロ変わるパスワードだと誤解していた。
しかし、今回、本を読んで、どこにも「コロコロ変わるパスワード」とは
一切書いていない。書いているのは「秘密鍵の生成」だ。
そこで、初めて、誤解が解けた。
さて、データの暗号化の秘密鍵のやりとりだとわかったのだが、
それではパスワードは、どうやって設定しているのかが疑問になった。
そんな疑問を持ちながら、本を読み進めた。
ところで、肝心のIPSeCは、どういう仕組みで通信が行われているのか
全くわからないので、調べる事にした。
IPSeCの通信を確立するのに、IKEが重要な役割を果たす。
ところでIKEって何やねん?
そうなのです。今まで、IKEが何なのかわかっていないのです！！
そこで、調べてみると「SA自動生成／管理プロトコル」と書いていた。
さすがに、SAはコネクション（通信確立）の事だとわかる。
つまり、IKEは、自動的に通信確立をしたり、通信確立などの管理を行うものだ。
いわば、IPSeCの制御を行う。さて、IKEの通信では、次のポートが使われる。
| IPSeCの通信のポートについて |
|---|
 |
IPSeCの制御は、ポートが500で、UDPのパケットを使う。
そして、暗号化されたデータのやりとりは、ESPのプロトコルを使う。
|
IKEが、IPSeCの制御に使われる事は、わかった。
となると、IKEの具体的な動作を見てみたくなる。
| IKEには2つの段階ある |
|---|
 |
IKEには2つの段階ある。Phase1とPhase2という感じで横文字で表す。
第1段階のPhase1では、IPSeCの通信の前準備を行うための物だ。
IPSeCの通信確立の際に、どの暗号を使って、どの方式で通信するのか
決める必要があるのだが、その情報が洩れると、盗聴の危険性や
改竄の危険性が出てくる。
そこで、Phase1では、IPSeC通信の方針を決めるやりとりの通信を
暗号化するための、やりとりだ。そのため、前準備とも言える。
Phase1の事を「ISAKMP SA」という。呼び方は「アイサキャンプセスエ」
舌を噛む発音だなぁ・・・
Phase2では、実際に、IPSeC通信を行う際の通信方法を決める。
Phase2のやりとりは、Phase1のお陰で、全て暗号化されて行われる。
|
安全性を保つために、2重の仕掛けをするとは、なかなか奥が深いと感心する。
さて、Phase1とPhase2を詳しく見てみる事にした。
| IKEのPhase1(ISAKMP SA)の動き |
|---|
 |
まずは、ISAKMP SAの通信で、どんな暗号方式で通信を行うのか決める。
それが「SA」のやりとりだ。
そして、秘密鍵を生成するために、お互いが乱数の交換を行う。
最後に、お互いの事前共有キーのハッシュ値を出して、暗号化を行う。
それを使って、お互いの通信先が本物かどうかの確認を行う。
|
さて、どんな暗号方式で通信を行うのか決めるやりとりが「SA」と書いたが
具体的に、どんな事が決められるのか調べる事にした。
| IKEのPhase1での、SAの内容 |
|---|
 |
SAとは、実際に通信を行う時の約束事を提案する事だ。
Phase1では、上の5つの項目について、決め事を行う。
暗号化の方法の候補に、例えば、DES-CBC、3DES-CBCを提案する。
認証方式の場合は、例えば、共有事前キーのチェックを提案する。
Diffie-Hellman交換（秘密鍵生成の際のnの値のグループ）を、2で提案する。
認証のためのハッシュ関数を、例えば、MD5-HMAC、SHA1-HMACを提案する。
ISAKMP SAの寿命を、例えば、28800秒を提案する。
提案は複数できるのがSAの特徴だ。相手側は、そのうちのどれかを選択できる。
|
ここで認証方式に注目した。
先ほども書きましたが、コロコロ変わる秘密鍵を、コロコロ変わるパスワードと
誤解していた事だ。私はパスワードでお互いの認証をしているとばかり思っていたが
本には認証方法に何種類かある事が書かれていた。
そこでコンフィグを見てみる事にした。
| コンフィグの内容 |
|---|
ipsec ike pre-shared-key 1 text password
|
これはお互いの認証方法が共有事前キー(パスワード)だという事がわかる。
passwordがパスワードに当たる。
認証に使う際は、これのハッシュ値を算出して、その上で、秘密鍵で暗号化して
盗聴されないようにして、相手に送り、照合を行う。
ハッシュにするのは、相手が偽物である可能性があるから、簡単に、
パスワードを解読できないようにするための方法だと思う。
|
これで、うちの会社の設定は、共有事前キー方式を採用している事がわかった。
さて、次にPhase2の動きを見てみる事にした。
| IKEのPhase2の動き |
|---|
 |
ここでは、IPSeC通信を行う際の暗号方式などを決めるやりとりが
行われます。
|
IKEのPhase2の時のSAの内容はどうなっているのか。
| IKEのPhase2での、SAの内容 |
|---|
 |
ここでは、IPSeCで使われる暗号化の方法を決めるやりとり(SA)だ。
暗号化の方法の候補に、例えば、DES-CBC、3DES-CBCを提案する。
セキュリティープロトコルを、ESPかAHかを提案する。
カプセル化を行う場合、トンネルモードかトランスポートモードかを提案する。
IPSeC SAの寿命を、例えば、28800秒を提案する。
通常、秘密鍵は、Phase1で生成した物をIPSeC通信でも使われるのだが、
PFSを採用すれば、Phase2でも、乱数交換で秘密鍵を生成し、Phase1で生成した
秘密鍵と置き換える事ができる。
このメリットは、Phase1で生成した秘密鍵が破られても、Phase2で
生成した秘密鍵を使っているために、セキュリティーが強固になるのだが
通信を行う上での問題点があるため、あまり使われていないのが現状のようだ。
|
ふと、ここで思った。
N社が設定したルーターだと、ISAKMP SAとIPSeC SAの寿命はどれくらいなのか
知りたくなった。
まさか、永遠に鍵交換を行わない危ない設定は行うはずがない。
そこでコンフィグを見てみると自動的に鍵交換を行う設定があった。
| 鍵交換を自動的に行う設定 |
|---|
ipsec auto refresh on
|
では、ISAKMP SAとIPSeC SAの寿命を調べるため、コンフィグを見てみたが・・・
全く設定があらへん (^^;;
一体、寿命はどう決めているのか、謎になったのだが、マニュアルを見ると
RTX1000、RT105eだと初期値では28800秒になっていた。
28800秒は、8時間だ。一日に3回も鍵交換が行われているという。
これだと、ソフトの不具合がない限り、絶対に暗号が破られないと思う。
さて、ISAKMP SAやIPSeC SAの寿命はルーターによっては時間だけでなく、
通過したデータ量がある一定以上越えた時点で、新しく生成しなおす方式もある。
ちなみに、RTX1000やRT105eの場合、IPSeC SAの寿命は時間だけでなく、
通過したデータ量(バイト)で決める事もできる。
ただし、IPSeC SAだけであって、ISAKMP SAは、時間のみの設定になる。
さて、IPSeCの仕組みを、いかにも簡単そうに書いているのだが、実は・・・
これを調べるのに、相当時間を費しました (TT)
そうなのです。理解するだけで七転八倒しているのです。
IPSeCが行われるまでのやりとりが、だいたい理解できた所で、
次に、IPSeCの通信中に使われている暗号化の話をする事にします。
暗号の種類には、DES、3DES、AESなどがありますが、ここでは、うちの会社が
使っています3DESについて書く事にします。
| 3DESの暗号化方式 |
|---|
 |
3DESは、2種類のDESの鍵を使って暗号化を行います。
まずは、1つ目の鍵で暗号化を行い、次に2つ目の鍵で復元化します。
復元化する所が面白い。単に暗号化するよりも暗号強度が増すためだという。
最後、1つ目の鍵で暗号化を行います。
これにより、DESの鍵よりも3倍強度があると言われています。
この辺りの秘密鍵だが、ここでは2つ使うのを紹介しましたが、
本よれば、3回とも違う鍵を使う場合もあるみたいで、
どちらが正しいのか、どっちも正しくて、単なる利用頻度の違いなのかは
わからなかった (^^;;
|
さて、普通に3DESで暗号化を行う場合は、以下のようになる。
| 3DESで暗号化した場合 |
|---|
 |
|
データは、一定のブロック(大きさ)に分けられて、暗号化される。
|
さて、ここまできて、お気付きの方もおられると思いますが、
3DESと書いているのに、3DES-CBCが出てきました。
コンフィグを見た時も設定が「3DES-CBC」になっている。
| ルーターのコンフィグ |
|---|
ipsec sa policy 1 1 esp 3des-cbc md5-hmac
|
一体、何が違うのか。調べてみる事にした。
| 3DES-CBCで暗号化した場合 |
|---|
 |
まずは、乱数で作った「IV」というブロックがあります。
それとブロック1との排他的論理和を算出した物を暗号化します。
次に、暗号化されたブロック1とブロック2の排他的論理和をとり
それを暗号化した物を暗号化ブロック2とします。
上図のように、排他的論理和を算出しながら3DESの暗号化していく方式を
3DES-CBCという。排他的論理和をとる事により、より強度を増すという。
ちなみに、「IV」は、暗号を復元するため、相手側も知る必要があるので
ネット上では平文で流れていますが、問題ないようです。
|
ふぅ、一応、IPSeCの通信の話が書けた。
こんな手のこんだ仕組みにするのも、通信の安全性の確保が目的だからだ。
鹿児島でのフレッツADSL接続不可問題の解決
11月1日、接続ができない問題が発生した鹿児島対策を行った。
N社から鹿児島へ設定済みのルーター（RTX1000とRT105e）が届けられた。
RTX1000が送られたのは、もし、MRUが原因でない場合に、
RTX1000で試してみるという狙いがあった。
N社のFさんから、鹿児島の所長に接続の設定の説明が行われる。
そして、RT105eで接続を行うと・・・
無事、接続確立ができた！！！
これでようやく鹿児島も、インターネットVPNへ切り替えができるようになった。
N社の推測通り「MRUサイズ」が問題だった。
Fさんから「今後、他の拠点で、NTTの網終端装置が新しくなり、同じ問題が
今後も発生しないように、MRU値を1280から1454にします」と言ってきた。
これで鹿児島の問題は解決できた。
先代仙台営業所
残りは仙台と札幌になった。寒くなる時期に北国の設定。
鹿児島の事件以来、1泊作業に不安を感じるようになった。
何が起こるかわからない。それに遠隔地なので、問題が発生しても
すぐに行ける場所ではない。そこで予備日を設け、2泊3日の出張にした。
11月7日、仙台へ出張。
仙台空港に降りた。仙台は寒いかなぁと思い、防寒を整えたのだが、
意外と暖かいので、ちょっと拍子抜け (^^;;
びぎねっとのMLで知り合いになった村上さんとお会いする事になり、わざわざ
空港まで向かいに来てくださるということで、空港で待ち合わせする事になった。
さて、空港を出発した。のどかな田園風景が見える。
村上さんは乗馬をされておられ、なんと馬まで持っておられるという事で、
早速、村上さんの愛馬を見に行く事になった。
厩舎に着いて、村上さんの愛馬を見た。間近で馬を見るのは初めてだったので
すげーでかい！！
と思った。茶色の毛並みで、がっしりとした感じの馬だった。
携帯のカメラで、しっかり村上さんの愛馬を撮影！！
読者の方にも、お見せしたい所なのだが・・・
私の携帯カメラは画像データが抽出できないのらー (TT)
という事で、残念ながら村上さんの愛馬の写真を、お見せする事はできません m(--)m
村上さんから「馬にあげてみますか」と勧められ、氷砂糖を手の平に乗せて、
馬の口元まで持っていく。そして、馬が私の手をペロペロなめて、氷砂糖を食べる。
結構、くすぐったいのだが、愛嬌のある目を見て、かわいいなぁと思う。
ここで一つ発見！ 馬は氷砂糖を食べる！
どうも「馬＝ニンジン」の思い込みが強いため、氷砂糖を食べるのは意外だった。
厩舎では、村上さんの息子さん、娘さんが馬の世話をしていた。
家族総出で馬の世話で大変そうなのだが、馬を通して、村上家の家族団欒の場に
なっているのが垣間見える。仙台市街から車で20分の所で、周囲は田園風景で、
しかも厩舎があるというのは神戸にいると考えられない。
村上さんの話では「馬を飼ってから体が丈夫になった」という。
体を動かすためか、風邪知らずになったり、腰痛持ちだったのが治った話で
馬を飼い、乗馬をする事により健康になるという。
ちなみに、私の健康状態というと・・・。
運動不足の塊。椎間板ヘルニア。その他、色々と不健康の塊。
風邪引きやすいため、うがいを習慣づけても、風邪知らずにならないし、
疲労が取れないため、ドリンク剤に溺れた日々があったり、健康のために
ウコンを飲んだりと、ドーピングをして無理やり健康を保っている(?)ので
とても健康体とは呼べない ← かなりジジイ化しているかも (^^;;
そこで、私も馬を飼って、乗馬をして健康な体にして、しかも女の子に
モテモテという妄想を抱きたいのだが、神戸で馬を飼うのは物理的に難しいだけでなく
ピチピチギャルが、中年腹で容姿も良くない、31のオッサンの相手なんぞ、
100%するわけない現実がある (TT)
さて、仙台市内で、村上さんに美味しい寿司をごちそうになった。
自然が近くにあり、美味しい食べ物がある仙台。
仕事やプライベートで過去5回、仙台に来て、今回で6度目だが、
仙台に来る度に「ええとこや（良い所だ）」と思う。
この後、石巻の竹内さんと合流して3人で喫茶店で話が盛り上がる。
さて、8日に仙台営業所に乗り込む。設定は順調に進む。
予備日の9日は営業所で通信の点検等を行う。問題なし。
牛タンは食べた。ホヤは買った。これで仙台から帰る準備はOKだった。
札幌営業所
11月11日、札幌へ出張。
北海道といえば津軽海峡を渡らねばならない。
「上野発の夜行列車〜降りた時から〜青森駅は雪の中 ♪」と
津軽海峡冬景色の歌詞を連想してしまう。青函連絡船があった時代だ。
まぁ、関西からだと以前は、大阪〜青森まで走っていた特急「白鳥」があった。
だが、今は飛行機の時代だ。一応、豪華寝台特急（トワイライトエキスプレス）が
大阪〜札幌間を走っていてはいるが、お金と時間がないと乗れないのだ！！
千歳空港から札幌市内までJRで移動する事にした。
白樺の並木が見える。本州だと白樺は長野の高原ぐらいでしか見れないのに
北海道だと札幌市内でも普通に見る事ができる。
北海道は、相当、北にあるのだなぁと改めて感じてしまう。
ルーターの設定は問題なく終了した。
これで全ての営業所のVPNの設定は終わった。
この日、bluesさんのお誘いで、mixiの集まりに参加させていただいた。
参加者は、bluesさん、camusさん、ささきさん、どんさん、さわださん。
石鍋亭でジンギスカン鍋を食べる。北海道と言えば、ジンギスカン鍋は外せない！
遅くまで飲んで食べて満足した。
11月12日は、11日の作業で、問題が発生した時の予備日として
確保していたのだが、作業は完了していた事もあり、
埼玉・福岡・名古屋・高松で起こっている
P-COMMのデータ転送の対策をする事にした。
AS/400の技術的なホームページを検索して調べる。
そして、次の方法がある事を見つけた。
| Windows98で、msconfigコマンドを使い設定変更 |
|---|
 |
赤い部分の印を外せば良い設定。P-COMMをインストールした時にできるみたい。
この設定は、P-COMMの動作を速くするための設定だ。
|
そして、次に不要なパケットを出さない処置を行う。
営業所のパソコンのネットワークコンポーネントを見てみる。
| Windows98のネットワークコンポーネント |
|---|
 |
LLCドライバーという、SNAプロトコルの通信に使う物が入っている。
これは、P-COMMインストール時に、追加されるものだ。
|
埼玉でパケットキャプチャをした時、LLCのパケットが飛びんでいた。
もちろん、SNAでの通信を行うためにあるので、取り除いても問題はないのだが
この時は、LLCドライバーを取り除くと、P-COMMが動かなくなる心配していた。
いつものように、ドツボにハマるのを恐れていたからだ。
でも、LLCパケットのために、パケットが渋滞を起こしている可能性があるので
取り除く必要がある。
そこで、思い切って、削除する事にした。すると・・・
削除した後も、問題なく動いてくれた。
そこで、埼玉・福岡・高松・名古屋のパソコンを遠隔操作を行い、
札幌で見つけた2つの方法の処置を施した。
今後こそ、データ転送が遅くなる問題が解決してくれる事を願った。
この日、所長に北海道で人気のラーメン屋「純連」(すみれ)へ
連れてってもらった。
濃厚なスープ。これが人気の秘密だなぁと思った。
11月13日、関西に帰る日だ。問題発生していたら営業所へ行っているが、
幸い、何もない上、土曜日なので、観光に当てる。
最終の飛行機にしたので、思いっきり北海道を満喫できる。
朝、ホテルのベランダをのぞくと、雪が積もっていた。
前日、所長から「今晩、雪が降るかもしれないぞ」と言っていたのが当たった。
この日は小樽へ行く。小樽といえば、小樽運河が有名だ。
他にも、石原裕次郎記念館があるが、私の趣味ではないので行かない。
| 石原慎太郎、石原裕次郎は実は神戸出身 |
|---|
東京都知事で、TVで痛快な発言をしてくれる石原慎ちゃん事・石原慎太郎と
弟で、今も奥様方の人気の高い、故・石原裕次郎は、実は神戸出身なのです。
小樽出身と間違えた事を書いているサイトがありますが、実際は神戸出身です。
父親が山下汽船の小樽支店長に就任したため、神戸から小樽に移り住みました。
小樽が記念館になるのは、2人が育った場所が小樽である事に由来する。
|
北海道に来たのだから、美味しい魚介類を食べようと思い
バフンウニ丼を食べる。
変にケチって、後で「もっと食べたかった」と言うよりも
腹一杯食べた方が心残りもない。
ちなみに、ウニ丼の値段は、3300円だった。
寒いなぁと思って、電光掲示板の温度計を見ると、3.6度と出ていた。
まだ、11月なのに、そんなに気温が低いのかよと思った。さすがは北海道。
雪がちらついていた。寒いはずだと思う。
小樽といえば、ガラス細工の有名みたいだ。
早速、ガラス工房へ行く。ガラス吹きをやってみたかったのだが、
ちょっと値段が高かったのでやめた。
帰りの飛行機。高所恐怖症の私。早く地面のある所へ着いて欲しいと思う。
飛行機が揺れた途端、急降下し始めた。
「まさか、失速とちゃうやろか」と悪い方向へ考えてしまうのだが、
機内アナウンスで「予想以上に気流の状態が悪いため、高度を下げてます」と
流れたため、ホッとひと安心。しかし、生きた心地がしない (--;
ADSL方式の通信の仕組み
さて、回線状態だが、1ヶ所だけ悪い所があった。
10月中旬辺りから金沢営業所から「AS400の画面が落ちたりする」と連絡が
来るようになった。
最初、何が原因か、わからなかったが、AS400の画面が落ちたりする度合が
増えているという。
NTTに問い合わせると「ADSLが不安定の可能性がある」と言うことだ。
金沢営業所の場合、伝送損失が42dBだ。ADSL回線が不安定な事が考えられる。
H子さんが作った、ADSLが開通できるかどうか怪しい営業所の一覧を
見てみると、金沢は一覧の中に入っている。
NTTに問い合わせるが「色々な要因で、回線が不安定なので」と一点張り。
そこで、私は、ADSLについて、より詳しく調べる事にした。
まずは、伝送損失が何かを知る事から始めた。
信号の損失度合を示す数値だが、30とか、40と言われてもピンと来ない。
そこで、この数字の意味する所を調べてみると、
伝送損失が10の場合、電話局からモデムまでにたどり着くまでに
信号電力が10分の1。伝送損失が20の場合は、100分の1。
30の場合は、1000分の1にまで信号電力が減衰する。
まさに、対数の計算を連想してしまう。
そこで、数式を調べると次のような物がわかった。
| 伝送損失算出の数式 |
|---|
 |
デシベル(dB)は電話局からモデムまでにたどり着くまでに、
信号の電力がどれくらい減衰しているのかを表した物。
素直に、10分の1から1000分の1までのグラフをとると、
グラフのマス目が小さすぎて、人間の目ではわからなくなる。
そこで、減衰の割合が等間隔のマス目に見えるように、対数を使って、
人間の目でもわかるようにしている。
|
この式から伝送損失42dBの金沢の場合・・・
なんと1万5千分の1に減衰しているのだ！！
これを知って、信号電力の減衰度合に驚いたと同時に、よくモデムは
こんな小さな信号をキャッチしているなぁと感心してしまった。
ちなみに、一番伝送損失が大きい千葉の場合、56dBだった。
この場合、信号電力は何分の1に減衰するのか、計算をしてみると・・・
なんと40万分の1に減衰しているのだ！！
こんなに減衰しているのにも関わらず、安定して通信ができるとは驚きだ！！
ところで、ADSLが不安定になる原因として考えられるのは、
近隣のISDN回線による影響と思っていたが、AMラジオ局による影響もある。
金沢の場合、何が原因なのか、特定したい。
そこで、ADSL通信における干渉の問題を調べてみる事にした。
まずは、ADSL信号の場合、どんな周波数帯を使っているのか調べてみた。
| ADSL信号の周波数帯域 |
|---|
 |
これはDMT方式と呼ばれる方式で、トーン（波）が上りは26個、
下りは224個ある。この波を使って信号を送っている。
個々のトーンは独立しているので、一部のトーンが使えなくても、
他のトーンを使って信号を送る事ができる。
トーンの間隔は、4.3125kHzごとになっている。
ちなみに、電話の場合は、周波数帯は、0〜4kHzまでの範囲を使っていて、
ADSLが使っている周波数とは重複しないため、ADSLと電話は共有できる。
タイプ1（電話共有タイプ）が存在できるのは、このわけだ。
|
ところで、ISDNがあると、ISDNの影響で、ADSL信号が不安定になったりする。
その理由は以下の通りだ。
| ISDNによる干渉問題 |
|---|
 |
アメリカのISDNの規格だと、80kHz以下の周波数帯を使っているので、
ISDNによるADSLへの干渉問題は起こっていない。
しかし、日本のISDNの規格は、NTTがアホな設定をしたために、
こんな問題が起こってしまったのだ。
90年代後半、旧・郵政省の審議会で、散々、NTTはADSLの導入を渋っていた。
表向きは、ISDNによる干渉問題だが、実際の所は、ISDNに過剰投資をしたため、
利用者の利益を考えず、己の利益だけを考えて、高く売れるISDNを売るため、
ADSLの導入を渋っていた。
既に、アメリカでADSLが導入された時、日本ではNTTが「ISDNはじめちゃん」と
宣伝が流れていたのだ。
天才バカボンに出てくる「はじめちゃん」は天才赤ちゃんなのだ。
天才赤ちゃんを使って、愚かなISDNの宣伝を行うのは、いかがなものかと思う。
|
そんな国民の利益を無視したNTTだが、ISDNの干渉問題を緩和した
ADSLの規格を導入した。
さて、どんな規格を導入した事を説明する前に、ISDNの規格を軽く説明します。
| ISDNのピンポン方式 |
|---|
 |
日本のISDNの場合、ピンポン方式と呼ばれる物を使っている。
それは、上りと下りが1.25msごとに交互に入れ替わる(ピンポン)している。
|
上りと下りが交互に入れ替わっている。
さて、ISDNの影響は、電話局から発信されるISDN信号(下り)による影響よりも
近くの家や会社から発信される上り信号の影響を受ける。
| 近端漏話と遠端漏話について |
|---|
 |
ISDN回線の下り信号による影響を遠端漏話(FEXT)
上り信号による影響を遠端漏話(NEXT)と呼ばれる。
|
さて、これにより、ISDNによるノイズが出やすいタイミングがわかる。
| ISDNが発生するノイズについて |
|---|
 |
|
ISDN回線の下り信号が出ている期間と、上りの期間ではノイズの大きさが違う
|
この事から、NTTのADSLの規格では、次のような方法を使っている。
| ADSL信号の周波数帯域 |
|---|
 |
ISDNが下りの時、ノイズが小さいので、ADSLでは
多くデータ(ビット数)を送ろうとする。
そして、ISDNが上りのタイミングでは、ノイズが大きくなるため、
データの量(ビット数)を少なくして送って、ノイズの影響を減らそうとしている。
|
さて、金沢ではトーンが、どうなっているのか、わからない。
そこで、NTT西日本に電話をかけて、NTT側でトーン情報がとれないかを
聞いてみる事にした。
トーン情報といっても、窓口の人は、わからない。
いくつかたらい回しにあった後、トーン情報を出してもらう事にした。
| 金沢でのトーン情報 |
|---|
 |
これを見る限り、ISDNの干渉やAMラジオの干渉などを受けている形跡がない。
NEXTビットは、ISDNの上りのタイミングなので、ビット数は少ないと思いきや
FEXT(ISDNの下り)とあまり変わらない。なぜ?
|
ADSLが不安定な時間帯なら、何が原因か特定できるのだが、
どうやら、安定している時間帯のトーン情報みたいなので、
何が原因になっているのか、推測すらできない。
ただ、言えているのは、AMラジオの影響なら、四六時中、起こっていて
当然なのだが、安定している時間帯がある事から、ISDNの干渉が原因では
ないかと考えている。
金沢でのBフレッツ切り換えの打ち合わせ
N社のFさん、H子さんがやってきた。
金沢でADSLからBフレッツへ切り替えを行う場合の打ち合わせだった。
N社の依頼を受けた業者から人を出せば費用がかかる。
それだけでなかった。金沢営業所には事務員さんがいないため、
営業マンが外出中は、営業所は不在になる。
Bフレッツの工事と、ルーター設定のために、営業所の人の立ち合いが
必要になるが、それも難しい話だ。
営業マンと都合と、設定業者の都合の上、早急にBフレッツの開通する問題。
そこで考えた。私が行けば、交通費だけで済む上、Bフレッツの工事日と同日に
プロバイダーも開通させれば、立ち合いの問題も解消される。
「では、私が金沢へ行って設定を行いましょう」と言った。
Fさんも「そうしていただけると、助かります」と答えた。
Fさんからルーターの設定変更の手順書を送ってもらった。
数行のコマンドを入力する程度だったので簡単だと思った。
再々度、金沢営業所
11月25日、日帰りで金沢出張。
ADSL回線が不安定で使い物にならないので、Bフレッツへ切替えるためで
Bフレッツの工事の立ち合いと、ルーターの設定変更だ。
しかし、NTTの工事の人が約束の11時になっても来ない。
そして、電話が入り「2時になりますが」という内容だった。
「何、考えているねん」と思ったが、怒っても仕方ないので、
「わかりました」と答えた。
だが、2時になっても来ないので、工事担当に電話をかけたら
「もう一時間かかります」だったので、さすがに私もブチ切れ
「一体、どうなんてんだ。だいたい4時間も遅れるのは、どういう事だ。
こっちだって予定があるんだ。」と言った。
あまりにも頭に来たので、Bフレッツの窓口にも「どうなってるんだ！！」と
電話をかけた。
守れない約束だったら、最初からするなと言いたくなる。
予定より3時間40分遅れて、Bフレッツの工事が行われた。
そして、4時半ぐらいに工事が終了。
まずは、ルーターの設定変更を行う。あらかじめ、N社のFさんから
設定変更の手順を送ってもらっているので、それを見て変更を行う。
簡単に設定変更が終わった。
そして、ルーターをADSL回線から、Bフレッツに切り替えると、
無事、通信が行えた。Fさんも遠隔操作でルーターに接続して、
通信が無事行えている事を確認した。
これで金沢の通信の不安定な問題を解消できた。
さて、ADSL回線が空いたので、当初予定していたトーン情報を採取する事にした。
しかし、NTT西日本から紹介されたホームページが、金沢のモデムでは
使えない事がわかった。
私が他社のモデムを調達していたのであれば、私の責任になるのだが、
NTT西日本からのレンタルモデムだ。その事も、NTT西日本には説明してる。
思わず・・・
NTT西日本はウソつきやがた!!
ADSLと大々的に宣伝しながら、メタル回線を撤去している詐欺紛いの実態。
ISDN回線によるADSL回線の通信障害が起こっているにも関わらず、いい加減な態度。
ADSL回線の収容変えしても安定する保証がないのに、費用だけは取るエゲツなさ。
回線調査に非協力的な姿勢。守れない約束を平気でする無神経さ。
公社時代の殿様商売そのものだ。
仕方がないので、独自にgoogleを使って、トーン情報の採取する方法を調べるが
全く見つからない (TT)
ついに時間切れを向かえた。
そして、当初、予定していたADSLのトーン情報を調べるのを断念せざる得なかった。
Bフレッツの工事の遅れと、ウソのホームページを紹介したのは、
NTTが私の行動を妨害するためと、勘ぐりたくなった。
不運は続くもの。帰りのサンダーバードの指定席が満員で取れない。
仕方なく、米原行きの「しらさぎ」に乗り、米原から新快速で帰る (--;;
さて、帰りの「しらさぎ」で、北陸線の虎姫〜長浜間を走っている間、
車内の照明に注意深く見ていた。
この区間は、直流と交流との切り替えがあるため、各駅停車で使われる
新しくない車両だと、電源切り替えのため、車内照明が消える。
だが、「しらさぎ」は新型車両を使っていたため、車内照明が切れる事なかった。
そういえば、サンダーバードでも湖西線で直流と交流との切り替え区間である
永原〜近江塩津間でも照明が切れない。バッテリーが積んでいるのかなぁと思う。
P-COMMのデータ転送不具合障害の解決への道のり
金沢での回線の問題は解決できた。
しかし、解決できない大きな問題が横たわっていた。
P-COMMのデータ転送が遅い問題だった。
Fさんに、QoSの設定を営業所のルーターの変更をしてもらっていたのだが、
全く解決できない。
Fさんと話をすると、Fさんは「データ転送のパケットサイズが大きくて
ルーターの所で再送要求しているため、遅延が起こっているかもしれません」だった。
| Fさんが言った内容を図にすると |
|---|
 |
冷静に考えれば、分割不可能なDFビットを落としているから、
いくらパケットサイズが大きくても、ルーターの所で、詰まる事はないが、
頭の中が混乱していたのと、本職のSEの言う事だから、
完全に鵜呑みにしてしまった。これが混乱を大きくする原因になった。
そこで、Ethereal を使って、AS/400のパケットサイズを調べてみると、
MSS値が1452のパケットが飛んでいた。MTU値にすると、もう少し大きくなる。
これだと、MTU値が1280のIPSeCのトンネル内にパケットが通るのは無理だと思った。
この時、私は「今度こそ、データ転送が遅い原因がわかった」と思った。
そこで、J社のサポートセンターに電話をかけて、AS400のMTU値を下げる方法を
教えてもらう。
サポートセンターの人は「普通は、大きくする問い合わせばかりなのに、
小さくする話は初めてです」と驚いていた。
サポートセンターの人の言う通りにして、AS400の最大フレーム長を
見てみる。最大フレーム長が1492になっていた。
そこで、昼休みに、AS400を止める事を通達で流した。
| AS400の最大フレーム長を変更する作業 |
|---|
 |
これで、AS/400の最大フレーム長が最小の576になった。
もう、データ転送が遅いという問題はないだろうと思った。
しかし、「まだ、遅い」という報告がやってくる。
私は「最大フレーム長が576でも、まだ大きいのか」と思った。
そこで、J社のサポートセンターに、もっと最大フレーム長を短くできないかと
尋ねてみた。
「これが最小ですよ。ごめんなさい。こちらでは、どうしようもないです」という
答えが返ってきた。要するに、これ以上、フレーム長は小さくはできない。
完全に、頭の中は混乱に陥った。
Fさんに「ルーターの方で、MTU値を500ぐらいにできないか」と言ったみた。
私の混乱ぶりに気づいたFさんは「落ち着きましょう。原因の切り分けを
行っていきましょう」と言った。
これで冷静になった私だが、打つ手なしの状態。
メールができない障害発生
データ転送の問題で、解決の糸口が見えない状態が続いていた。
しかし、障害は、これが最後ではなかった。
11月後半に、名古屋の営業マンから「夜間になるとメールが読めなくなる」
という知らせが来た。そこで、名古屋営業所に電話をかけてみた。
事務員さんは「私がいる時は問題なくメールが読めています」という
回答を得た。
上司が「以前、千葉などで起こっていた現象か」と聞いてきたので、
私は「また、別の要因でしょう」と答えた。
PMTUブラックホール問題は解消されたため、一体、何の問題か全く見当がつかない。
何も手が打てないまま、12月を迎える。
埼玉から「以前から、晩になるとメールが読めない」という知らせがきた。
さらに奇妙な事に「一台のパソコンからだと、AS400につながらないけど、
もう一台からだと、AS400に接続できるけど、なんで?」だった。
この時、私も「なんで?」だった。
上司は、全営業所に、メールが読めない現象が起こっているのか
アンケートをとる事にした。
千葉、鹿児島でも、晩になるとメールが読めない現象が起こっている事がわかった。
まずは、名古屋に依頼して、夜間、パソコンを立ち上げたままにしてもらった。
そして、私は自宅から社内のネットワークに入り、VNCで遠隔操作を行った。
そして、メーラである、OutlookExpress を開くと、エラーが出た。
エラー番号が「 0x800C0131 不明なエラー」と出た。
念のため、パケットがメールサーバーまで飛んでいるか、pingで確認をしたら、
問題なく飛んでいた。
「一体何やろ」と思い、googleで調べると、MSのサイトに解決法が書かれていた。
それを実践すると、問題が解消された。
翌日、出社する。名古屋の原因を報告するが、埼玉・千葉・鹿児島から
報告されたメールが読めない問題は、名古屋と原因が同じかどうか、
全くわからない。
翌日は日曜日。だが、別件で休日出勤の予定が入っていたので、
原因の調査ができると思った私は、原因の尻尾を掴むため、営業所に依頼して、
夜間と日曜日は、パソコンを立ち上げたままにしてもらう事にした。
パケット採取しながら原因を特定していく
12月5日。この日は日曜日だったが、休日出勤を行った。
この時、埼玉や福岡のパソコンの電源を入れたままにしてもらっていた。
埼玉のパソコンを遠隔操作をしてみる。
埼玉のパソコンでメールを開こうとするが、メールサーバーに
接続できないエラーが発生する。何度やっても同じエラーがでる。
ふと、DOSプロンプトの画面を出して、ping ドメインのコマンドを打つと
pingが反応せぇへん （・・）
そして、unknown hostというエラーが出た。
この時、DNS検索ができていない事がわかった！！
この時、営業所でメールが読めない、インターネットの閲覧ができない謎が解けた。
DNS検索ができないため、接続先がわからず、エラーが出るというわけだ。
ようやくメールが読めない原因の尻尾を掴めた！！
この時、埼玉で起こっていた謎の現象が解けた。
埼玉で、AS/400に接続できないパソコンと、AS400に接続できるパソコンがある。
一台は、接続先の設定をホスト名で記述し、もう一台はIPアドレスで記述している。
ホスト名で記述したパソコンで、AS400に接続できない現象が起こっていたが
これで合点がいく。DNS検索ができなければ、接続先がわからずに、
接続できないままになる。
不思議な事に、ping (IPアドレス)を使って刺激を与えると
DNS検索ができるようになり、メールサーバーへの接続が可能になり、
メールが読めたりする。しかし、しばらくすると、また接続できなくなったりする。
本当に、奇妙な現象だ。
自宅に帰るが、営業所のパソコンからDNS検索ができない謎が気になる。
そこで、データを採取して、分析しようと考えた。
会社のNATマシンへ接続して、tcpdumpで、DNSのパケットの採取を行う。
ある営業所から、KEK（高エネルギー加速器研究機構）のWebサーバーへ
pingを飛ばしてみる事にした。
まず、tcpdump -i eth1 port domainを使ってDNSのパケットを受信できるようにする。
そして、ping www.kek.jpをして、DNS検索を行う様子を見てみる。
| tcpdump -i eth1 port domainの結果 |
|---|
00:13:00.003856 dsp1211.xxxx.co.jp.1330 > nat.xxxx.co.jp.domain: 1+ A? www.kek.jp. (28) [tos 0x8]
00:13:05.504284 dsp1211.xxxx.co.jp.1330 > nat.xxxx.co.jp.domain: 1+ A? www.kek.jp. (28) [tos 0x8]
00:13:16.006090 dsp1211.xxxx.co.jp.1330 > nat.xxxx.co.jp.domain: 1+ A? www.kek.jp. (28) [tos 0x8]
00:13:31.511825 dsp1211.xxxx.co.jp.1330 > nat.xxxx.co.jp.domain: 1+ A? www.kek.jp. (28) [tos 0x8]
00:13:52.011291 dsp1211.xxxx.co.jp.1331 > nat.xxxx.co.jp.domain: 2+ A? www.kek.jp.xxxx.co.jp. (46) [tos 0x8]
00:13:57.516226 dsp1211.xxxx.co.jp.1331 > nat.xxxx.co.jp.domain: 2+ A? www.kek.jp.xxxx.co.jp. (46) [tos 0x8]
00:14:08.016698 dsp1211.xxxx.co.jp.1331 > nat.xxxx.co.jp.domain: 2+ A? www.kek.jp.xxxx.co.jp. (46) [tos 0x8]
00:14:23.597440 dsp1211.xxxx.co.jp.1331 > nat.xxxx.co.jp.domain: 2+ A? www.kek.jp.xxxx.co.jp. (46) [tos 0x8]
00:14:46.409357 dsp1211.xxx.co.jp.netbios-ns > nat.xxx.co.jp.domain: 4044+ A? WWW.KEK.JP. (34) [tos 0x8]
00:14:47.906160 dsp1211.xxx.co.jp.netbios-ns > nat.xxx.co.jp.domain: 4044+ A? WWW.KEK.JP. (34) [tos 0x8]
00:14:49.405531 dsp1211.xxx.co.jp.netbios-ns > nat.xxx.co.jp.domain: 4044+ A? WWW.KEK.JP. (34) [tos 0x8]
00:14:50.905561 dsp1211.xxx.co.jp.netbios-ns > nat.xxx.co.jp.domain: 4044+ A? WWW.KEK.JP.xxx.co.jp. (52) [tos0x8]
00:14:52.405396 dsp1211.xxx.co.jp.netbios-ns > nat.xxx.co.jp.domain: 4044+ A? WWW.KEK.JP.xxx.co.jp. (52) [tos0x8]
00:14:53.904171 dsp1211.xxx.co.jp.netbios-ns > nat.xxx.co.jp.domain: 4044+ A? WWW.KEK.JP.xxx.co.jp. (52) [tos0x8]
00:14:55.404252 dsp1211.xxx.co.jp.netbios-ns > nat.xxx.co.jp.domain: 4044+ A? WWW.KEK.JP.co.jp. (40) [tos 0x8]
00:14:56.903525 dsp1211.xxx.co.jp.netbios-ns > nat.xxx.co.jp.domain: 4044+ A? WWW.KEK.JP.co.jp. (40) [tos 0x8]
00:14:58.403527 dsp1211.xxx.co.jp.netbios-ns > nat.xxx.co.jp.domain: 4044+ A? WWW.KEK.JP.co.jp. (40) [tos 0x8]
|
採取したデータを見ていると、以下の事がわかる。
検索するはずのドメインのwww.kek.jpが検索できないため、
クライアントが「www.kek.jp」はホスト名だと予想しているが、
それでも検索できないため、ついには、NetBIOSの名前解決のパケットを
出している様子が伺える。
要するに、名前解決ができていない様子が、よくわかる。
何かの拍子で、DNS検索ができるようになると、次のようなパケットの動きになる。
| tcpdump -i eth1 port domainの結果 |
|---|
00:23:00.551080 dsp1211.xxx.co.jp.1375 > nat.xxxx.co.jp.domain: 1+ A? www.kek.jp. (28)
00:23:00.560105 nat.xxxx.co.jp.domain > dsp1211.xxx.co.jp.1375: 1 2/3/1 CNAME ccwww.kek.jp., (149) (DF)
00:23:00.560333 nat.xxxx.co.jp.domain > dsp1211.xxx.co.jp.1375: 1 2/3/1 CNAME ccwww.kek.jp., (149) (DF)
|
青い部分は、クライアントからDNS検索の問い合わせのパケット。
ピンクの部分は、DNSサーバーからクライアントへの応答のパケット。
|
他の営業所でも、同じ現象が起こっているのか、確かめる事にした。
やはり、DNS検索ができていない事がわかった。
パケットには、DFフラグがたっている事がわかる。
ふと思った。9月にメールやインターネット接続ができない原因として
PMTUブラックホール問題という事で、VPNルーターに、DFビットを落とす設定を
してもらった。
そこで、メールやWebのパケットが、DFフラグがついているかどうか確認をすると
予想通り、ついていた。
この時、9月に発生した問題の真相がハッキリわかった。
ひょんな事で、今までハッキリしていなかった原因がわかるのだなぁと思った。
さて、各種データの採取などをしていると時間が経つのを忘れる。
時計の針を見て午前3時。さすがに、眠いので、どういう症状が出ているのか
N社のFさんにメールを書く事にした。
| Fさんへのメール |
|---|
現在も、千葉、福岡、鹿児島、埼玉でメールやインターネットの閲覧が
時間帯（特に夜間）によっては、できないという報告を受けました。
（報告していない営業所もあります）
VNCを使い、営業所のパソコンを遠隔操作をしまして、
メールやインターネットができない状態の時、
どんな状態になっているかを調べてみました。
VNCのパケットは問題なく、やりとりできていますため、
遠隔操作は問題なく行えるのですが、その間に、メールや
インターネットが使えない症状が発生しました。
原因を調べてみますと、症状の発生時に、DNS検索が
できていない事が、わかりました。
症状が起こっています間、 ping （ドメイン名） を使っても、
何も反応が返ってこない事から、DNSの検索に問題ありと
考えています。
念のため、DNSサーバーに、パケットを採取するコマンドを仕掛け、
確かめました所、症状が出ていない時は、営業所からのDNS問い合わせの
パケットに対する返答のパケットが飛んでいるのに、症状が出ている時は、
返答のパケットが出ていない事が、わかりました。
---------------------------------------------------------------------------
00:12:52.798528 dsp1211.xxxx.co.jp.1369 > nat.xxxx.co.jp.domain: 1+A? www.kek.jp. (28)
00:12:58.300010 dsp1211.xxxx.co.jp.1369 > nat.xxxx.co.jp.domain: 1+A? www.kek.jp. (28)
00:13:08.802640 dsp1211.xxxx.co.jp.1369 > nat.xxxx.co.jp.domain: 1+A? www.kek.jp. (28)
00:13:24.302821 dsp1211.xxxx.co.jp.1369 > nat.xxxx.co.jp.domain: 1+A? www.kek.jp. (28)
00:13:44.799021 dsp1211.xxxx.co.jp.1370 > nat.xxxx.co.jp.domain: 2+A? www.kek.jp.xxxx.co.jp. (46)
00:13:50.302576 dsp1211.xxxx.co.jp.1370 > nat.xxxx.co.jp.domain: 2+A? www.kek.jp.xxxx.co.jp. (46)
00:14:00.805923 dsp1211.xxxx.co.jp.1370 > nat.xxxx.co.jp.domain: 2+A? www.kek.jp.xxxx.co.jp. (46)
00:14:16.315692 dsp1211.xxxx.co.jp.1370 > nat.xxxx.co.jp.domain: 2+A? www.kek.jp.xxxx.co.jp. (46)
00:14:39.138445 dsp1211.xxxx.co.jp.netbios-ns > nat.xxxx.co.jp.domain:4592+ A? WWW.KEK.JP. (34)
00:14:40.640713 dsp1211.xxxx.co.jp.netbios-ns > nat.xxxx.co.jp.domain:4592+ A? WWW.KEK.JP. (34)
00:14:42.139035 dsp1211.xxxx.co.jp.netbios-ns > nat.xxxx.co.jp.domain:4592+ A? WWW.KEK.JP. (34)
00:14:43.638686 dsp1211.xxxx.co.jp.netbios-ns > nat.xxxx.co.jp.domain:4592+ A?WWW.KEK.JP.xxxx.co.jp. (52)
---------------------------------------------------------------------------
内容は、 ping www.kek.jp を東京支店から打った場合ですが、
東京支店からパケットを飛ばしても、返答がないため、５回目からは
www.kek.jp.xxxx.co.jp. で、DNSの問い合わせを行い、
それでもダメなので、９回目からは、NetBIOSでの名前解決を行っているという様子
です。
参考のため、正常にDNS検索ができる場合の内容も書きました。
----------------------------------------------------------------------------
00:23:00.551080 dsp1211.xxxx.co.jp.1375 > nat.xxxx.co.jp.domain: 1+A? www.kek.jp. (28)
00:23:00.560105 nat.xxxx.co.jp.domain > dsp1211.xxxx.co.jp.1375: 1 2/3/1 CNAME ccwww.kek.jp., (149) (DF)
00:23:00.560333 nat.xxxx.co.jp.domain > dsp1211.xxxx.co.jp.1375: 1 2/3/1 CNAME ccwww.kek.jp., (149) (DF)
----------------------------------------------------------------------------
試した回数が少ないため確実とは言えないのですが、ある営業所で、
DNS検索が出来ていない間は、他の営業所でも出来ていないようです。
ただ、症状が出ています時間帯でも、本社ですと、問題なくDNS検索が出来ています。
パソコンの再起動や、ping IPアドレス を打った後、なぜか、
DNS検索が正常に動くようになるという奇妙な事も起こったりします。
ここで考えられますのは、
(1) DNSサーバーがおかしい
(2) 本社にDNSの問い合わせのパケットがやってくるまでに、
パケットが破壊されている。
ここまで来て、対策方法が思いつかないため、頭を抱えていますが、
引き続き、対策法を調べてみたいと考えています。
もし、Fさんの方で、対策法がわかりましたら、
教えていただけませんでしょうか。
DNS検索が上手にいかない件ですが、DNSの問い合わせの
パケットサイズや、解答のパケットサイズが大きくても150バイトのため
VPN回線を通過する際、どこかで詰まってしまう可能性は
考えられない状態です。
もし、どこかで詰まれば、もっと大きいパケットでやりとりしています
VNCまでが止まってしまいますためです。
|
この時、私はDNSサーバーと、DNSパケットが途中で破壊されると考えた。
そして、とりあえずは寝る事にした。
朝、いつもの如く、7時に起きる。
さすがに、寝不足はキツイ。出社して原因について報告する。
早速、DNSサーバーの設定を見るが、どこにも、おかしな場所が見つからない。
何度も見直すが見つからない。どうやら、DNSの設定が問題ではなさそうだ。
Fさんから電話がかかってきた。
DNSのパケットが、まともに飛んでいない話になるが、お互い、原因が全く
原因が特定できないので、考え込む。
もしかして、DNSのパケットが、UDPなので、途中で破壊されても
パケットの損傷が送信元のクライアントに届かいないため、
DNS検索ができない状態の可能性がある事を話した。
全く可能性としてはゼロではないので、Fさんも「どうなんだろう」という
感じだった。
そこで、一つの方法として、東京支店だけ、QoSの設定で、DNSのパケットを
優先的に流す設定をしてもらう事にした。
Fさんから「DFの記号は、DFビットの事ですか？」と聞かれたので、
私は「そうです。これが原因で、9月にネット接続やメールが読めない
原因だったのです」と答えたら、Fさんが「なるほど」と答えた。
さて、DNS検索ができない原因が特定できない上、対処療法すら見つからない。
そこで、BLUEのMLに助けを求める事にした。
| 私がBLUEに投稿した内容 |
|---|
菅＠Linux好き事務員です。
おはようございます。
困った時のBLUE頼みです m(--)m
本社・営業所間で、インターネットVPN導入しましたのですが、
時間帯によって、メールやインターネットの利用ができないという
営業所が出ています。特に、夜間に出ています。
VPNの方式は、IPSeC 方式で、ルーターは、ヤマハ RTX1000（本社）
RT105e （営業所）を使っています。
そこで、VNCを使い、営業所のパソコンを遠隔操作をしまして、
メールやインターネットができない状態の時、
VNCのパケットは問題なく、やりとりできていますため、
遠隔操作は問題なく行えるのですが、
メールやインターネットが使えない現象が起こっていました。
原因を調べてみますと、症状の発生時に、DNS検索が
できていない事が、わかりました。
症状が起こっています間、 ping （ドメイン名） を使っても、
何も反応が返ってこない事から、DNSの検索に問題ありと
考えています。
念のため、DNSサーバーに、tcpdump コマンドを使い、
パケットの様子を、確かめました所、症状が出ていない時は、
問題なく、パケットのやりとりができているのですが、
症状が出ている時は、営業所からDNSサーバーへ問い合わせの
パケットが飛んでいるのですが、それに対する返答のパケットが
返答のパケットが出ていない事が、わかりました。
（ tcpdump -i eth1 -S port domain の結果）
192.168.50.10 は、ある部署のIPアドレスで、nat.xxxx.co.jpは
本社のDNSサーバーです。
----------------------------------------------------------------------------
00:12:52.798528 192.168.50.101.1369 > nat.xxxx.co.jp.domain:1+A? www.kek.jp. (28)
00:12:58.300010 192.168.50.101.1369 > nat.xxxx.co.jp.domain:1+A? www.kek.jp. (28)
00:13:08.802640 192.168.50.101.1369 > nat.xxxx.co.jp.domain:1+A? www.kek.jp. (28)
00:13:24.302821 192.168.50.101.1369 > nat.xxxx.co.jp.domain:1+A? www.kek.jp. (28)
00:13:44.799021 192.168.50.101.1370 > nat.xxxx.co.jp.domain:2+A ?www.kek.jp.xxxx.cp.jp. (46)
00:13:50.302576 192.168.50.101.1370 > nat.xxxx.co.jp.domain:2+A? www.kek.jp.xxxx.cp.jp. (46)
00:14:00.805923 192.168.50.101.1370 > nat.xxxx.co.jp.domain:2+A? www.kek.jp.xxxx.cp.jp. (46)
00:14:16.315692 192.168.50.101.1370 > nat.xxxx.co.jp.domain:2+A? www.kek.jp.xxxx.cp.jp. (46)
00:14:39.138445 192.168.50.101.netbios-ns >nat.xxxx.co.jp.domain:4592+ A? WWW.KEK.JP. (34)
00:14:40.640713 192.168.50.101.netbios-ns >nat.xxxx.co.jp.domain:4592+ A? WWW.KEK.JP. (34)
00:14:42.139035 192.168.50.101.netbios-ns >nat.xxxx.co.jp.domain:4592+ A? WWW.KEK.JP. (34)
00:14:43.638686 192.168.50.101.netbios-ns >nat.xxxx.co.jp.domain:4592+ A WWW.KEK.JP.xxxx.cp.jp. (52)
----------------------------------------------------------------------------
内容は、ある営業所から「ping www.kek.jp 」を打った場合ですが、
営業所からパケットを飛ばしても、返答がないため、５回目からは
www.kek.jp.xxxx.cp.jp. で、DNSの問い合わせを行い、
それでもダメなので、９回目からは、NetBIOSでの名前解決を
行っているという様子です。
参考のため、正常にDNS検索ができる場合の内容も書きました。
----------------------------------------------------------------------------
00:23:00.551080 192.168.50.101.1375 > nat.xxxx.co.jp.domain: 1+A? www.kek.jp. (28)
00:23:00.560105 nat.xxxx.co.jp.domain > 192.168.50.101.1375: 1 2/3/1 CNAME ccwww.kek.jp., (149) (DF)
00:23:00.560333 nat.xxxx.co.jp.domain > 192.168.50.101.1375: 1 2/3/1 CNAME ccwww.kek.jp., (149) (DF)
----------------------------------------------------------------------------
試した回数が少ないため確実とは言えないのですが、ある営業所で、
DNS検索が出来ていない間は、他の営業所でも出来ていないようです。
ただ、症状が出ています時間帯でも、本社ですと、問題なくDNS検索が出来ています。
パソコンの再起動や、ping IPアドレス を打った後、なぜか、
DNS検索が正常に動くようになるという奇妙な事も起こったりします。
ここで考えられますのは、
(1) 本社のDNSサーバーがおかしい
(2) 本社にDNSの問い合わせのパケットがやってくるまでに、
パケットが破壊されているため、DNSサーバーが応答しない。
DNSのやりとりのパケットサイズの問題を考えてみたのですが、
大きくても150バイトのため、VNCのパケットよりも小さいため、
パケット長のために、経路上で引っかかっている可能性は
まずないと考えています。
一体、DNSのパケットが、どうなっているのか、見当もつきません。
もしよろしければ、この現象をご存知の方は、教えていただけませんでしょうか。
すみませんが、よろしくお願い致します m(--)m
|
メールを投稿して、一旦、自宅へ帰る事にした。
ネットワークを止められるのは夜間しかない。
ネットワークを止めて、徹底的に調べる必要があるからだ。
となると、徹夜という事になるのだが、4時間しか寝ていない状態で
徹夜となると体がもたないので、会社に許可をとって、午前中に切り上げて、
ゆっくり寝て、深夜に出社してデータの収集を行う事を考えた。
さすがに、30越えると徹夜はキツイ・・・ （＞＜）
午後になり、とりあえず自宅に帰る事にした。
しかし、家に着いたが、このまま寝るわけにはいかない。
困った時のBLUE頼みで、BLUEのMLに投稿した際に、色々な方々から
お返事のメールをいただいたので、それを無視して寝るわけにはいかない。
自宅へ帰ると、磯部さんからお返事がきていた。
| 磯部さんからお返事 |
|---|
磯部です。お疲れ様です。
少し気になったのですが、記述されているログで
「cp」となっているのですが、正しくは「co」ではないのですか？
---------------------------------------
00:13:44.799021 192.168.50.101.1370 > nat.xxxx.co.jp.domain: 2+A?
www.kek.jp.xxxx.cp.jp. (46)
^^
↑この部分です。
----------------------------
もしこのDNSサーバ設定が誤りの場合、
正しく起動するDNSサーバを使用されているときと
誤った設定のDNSサーバを使用されているときが存在していて、
そのためメールやインターネットの利用ができない時間帯が
できてしまっているといったことは考えられないでしょうか？
|
営業所のパソコンのDNSの設定で「co」と「cp」を
入力間違いする、おバカな私 (^^;;;
だが、そこの部署以外は正しく入力できているため、原因ではなかった。
加藤さんからのお返事をいただいた。
| 加藤さんからのお返事 |
|---|
> 念のため、DNSサーバーに、tcpdump コマンドを使い、
> パケットの様子を、確かめました所、症状が出ていない時は、
> 問題なく、パケットのやりとりができているのですが、
> 症状が出ている時は、営業所からDNSサーバーへ問い合わせの
> パケットが飛んでいるのですが、それに対する返答のパケットが
> 返答のパケットが出ていない事が、わかりました。
キャプチャは通信がおかしくなった部署でされているのですよね? DNS サーバ
の付近でそこからの通信が来ているかチェックされてはいかがでしょう?
|
そういえば、営業所の周辺でパケットキャプチャをしていないので、
営業所の周辺のネットワークでは、パケットがどうなっているのか
調べる必要がある。
そこで、営業所に電話をかけて、しばらく遠隔操作をさせてもらう事を伝えた。
営業所のパソコンに、Etherealをインストールして、動かしみたいが
Microsoftお得意の不正な処理が出る！！
どうやら、Windows98だと、エラーが出て動かないようだ。
念のため、いくつかの営業所のパソコンに、Ethrealを入れてみたものの、
どの営業所でも「不正な処理」が表示され、動かない (TT)
おのれ！ MSめ！ てーめーはアホか！ (--メ
と思ったが、MSに怒り炸裂をする余裕がない。
しばらくして、後藤さんからお返事をいただいた。
| 後藤さんからお返事 |
|---|
> 通信がおかしくなった部署では、キャプチャは行っていません。
> キャプチャを行いたかったのですが、Ethereal を立ち上げたくても
> 「不正な処理」とMSの大好きな表示に阻まれ、できない状態です (TT)
先に以下のような事を書かれていたという事は、DNS サーバ自身で
キャプチャを行ってみると、クライアントからの問い合わせパケットは
来るのに、それに対して応答していないということでしょうか？
> > > 症状が出ている時は、営業所からDNSサーバーへ問い合わせの
> > > パケットが飛んでいるのですが、それに対する返答のパケットが
> > > 返答のパケットが出ていない事が、わかりました。
問い合わせパケットの内容が正しいのに DNS サーバが応答を返さないと
いうのであれば、それは DNS サーバ側の問題だとなりますが…
ところで、ヤマハのルータは結構頻繁にファームウェアのバージョン
アップが行われます。で、そのバージョンアップの理由は機能強化の
場合もありますが、結構バグフィックスも多いんですよね。
RTX1000 や RT105e をいつ購入したのかわかりませんが、在庫状況などに
より、購入した機材のファームウェアのバージョンがかなり古いことが
あります。
RTX1000, RT105e ともにファームウェアのバージョンは現時点での
最新バージョンにはしているのでしょうか？
|
9月に、営業所のルーターのファームウェアのバージョンアップを行っているし
RTX1000は最新のバージョンを入れていると思った。
この時は、バージョンの問題はないだろうと思ったが、以下のように、
後藤さんからの、ご指摘をいただいた。
| 後藤さんからのご指摘 |
|---|
> 設置、設定をしてくれました業者によれば、
> 9月時点での最新のバージョンを入れていますとの事です。
今年の 9月だと RT105e は 2004年 5月以降に新しいファームウェアは
出ていませんが(もう生産停止機種ですしね)、RTX1000 は 10月に
新しいものが出ています。
RTX1000 は面倒なことにファームウェアが 7.00系、7.01系、8.01系と
3系統あります。7.00系は 2003年 12月以来更新がありませんが、
菅さんのところではどれをお使いでしょうか？
10月の更新では機能追加の他に 7.01系では 88個ものバグフィックスが
行われ、8.01系では結構 fatal なバグフィックスが行われています。
ついでながら、私の経験によるとバージョンについては「XX月時点での
最新バージョンです」という類いの言い回しはアテになりません。
# 私も最新バージョンにしてますか？ なんて書いちゃいましたが。(^^;;
何が「最新」なのかなんて、その人のチェックが甘ければそれまで
ですから。必ず「XX.YY.ZZ です」というゆうな正確なバージョン番号を
用いないと誤解が生まれることがありますから。
|
そこで、Fさんから送られて来たコンフィグを見て、本社のRTX1000の
ファームウェアのバージョンを調べる。Ver7.01.34だった。
そして、ヤマハのダウンロードのサイトを見て、最新バージョンを確認。
最新バージョンは、2004年10月に出ていて、Ver7.01.41だった。
Ver7.01.34だと、バグが88個も出ているから、これが原因である可能性も
十分に考えられる。
ファームウェアのバージョンアップだが、100%、私が行う事になると思う。
バージョンアップを行う事をFさんにメールで連絡すると、
| 私がFさんへ送ったメール |
|---|
RTX1000のファームウェアーが10月12日にバージョンアップしています。
現在、使っていますのが、Rev.7.01.34ですが、最新バージョンは、
Rev.7.01.41です。
88個のバグフィックスがされたようです。
http://www.rtpro.yamaha.co.jp/RT/docs/relnote/Rev.07.01/relnote_07_01_41.html
私の方でバージョンアップしようと考えていますが
tftpでルーターに入る際は、パスワードが必要なのですが、
本社のルーターのパスワードを教えていただけませんでしょうか。
バグフィックスの内容には、DNSの話などは書かれていませんでしたが、
これで解消できれば、良いかなぁと思っています。
|
すると、次の返事が返ってきた。
| Fさんからのメール |
|---|
ファームのバージョンアップについては、十分に気をつけて
された方が良いかと思います。TFTPでリモートからもアップが
可能ですが、通常はオンサイトで行います。
失敗すると間違いなく動かなくなりますので。
|
これを読んで「オンサイトって何?」と思った。
どういう事なのか意味がわからなかったので、Fさんに電話して聞いてみた。
Fさんは「営業所のルーターのファームウェアのバージョンアップを
遠隔操作で行うのは聞いた事はないですし、できるか保証がないです」だった。
これを聞いて私は「メールの内容、キチンと読んでへんな・・・ (--;;」と思った。
Fさんに「本社だけですよ。RT105eは、9月のバージョンアップが最新ですよ」
と言うと、「そうでした」と答えた。
どうやらFさんは、何か勘違いしていたみたい・・・。
Fさんに、ルーターのパスワードを送ってもらう事にした。
そして、碇さんから、お返事をいただく。
| 碇さんからのお返事 |
|---|
> (1) 本社のDNSサーバーがおかしい
> (2) 本社にDNSの問い合わせのパケットがやってくるまでに、
> パケットが破壊されているため、DNSサーバーが応答しない。
3 IPSecのセッションが切れて通信できないに一票
RTX1000側でkeep何チャラってのがあったらそれ設定すればOKだとおもう。
このコマンドで、接続を維持できるんじゃないかしら?
ipsec ike keepalive use GATEWAY SW
http://www.rtpro.yamaha.co.jp/RT/docs/ipsec/command.html#ipsec.ike.keepalive.us
|
碇さんからのお返事を見て、N社のFさんにメールで依頼してみた。
そして、Fさんからメールがやってきた。
| Fさんからのメール |
|---|
下記の内容につきましては、本日IPSecのセッション状況を
確認したところ切れているといった事象は確認できませんでしたので
今回の問題には関係ないかと思われます。
パケット自体はサーバまで届いておりますので、パケットの中身に
問題があるかどうか弊社でも調査を行ってみたいと思います。
|
Fさん曰く「IPSeCのセッションが切れるのが原因とは思えない」だった。
となると、何が原因なのかが、わからない。
しかし、問題解決への作業内容が、だいたい頭の中で考えついた。
Etherealを使ってパケットキャプチャを使って、パケットを調べる事。
RTX1000のファームウェアのバージョンアップ。
あとは、詳細なログを取る。
そして、東京支店だけ、QoSの設定をしてもらったので、東京支店で
DNS検索ができるかどうかの確認だ。
夕方に少し仮眠した。さすがに、寝ないで作業は体がもたない。
頑丈な体だと問題はないが、あまり丈夫でないので、無理はできない。
そして、晩の9時くらいに家を出発。10時くらいに会社に到着した。
RTX1000のファームウェアーの更新
さて、tcpdump でパケットの様子を見た時に気がついたのだが、
DNS検索ができていない時、DNSサーバーから戻りのパケットが発信されていない。
そこで、DNSサーバーのログを見てみる事にする。
実は、DNSの設定で、ログを採取の設定は行っていないのだが、
異常が出た場合には、/var/log/messageに書き込まれる。
（RedHat7.3の場合、初期設定でそうなってみるみたい。他はわかりません）
そこで、該当のファイルを見てみるのだが・・・
時間が狂っている！！！
NATマシンの時間がおかしいのだ。これではログを正しく見れない。
ふと、思った。NAT & DNSサーバーの時間が正確でないため、DNS検索が
できなくなるのではと思った。
システムの時計がおかしい場合、ログが正しく見れないだけでなく、
アプリケーションなどが正確に動かなくなる事もあるからだ。
詳しくは「システム奮闘記：その15」(時間の正確さの重要性)をご覧ください。
そこで、時間を正確にする事にした。
| 時間の調整 |
|---|
[root@log]# date
2004年 12月 6日 月曜日 21:22:15 GMT+9
[root@log]# ntpdate -b time.xxxx.co.jp
6 Dec 04:39:38 ntpdate[5121]: step time server XXX.YYY.ZZZ.AAA offset -60246.401026 sec
[root@log]# date
2004年 12月 6日 月曜日 04:39:41 GMT+9
[root@log]# timeconfig Asia/Tokyo
[root@log]# date
2004年 12月 6日 月曜日 22:40:53 JST
|
時間を正確にした。そこで、営業所から、ping (ドメイン)を使ってみた。
DNS検索ができるようになったので、やれやれと思ったが、一時的な解消であって、
また、DNS検索ができなくなった。
システム時間が原因でない事がわかった。
Fさんには、QoSで解消できないかという事で、東京支店のルーターだけ
QoSの設定で、DNSのパケットを優先させるようにしたのだが、
DNS検索ができない状態だった。QoSでも解消していない。
ならばと思い、本社のルーター（RTX1000）のファームウェアーの
バージョンアップをする事にした。結果は・・・
全くアカンかった (TT)
そこで、ダメ元で、iptablesの設定を外して、ザルの状態にする。
iptablesの設定が悪さをしている可能性も考えられるからだ。
しかし、結果は・・・
やっぱりダメだった (TT)
万事休す。
時計の針が午前6時を指していた。もう体力的にも、しんどくなったので
とりあえず、切り上げる事にした。
原因はDNSサーバーの位置だった
7時に家につき、朝食を食べる。だが寝る前に、メールを読む事にした。
| YamYasさんからのお返事 |
|---|
一連のやり取りを見ると、まず切り分けができていないようです。
・DNSサーバまで、パケットが届いていますか？
-> 届いていないようであれば、通信路に問題あり！？
・DNSサーバがリクエストを受け付け／応答してますか？
-> DNSサーバのログを確認しましょう！
・DNSサーバからパケットがでていますか？
-> 出ていないのであれば、サーバ側のネットワーク関連に問題あり！？
・クライアントにパケットは届いていますか？
-> 届いていないのであれば、通信路に問題あり！？
どこに問題があるか解かれば、もっと対応は楽になるとおもいますよ。
|
完全に頭の中が混乱状態になっていたので、このお返事を読んで
少しは冷静になった。
DNSのログ。どうやってログをとるのか、わからない。
そのため、BINDの勉強を突貫工事で行う事にした。
タナカさんから、お返事をいただいた。
| タナカさんからのお返事 |
|---|
> 営業所からの問い合わせに応答していない状態でも、
>なぜか本社のクライアントからの問い合わせには応答しています。
> DNSサーバーと睨めっこしながら、DNSサーバーの怪しい所を
>調べていますが、これといった物が見つからない状態です (^^;;
たぶんルーティングとかNATの設定、またはVPNの設定がおかしい気がする
---------------------------------------------
| |
VPNな箱-------------------- |
| | 営業所
| DMZ
|
LAN
この状況だと勝手に推測します。
とりあえず動かすために
LAN内に、DNSを立ててみる
設定が面倒なので以下の設定でキャッシュだけにさせます
options{
forward only;
forwarders{
ご自分のDNS;
};
}
営業所にはこのDNSをみさせる
--------------------------------------------------------------
たぶん、VPNのターゲットが2個あって、1個のセッションが切れる
そいで、それがたまたま"DNSのあるエリア<->営業所"だったと推測しました
一応、推測ですが、試してみる価値はあると思いますが、やっぱり前回の
メールでセッションが維持されるので、その場しのぎなきがします。
|
この時、今まで疑っていなかったルーティングの部分に問題があると思った。
だが、ルーティングテーブルを見ても、何もおかしな所が見つからない。
タナカさんのお返事を読んで、「LAN内にDNSを立ててみる」を見て、
次のような事を思いついた。
| クライアントに指定しているDNSサーバーのIP |
|---|
 |
今まで、DNSとNATは同じマシンを使っていた。
クライアントに指定するDNSサーバーのIPは、プライベート側のIPを指定していた。
2000年にインターネット接続した際、知識がなかったため、通信業者から
割り当てられたDNSのIPを、クライアントに設定して使っていた。
これまで、全く問題が起こらなかったので、プライベート側のIPを指定していた。
|
今回は、タナカさんの「LAN内にDNSを立ててみる」を解決の糸口にして、
プライベート側のIPを、DNSサーバーのIPとして割り当ててみる事にした。
| クライアントに設定しているDNSサーバーのIPの変更 |
|---|
 |
これだと、ごまかしの設定だが、LAN内にDNSがある感じになる。
本格的にDNSを立てたくても、予備のサーバーがないため、
止む得なく、突貫工事でできる上の方法を使った。
|
そこで、自宅から名古屋・福岡営業所のパソコンの遠隔操作を行って、
営業所のパソコンのDNSの設定を変更した。
すると、DNS検索ができない問題がウソのように消えた。
だが、一時的にDNS検索ができているかもしれないので、すぐには喜ぶわけには
いかない。しばらく様子を見る事にした。
夕方になっても名古屋・福岡で、無事、DNS検索が行えているため
これで対処療法ができると思った。
クライアントのDNSサーバーの指定で、プライベート側のIPを割り当てれば、
DNS検索の問題が解消できる。
原因そのものは全く不明だが、対処療法でも効果があれば、使った方が
業務に支障が出なくなる。
DNSサーバーのログを採取する設定、DNSサーバーのIPアドレスの指定の変更。
そして、ネットワークを止めて、原因を追求する。
そのため、また、夜中作業になったのだが、あまり寝ていないので、
晩7時くらいに仮眠をとる事にした。
DNSのログを採取
仮眠をとったとはいえ、睡眠不足の累積は体に堪える。
体がフラフラだ。まずは、DNSのログを採取する設定を行うのだが、本を見ても・・・
よくわからへん (TT)
だった。
睡眠不足も手伝っているのか、頭も回っていない (--;;
google先生を使って、検索して、設定方法をわかりやすく書いているサイトを
見つけた。＠ITのホームページに書かれていた。
睡魔と闘い、設定がうまくいかず、気力がなくなり、床でウトウトする場面も
ありながらも、なんとか設定した。
| named.confの設定(ログをとる部分) |
|---|
logging {
channel "syslog_custom" {
syslog daemon;
severity info;
print-severity yes;
print-time no;
print-category yes;
};
channel "yaritori" {
file "/var/log/dns-log" versions 5 size 1 m;
severity info;
print-severity yes;
print-time yes;
print-category yes;
};
category "default" {
syslog_custom;
};
category "queries" {
yaritori;
};
};
|
|
見よう見まねで、作りました (^^;;
|
これでDNSのログが取れる。
しかし、ログをとってみるが、異常な物が見つからない。
ルーティングでも、どこが悪いのか、全く見当がつかない。
一度、DNSの応答のパケットが間違えた所へ飛んでいないか確認してみた。
| パケットが誤ってグローバル側に出ていないか確認 |
|---|
 |
しかし、応答パケットが出ている様子は全くなかった。
どうやらサーバー内部で迷子になっている可能性がある。
床でウトウトしながら、頭の中で考えるが、何も閃かず、時間のみが過ぎていった。
何も思いつかない。だが、業務に支障が出るのは良くないため、
とりあえずは、営業所のパソコンのDNSサーバーのIPアドレスの指定を変更した。
さすがに、徹夜の連チャンは、体に堪える。
午前5時半に会社を出るが、帰宅までの長い道のりが始まる。
阪急の最寄り駅に着く。電車まで10分あるので、暖房の効いた待合室へ行く。
激しい睡魔に教われ、気がつけば15分たっていた。乗るはずの電車に乗り損ねた。
仕方なく、ウトウトしながら、次の電車を待つ。
そして、無事、電車に乗れたら、今度は、終点についても、寝たまま。
なんとか起きて、神戸線に乗り換えた。幸い、寝過ごさずに、最寄駅で起きれた。
いつもなら1時間で帰れるのだが、1時間半もかかってしまった。
7時に家につき、朝飯も食べずに、力尽きてベッドに倒れ込む。
そして、午後1時半まで爆睡。
実は、この日はN社のFさん、H子さんがやってきて、本社のルーターの
最終設定を行う予定だったのだが、前日に、「今晩も徹夜なので、
明日は応対できる元気がありませんので、日を替えてください」とお願いした。
徹夜の連チャンだと、体がもたない・・ （＞＜）
DNSの検索ができなかった原因ですが、2005年1月24日時点でも全くわかりません。
調査に長期化しそうなため、ここでの結果報告はできませんでした。
原因がわかり次第、改訂版で追加したいと思います m(--)m
P-COMMのデータ転送の不具合も解消
徹夜の連チャンには、さすがに参った。
でも、ようやくDNS検索の問題が解消されたので、安堵感で一杯だった。
翌日、最後まで残った問題で、データ転送が遅い理由を調べる事にした。
しかし、Etherealでパケットキャプチャをしても見えない事がある。
そこで、tcpdumpを使ってAS400のパケットを分析しようと考えた。
| AS400のパケットを採取する方法 |
|---|
|
そこで、データ採取を行い、結果を見ていると、DNS検索を行っている
パケットの様子がある。
この時、データ転送が遅かった真相がわかった！！
P-COMMがデータ転送を行う際、DNS検索を行っているのだが、
DNS検索のためクライアントからパケットが飛んでも、サーバーから
応答が返らない場合、P-COMMは応答待ちのため、動かなくなる。
そして、数分した後、DNS検索の応答が返ってきた時に、ようやく
データ転送が始まるというわけだ。
案の定、営業所から「データ転送が遅い」という報告がなくなった。
データ転送が遅かった原因として、QoSや、パケットサイズなど、
色々な部分を見ていったが、全て外れだった。
相当、てこずった問題だっただけに、解決した時は拍子抜けだった (^^;;
本社ルーターの最終設定
12月15日、N社のFさん、H子さんがやってきた。
本社のルーターの最終的な設定変更のためだ。
回線接続を行う前は、ADSLが使えない危険性があった事から、
余分にトンネルを使って、Bフレッツになっても対応できるようにしていた。
その余分な設定を外すためだった。
そして、全て終わった。
翌日の12月16日。張りつめていた緊張感がなくなったのか、
溜っていた疲れがドッと押し寄せ、勤務中、あくびをしたり、睡魔に襲われたり
集中力が全然なかった。そのため、ダラダラと仕事を行っていた (^^;;
こうして1年以上にも渡るインターネットVPN導入大作戦は、死闘(?)の末、
なんとか終わった。
年間の通信費の削減額は、300万円を越える金額になった。
最後におまけ
大きな仕事を終えると、パッと騒ぎたくなる。
そこで、N社のFさん、H子さんに「打ち上げをしましょう」と言うと
H子さんはノリノリで「是非、やりましょう！」と言ってきた。
Fさんも「都合が合えば、行きます」と言ってくれた。
2005年1月21日、打ち上げが行われた。
Fさんは仕事の予定が入り参加できなかったので、H子さんと2人だけで
打ち上げを行う。場所は、私の行きつけのタイ料理屋（イサラ）だった。
http://www.thai-square.com/restaurant/shoukai/shokai_081.htm
店の大ママさんは、私が女の子を連れてデートだと誤解したらしく
私に「女性に親切にしなさいよ」とか「彼女に教えてあげてね」とか言われる。
気心しれた冗談の通じる女の子の友人なら、誤解されても問題はないのだが
今回は、取引先の女性なので、誤解からセクハラになる事も考えられる。
私がジャニーズ系のイケメンなら、デートと誤解されても問題ないだろうが
実際は、100%、女にモテない、三段腹で容姿も悪いオッサンなので、H子さんに
なんで、こんなオッサンとデートせにゃアカンねん！
と思われたら、完全にセクハラになる。セクハラと思われては、
以後の商談がやりづらくなるので、冷汗をかきそうになる (^^;;
店を出る時、大ママさんは、デートでない事が、わかったみたいだったのだが、
大ママさんは大きな一撃として次のように言った。
菅さん、今まで女性を連れて来た事がなかったのよ
これを聞いたH子さんは爆笑。でも、爆笑してくれて良かった。
「なんで、こんなオッサンと」と受け止められたら大変な事だからだ (^^;;
それにしても、大ママさんの一撃は「私が彼女イナイ歴31年である事」を
的確に表現している。
ここで彼女イナイ歴31年を解消すべく、膨大な編集時間が必要な
システム奮闘記をやめて、恋愛奮闘記を実践して、彼女ができた暁には
女の子と腕を組んでデートするという妄想を抱きたい所なのだ
まとめ
フレームリレー回線からインターネットVPNへの切り替え大作戦。
H子さんが電卓を叩いて「これは激安になります」から、1年がかりで
次々に立ちはだかる壁を越えながら、ようやく導入できました。
N社にルーターの設定を丸投げした時は、円滑に切り替わると思い、
回線を切り替えする前までの準備の話だけになりそうな感じだったのですが、
いざフタを開けると、障害発生の連続のため、話がどんどん大きくなりました。
全国行脚をしながら、障害に関する原因調査などに大幅に時間を割かれたため、
いつもなら同時進行で、いくつかのシステム奮闘記の原稿を書いているのだが
それすら、ままならず、全く更新できない事態にもなりました。
そのため、2ヶ月更新が止まっただけで「ネタ切れですか」と言われました (^^;;
さて、インターネットVPNを行う際の注意点を簡潔にまとめてみます。
| インターネットVPNを行う上での注意点 |
|---|
| (1) |
パスワードを定期的に変更できない場合は、IPSeC方式を採用する事。
|
| (2) |
DFビットを落とす設定を行う事
PMTUブラックホール問題が起こらないようにするため
|
| (3) |
ルーターのMRU値を1454以上にしておく事
1454未満だと、フレッツ網ではリンクが確立できない場合があるため
|
| (4) |
ADSLを採用する場合、伝送損失に注意。40dB上は不安定になる可能性あり。
|
この4点が重要なポイントだと思います。
最後になりましたが、出張先で、私のために宴会をしてくださったり
色々な所を案内してくださったりで、本当にありがとうございました m(--)m
人とのつながりは、ありがたいなぁと強く感じました。
次章:「C言語のポインタと構造体入門」を読む
前章:「Sambaでファイルサーバー構築」を読む
目次:Linux、オープンソースで「システム奮闘記」戻る