【SonicWALL障害メモ】 IKE Responder: IPSec proposal does not match (Phase 2)

朝、メーラーを起動してみると、SonicWALL の警告の山。

IKE Responder: IPSec proposal does not match (Phase 2) -  221.189.***.***, ***.****.ne.jp -  219.163.***.**** -  192.168.0.66/32 -> 192.168.0.0/24

IKE Responder: No match for proposed remote network address - 221.189.***.***, ***.****.ne.jp - 219.163.***.*** - 192.168.0.66/32←なに、これ？　大体、66なんてアドレスは無いし…

こんなのが1時間に何通も届く。　2ヶ月位前にも同様の現象で、同じ警告メッセージが一杯届いているので、なんとか解決したような気がするけど、思い出せない。　年には勝てないので、ちゃんとメモしよう。

参考サイト
Stange errors on TZ170 with unknown LAN subnet
RE: Problem: Site-to-Site VPN ISA2004 and Sonicwall


◇現象解消 --- 08/12/19追記
あっさり解消した。　ネットワークはSite-to-Siteで、

　　こっちのTZ180（小社）　⇔　あっちのTZ180（客先）

となってて、「こっちのTZ-180」から上記のエラーログが送られてきてたので、こっちに障害があると思い込んだのがそもそも大間違い。　ただ、「あっちの」は客先の奴なので、滅多にいじることも無いわけで、原因となるのは「こっちの」だろうと、例によって思い込んだ。

結論としては、犯人は Panda MOP。　12月初め位からPandaが「アップデートしたのでPC(サーバを含む)を再起動しろ」とメッセージを表示していたが、うちは兎も角、客先のサーバをそう簡単に再起動できるわけもなくしばし放置。結局、この Panda のアップデートがSonicのエラーメッセージの原因だった。　12月某日12時(昼休)、客先に出向き2台のサーバを再起動。　12：00以降、あの警告メールがピッタリとまった。

クッソォ～、おぼえてろよぉ～、　パンダぁ！　ヽ(｀Д´)ﾉ ウワァァァン


◇メモ見つかる --- 08/12/19追記
上に「2ヶ月位前にも同様の現象で」と書いたが、メモが見つかった。それも堂々とテスクトップに置いてあった。　以下、そのメモ。

VPNの設定/詳細設定がこちらとあちらで全く同じことを確認する

• 0.254と1.252のSAをOFFにし、エラー継続を確認（0.1と1.253と競合していないことを確認）
• 0.1と1.253で、SonicOS Standard 3.8.0.3-36s.jpn の一致を確認
• 0.1と1.253で、MTUの一致確認

ネットワーク＞ルーティング　の誤ったルート設定が原因か？　削除したらエラー解消の模様（08/9/17）

◇今回12月のエラーログ発生時のメモ-- 08/12/19追記
12/13、170/180の2台と客先の180×２台が通信するときに、上記のエラーログを多数受信（但し、客先2台からはこのエラーログを受信していない) 。　亀がNPTの設定を弄ったとうので、4台のNTP設定を一致させるが、現象解消せず。


◇さらに-- 08/12/19追記
上記の英語サイトにもあるように、このエラーはさまざまな要因で起こるようで、発生前後で何か特別な事象が発生していないか、冷静に思い出すことが重要。


（終）

拠点間VPNネットワークの構築 (2) --- 回線の冗長化

近年、インターネット回線やルータなどのネットワーク機器はかなり安定してきているようですが、回線かルータのいずれかが落ちると拠点間の通信は一切できなくなるので、冗長化する --- 回線とルータを複数用意する--- ことが重要です。　

【回線とルータの冗長化イメージ図】

上図のように、重要な拠点間の回線とルータは二重化または多重化しておきます。　回線は異なるキャリアのものを使用し、一つのキャリアの回線（例：NTT Bflets）が落ちても、生きている他のキャリア（KDDI）に切り替えて運用を継続します。　回線の切替は自動的に実行される（SonicWALLによる冗長化の例）が理想ですが、そのようなネットワーク構成は通常、高額になります。　よって、規模の大きくない拠点においては、障害発生時は手動によりTCP/IPプロパティのデフォルトゲートウェイを切り替えれば良いでしょう。　また、回線にかかる負荷を分散させるために、拠点にあるPCの何台かを1つの回線へ、残りのPCをもう一つの回線へと、通信をゲートウェイの指定により割り振るのも良いと思います。


デフォルト ゲートウェイの冗長化に関するメモ
TCP/IPプロパティのデフォルトゲートウェイに複数のルータのIPアドレスを指定して冗長化すれば、ルータの障害発生時に自動的にゲートウェイを切り替えてくれる筈だが、冗長設定を行うと、通信が不安定になる（断続的に切断される）ので要注意。


回線メモ
◇KDDI
インターネットゲートウェイ　
イーサシェア　光ファイバー、100Mベストエフォート型、￥184,800/月～（関東）　*1
Business-ADSL　下り最大12Mbps/上り最大1Mbps、ベストエフォート型、￥27,000/月～　*2

1. 田舎は使用できないところが多そう。
2. 微妙に（一部）NTTの電話網を使っているようで、NTTが落ちた場合、影響を受ける可能性有。

◇Usen
光ビジネスアクセス　　光ファイバー、100Mベストエフォート型、￥52,500/月～

• 田舎では使用できない。

拠点間VPNネットワークの構築 (1)

一昔前であれば、膨大な初期費用とランニングコストを要した拠点間の高速ネットワーク。　近年の光回線等のブロードバンドと、各種ネットワーク関連機器の普及と低価格化により、従来に比し非常に低価格で実現できるようになりました。 今回は最近、小社で手がけた小規模な支店間VPNネットワークの構築について紹介します。


