14-01
14-01
１０月になると、朝夕は気温が涼しさを通り越して、少し寒いと感じる日があるようになった。日中はまだ気温が夏日になることもあるのだが、それは日の高い少しの時間帯だけで、仕事から早く帰ってきて近所のスーパーに買い物に行く頃には、もうすっかり涼しくなってしまっている。パーカーワンピース一枚でもまだ大丈夫だが、足元がビーチサンダルだと、足の指先が少し寒いと感じるようになってきた。休みの日の昼間、天気も良いし、気温も夏日だからと、喜んでビーチサンダルを履いて散歩に出ると、街中を歩く人に素足を晒している人はもう誰もいない。そんな都も、７分丈のパンツに、長袖の上着を羽織っていたりするのだから。
１０月に入ってすぐ、ＣＪ案件のヒアリングシートは回答が来た。ほぼ完璧に埋まっていて、細かいところを数点確認するだけで済んだ。優先制御のためのＴＯＳビットマーキング用のためのアクセスリストも、綺麗に埋まっていた。
都たちのＭＰＬＳサービスを利用するお客の中には、新規、継続のお客にかかわらず、優先制御対象のパケットをどう指定して良いのかわからなくて、問い合わせが多くなることが少なくない。プロトコルを指定した通信の送信元、宛先について、ＩＰアドレスをホスト単位かワイルドカードマスクで範囲指定、単一のポート番号かポート番号の範囲を指定すれば良い旨説明するのだが、そもそも対象のアプリケーションのパケットのそれらがわからない、というお客もいる。その場合は、お客自身で調べてもらうしかないのだが、調べることなく都たちへどう指定すれば良いのかと問い合わせが上がってくる。どのＩＰのホストからどのＩＰのホストへの通信なのか、そのホスト間の通信はそれだけなのかなどを、一つ一つヒアリングしていくしかない。大抵はその通信に限らない、とか、特定のＩＰ間の通信ではない、と返されるので、そうなるとそのアプリの使用ポート番号で絞るしかないから、調べて回答するよう案内するのだが、これについても調べもせずにわからない、と言われてしまう場合がある。それはＩＴ担当者のスキルが低い、特にネットワークについてのスキルが低いだけの場合もあるが、日本人特有の、なんでも売った方がやるべきだという、おかしな商文化によると考えられる事例も少なくない。
かと言って、お客の責任区分範囲だからとただ突き放すだけでは、さらにお客の態度を硬化させるだけだ。都たちの責任区分範囲、特にトラブルの多い海外の回線手配で何かトラブルがあったり、回避不可能な大幅なスケジュール遅れが起きたりした場合のクッションを作る意味でも、多少なりともこれらの問い合わせには対応しなければならない。こういった、何もわからないと言ってくるお客の多くは、一般に販売されている、もしくは出回っているソフトウェアやハードウェアの通信について優先制御を掛けたいという要望を持っていることが多い。そこで、都たちで優先制御の対象としたい通信はどんなアプリ、どんなハードウェアだと聞いてみることになる。流石にこの情報は簡単に出てくるので、それを普通にインターネットの検索エンジンで調べて、メーカーサイトの仕様書や、説明書などをダウンロードし、ネットワーク通信の項目を調べると、使用するポートなどの情報があるものもあって、それが見つかれば、きちんとお客で正常性は確認はするようにという但し書きをつけて、案内する。もっとも見つからない場合もあって、その場合はメーカーの問い合わせ先をメーカーサイトから探し、そこへ購入したお客自身で問い合わせるようにと促すしかない。
ＣＪ案件は、お客自身もある程度ネットワークについて知見がありそうだったし、ましてＬＡＮベンダーがついているのだから、この辺りは問題がなくて良かった。
ＰＢＲについても、打ち合わせ時に案内した通りに記入されており、都が設計を考えるにあたって不足する情報はなかった。結局、バックアップパスの監視対象ＩＰはグローバルアドレスになっているので、都が提案したバーチャルトンネルインターフェイスを使う、ルートベースのＩＰＳｅｃ方式への設計変更はしないようだ。後々の拡張性を考えると、このマイグレーションのタイミングでやっておくほうがインパクトは少ないと思うのだが、拡張の予定もないということかもしれない。あるいは、バーチャルトンネルインターフェイスへの設計変更の見積もりに、お客が肯んじなかったのか。それとも、このバックアップのインターネットＶＰＮも、インターネットをアクセスラインとして、ＩＰＳｅｃで都たちのＭＰＬＳのプロバイダエッジと接続し、同じ網へ接続するバックアップ回線としてマイグレーションする計画があるのだろうか。確か、営業はこれも売ろうとしたが、こちらは失注したと、最初の説明で下山から聞いた気がする。
何れにせよ、バーチャルトンネルインターフェイス方式にしないのであれば、都の事前検証も、ポリシーベースのＩＰＳｅｃでバックアップ側の環境を作らないといけない。稀にこれをＬＡＮ側に実装していたり、ＳＩ構築のインターネットＶＰＮが、ＭＰＬＳを終端しているルーターに相乗りしていたりすることがあって、そういうルーターでのトラブルシューティングに呼ばれ、コンフィグを見たり、状態を確認したりしたことはあるが、商用環境で一から作った経験が都にはなかった。検証でも随分前に動作確認のために軽くやったことがある程度で、上手く動いたか動かなかったかの記憶もない。そのため、まずはこのポリシーベースＩＰＳｅｃの検証を、ＣＪ案件のＰＢＲ検証の前にやっておかないといけない。そうしておかないと、ＰＢＲの検証環境を組んでから、実際テストを始めてみて、バックアップ側の通信が全く出来なかった時、どこでトラブルになっているのか切り分けがややこしくなる。検証の通信テストが上手く行かない時、その切り分けが難しくなるのは、何のための検証だかわからなくなるので、コンフィグの仕方が怪しい所は、先にそこだけ抜き出して、事前に試しておく必要がある。
都は、ノートを袖机から引っ張り出して、まずはこのポリシーベースのＩＰＳｅｃを試すための、ネットワーク図を描き始めた。インターネットを表すのはルーター１台で良い。そのルーターを挟むように、２拠点のベンダーのＩＰＳｅｃルーターを置く。ＬＡＮ側はどうしようか。ＩＰＳｅｃルーターのループバックインターフェイスでＬＡＮの代わりにするのもありだ。バーチャル環境でルーターを動かせるシミュレーターソフトウェアを動かすためには、ＰＣのマシンパワーが結構必要になる。そのため、通常端末のマシンパワーでは、ルーターを減らして検証しなければならない時があり、その際に良く使う手だ。しかし、このポリシーベースのＩＰＳｅｃを試すためだけであれば、ＬＡＮを表すルーターを両端に置いても、ルーターは５台で済む。ノートに５台のルーターを表す円を並べて書いて、それぞれを接続するリンクを表す線の上にＩＰアドレスをアサインしていく。簡単な図を書き終えたら、通常端末にインストールしてある、シミュレーターソフトウェアを起ち上げて、ソフトウェアのパレットの上に、ルーターを直列で５つ並べて、各ルーター間をリンクで接続する。
ルーターを起動する前に、都はブラウザを開いて、ポリシーベースのＩＰＳｅｃのコンフィグ例を解説した、メーカーサイトのページを検索する。都は、バーチャルトンネルインターフェイスを使用する、ルートベースのＩＰＳｅｃであれば、空でコンフィグすることができるが、ポリシーベースは、ＩＰＳｅｃにカプセリングしたい対象のトラフィックを指定して、そのパケットのみＩＰＳｅｃに包み、ＩＰＳｅｃトンネルの対向へ転送する、という大枠の仕組みだけを何となく覚えているだけだ。そのため、メーカーサイトのコンフィグ例を参照しながらコンフィグしないといけない。シミュレーターソフトウェアを都たちが貸与されている通常端末で動かすと、５台程度のルーターを動かすだけでも、すぐにＰＣの動作が重くなってしまう。シミュレーターを動かしてから、別の作業をしようとして、ブラウザを開いたり、メーラーを開いたり、あるいはスプレッドシートを開いたりすると、非常に動作が遅く、場合によっては動かない時すらある。そのため、メーカーサイトはルーターを動かす前にブラウザで開いておく必要があった。
メーカーサイトのコンフィグ例を解説したページを開いて、シミュレーターのルーターを１台ずつ起動していく。パレットの上のルーターを全部一度に起動させるボタンもあるのだが、都たちの通常端末で複数ルーターを起動させるのにこれを使うと、軟弱なマシンパワーのため、１台かあるいは数台、起動に失敗するものが出てきてしまう。この事象に当たると、一度シミュレーターソフトウェアをシャットダウンし再起動しないといけなくなるので、１台ずつ起動させる方が結果的に効率が良い。業務で使うメーラーや、スプレッドシート、プレゼンテーション用ソフト、ブラウザ、それらを動かすのにも緩慢な通常端末の性能問題は、時折正社員派遣社員問わず話題になっていて、どうにかもう少し現在業務で使うアプリケーションを円滑に動かすに足るスペックのＰＣに更改して欲しい所なのは、業務に従事する人間の総意だが、予算だ何だと言って全く進まない。その事によって業務が効率化され、無駄なレスポンス待ち時間も減り、ひいては残業時間の削減にもつながるというのに。だいたい、現在通常端末上で動いているＯＳの、一つ前のバージョンがもともと動いていたハードウェアだ。現在のＯＳだって、もう最新のものからは２世代ほど古い。もっとも、通常端末で走っているバージョンは安定していて、最新のものは、安定性や、デザインの根本的な変更から嫌われることは多い。
都が、このポリシーベースＩＰＳｅｃの事前検証をやろうと思ったのは、午後に入ってから結構すぐだったはずだが、いろいろな問い合わせや、トラブル相談などの対応をしているうちに、結局定時が過ぎ、今は２０時を回っていた。２１時までには終わるだろう、と踏んで今日中にやりきってしまうことにした。そうは言ってもとりあえず、都は上の階の自販機へコーヒーを買いに行ってくることにした。
都がいるオフィスの部屋には、出入り口となる扉は２箇所にある。結構広い部屋であることと、柱の多い構造のせいで、オフィスの内側では片方の扉付近から、もう一方の扉付近はよく見えない。都が廊下に出ると、自分が出た重たい鉄の扉が閉まる音がした後、もう一方の側も閉まった音がした。誰かが残業を終えて帰るのだろうと思っていたら、バタバタとハイヒールで駆けてくる音が反響とともに聞こえてくる。
「間宮さーん。」
その通る声は人影のない、電気も間引きで暗い廊下にうるさいくらい良く響いた。岸谷は走って都に追いつくと、間に合った、と興奮した様子で言うので、都は笑ってしまった。岸谷は、ちょうどやっていた工事がお客試験の待機に入ったので、ちょっと休憩しようと思ったら、都が立ち上がったのが見えたので、コーヒーだろうから一緒しようと思い、走ってきたと言う。そういえば、都が廊下へ出る時に誰かがオフィス内を走る音がしたが、あれは岸谷だったんだ。そう今更気がついた旨、エレベーターを二人で待ちながら言うと、岸谷は、気がつかないなんてひどいです、とふざけて不満げに言うので、都はまた笑ってしまった。
都が派遣社員として働くようになってから１０年くらい経つ。４年程度の事務職を経て、ネットワークエンジニアになり６年が過ぎたが、これだけ都を慕ってくれる後輩に出会ったのは初めてだった。岸谷は正社員で、都は派遣社員だから、後輩、と言うのは正しくはないのかもしれない。笑顔で嬉しそうな顔をして都に寄ってきてくれるのは、純粋に嬉しかったし、その仕草ひとつひとつが可愛らしい。グローバルで活躍できる立派なビジネスパーソンに、岸谷が成長すると良いな。都は素直に思った。