要件定義（お客様、ご要望）

1. 4拠点間+α　VPNネットワーク構築
2. 回線冗長性（ルータや回線障害時に回線を切り替え、業務を継続できること）
3. 主なアプリはFileMaker Pro 5.5
4. Windows Server 2008 と Terminal Service を導入、支店でも社内LAN並みのパフォーマンスを出すこと
5. 堅牢なセキュリティ環境と集中監視・管理
6. システム管理者が拠点のネットワークを遠隔保守
7. 初期コストを最小化する
8. 社内システム管理者の負担を最小化
9. 拠点間の通信コスト限りなく０に、そしてスムーズな意思疎通

と、テンコ盛りの要件、しかも低予算...

1.　4拠点間+αのVPNネットワークを構築する

本社、工場、支店、土屋企画、出先ノートPC(緊急対応用)間のVPNネットワークを構築。 　このうち、本社、工場、土屋企画間はSite-to-Site VPN（SonicWALL TZ180同士で暗号化）、支店と出先ノートPCはVPNクライアントにGVP(SonicWALL Global VPN Client)を使用。

4.　回線冗長性

万が一の回線やルータ障害の時にも、工場で生産や配送の指図書や送状が照会・印刷できますように。　大分前ですけど、OCNが大規模回線障害で何時間も不通になってる、って、NHKの夜のニュースでやってもやってましたね。　はい、うちも被害者です。

3.　主なアプリはFileMaker Pro 5.5

少しはクライアント/サーバっぽいFileMaker 8.5とか9を使うと、クライアント⇔サーバ間のパフォーマンスもよくなると思うんですけどね…　　お客様の暗黙の（しかも強力な）要請により、既存のFileMaker Pro 5.5/FileMaker Pro Server 5.5によるシステムを継続利用。　既存システムのできる限りの延命も重要なミッションでございます。

4.　Windows Server 2008 と Terminal Service を導入

「2008でFileMaker Pro 5.5が動くん？」　---　Ans：はい、立派に動いてますね。　しかもTerminal Server 上で。　

「印刷は？　ローカルディスク利用は？」　--- Ans：お客さんの環境では、問題なく動作しておりますです。　

「で、Vistaは？」　---　Ans:動くかも…

5.　堅牢なセキュリティ環境と集中監視・管理

SonicWALL　と Panda で、統合的、集中的な管理。企業の社会的信用にかかわるセキュリティ関連リスクの低減に、万全を期しましょう。

6.　システム管理者が拠点のクライアントPCを含むデバイスを保守

遠隔地よりシステム管理者（≒小社）が、サーバ、クライアントPC、ルータ(SonicWALL)、プリンタ等を管理・保守できるようにしています。　請け賜っているのは SonicWALLの保守と各PCのセキュリティ管理だけなのですが、「これ、セキュリティの問題ではありませんね」って言えるまでの調査過程で、大体は原因が判明してしまうんですけどね。

7.　初期コストを最小化する

• Dell PowerEdge R300 (RAID 1)
• Windows　Server　2008　+　Terminal Service Client ラインセンス
• SonicWALL TotalSecure TZ-180 ×　4台
• Panda WebAdmin クライアントライセンス（追加ユーザ分）

合計60万位。　既成のハード/ソフトだけでこれだけはどうしてもかかってしまいます（クライアントPCやプリンタは既存のモノで新規導入無し）。　ホントに大変なのは、これらの機器やソフト、PC、プリンタを最適に設定して、テスト、テスト、そしてテスト。この部分は小社の営業努力で ･ﾟ･(ﾉД`)･ﾟ･

8. 社内システム管理者の負担を最小化する

経営者　　「システム、特にセキュリティなんかじゃ飯は食えんのよ」

小社　「ごもっともでございます（トホホ...）」

9.　拠点間の通信コストを抑える

IP電話より、Skypeとか、AOL IMの方が、使い勝手も、生産性が高いですね。

(続く)

SonicWALL を使った Site-to-Site VPN の構築

　VPN ルータ同士を接続して常時 VPN 接続を確立することを Site-to-Site VPN と言いますが、最近弊社では SonicWALL 同士の Site-to-Site VPN 接続の設定テストを行っています。

　VPN ルータが各終点に一つずつの場合は、比較的設定は容易です。
　基本的には VPN のポリシー設定で「主格 IPSec ゲートウェイ名またはアドレス」に対岸のルータアドレス（ゲートウェイアドレス）を入力し、「事前共有鍵」に任意の共有鍵コード（両方のルータに同じ共有鍵を設定）を指定し、そして「対象先のネットワーク」に対岸 LAN のネットワーク（たとえば 192.168.3.0）とサブネットマスクを指定するだけです。

　しかし、ネットワークが落ちたりすると業務に支障が出るような環境では、回線を複数用意しているところもあります。そのようなときに、現用回線と予備回線の両方に対して VPN トンネルを張っておき、現用回線がダウンしたときに予備回線の VPN トンネルを使うことがあります。これを冗長 VPN ゲートウェイと呼んでいるそうですが、この設定は、理屈では「主格 IPSec ゲートウェイ名またはアドレス」に現用回線のルータアドレス、「副格 IPSec ゲートウェイ名またはアドレス」に予備回線のルータアドレスを指定すれば動くということになっているのですが、何故か副格ゲートウェイの方だけが採用されている状態となりました。主格の方が無視されている状態なので、現在この原因について調査中です。