Top > ネットワーク

2007年10月21日

会社でファイル共有ソフトはバレますよ

P2P型ファイル共有ソフトが原因で社内ネットワークが停滞した事例の紹介です。

長野に本社兼工場があって、東京・大阪・福岡に営業所があるお客さんです。営業所から本社へスター状にインターネットVPNを構築していて、インターネットにはすべてフレッツ等のFTTHで接続しています。

ネットワーク構成 概要

夕方担当の方から電話がありました。今日の昼ぐらいからインターネット接続が極端に遅くなったそうです。営業所から、本社のLANディスクへのアクセスもできない状況とのこと。
本社から同じセグメントのLANディスクには、問題なくアクセスできるそうです。

インターネットへのWeb、メールともに駄目なことから、プロバイダーもしくは、ルータの障害ではないかと、担当の方は話してました。
クライアントPCからルータまでのpingをしてもらったところ、最初の一発目はtime outになったそうですが、2発目からは、返答があるとのこと。
ルータのsyslogをwebブラウザーから見てもらいましたが、syslogを見る画面までたどり着けずにタイムアウトとなってしまいました。
ルータのスローダウンかな?という気がしたので、ルータの電源をOFF/ONしてもらいました。

ルータ起動後、5分程度は、まともに使えていたのですが、その後またまた、インターネットへの接続が極端に遅くなってしまうとのこと。
ルータの再起動を何度かしてみましたが、改善されないようなので、翌日代替えのルータを持ってお伺いすることに。

翌日、朝からの状況を聞いてみましたが、やはり今日も駄目だそうです。
片道2時間のドライブで、お昼に到着。早々ルータの設置してある会議室に。ルータに接続されている親L2スイッチを見て、おかしいなぁと思いました。ルータとA部署のポートのアクティブインジケータが止まることなくチカチカしてました。もちろんルータのLAN・WANともにインジケータがチカチカと。
A部署のどなたかが、ウィルス(あるいはそのたぐい)に感染したか、どでかいファイルのダウンロードをしてるか、ファイル共有の3択です。
このユーザさんは、IPアドレスをすべて固定で割り当てているので、IPアドレスを特定すれば、クライアントも限定できます。
早速ルータと親L2スイッチの間にリピータHubをかまして、持参のノートPCで、パケットキャプチャしました。

Wiresharkのサマリー画面

パケットキャプチャリングソフトは、フリーで定番のWireshark(Ethereal)です。
うわ~、IPアドレス192.168.1.129のパケットだらけです。相手先は20箇所くらい。tcpソースポートとディスティネーションポートともに、ウェルノンポートではないから疑わしきは、ファイル共有ソフトです。
つらつら見ると上位層のプロトコルを判定してくれてます。「Gnutella」だそうで。検索サイトにお伺いをかけたところ、Wikipedia様が1位にヒット。P2P型ファイル共有ソフトだそうです。恥ずかしながら、Gnutellaは、この時初めて知りました。

さて、原因がわかったら、次に探すは、使用者です。IPアドレス割り当て表から、すぐにお名前判明。クライアントPCは、個人持込のmacでした。この使用者さんは厳重注意となりました。公務員だったら減給もんです。

わたし的には、どんなもんをP2Pしてたのかが一番興味のあるところだったんですが、そこは追求しないで終わってしまいました。

 

IT工房にんにく庵関連ページ

 

トラブル対応

2007年11月05日

送信ドメイン認証(Sender ID/SPF)の設定

送信ドメイン認証をオンにしたときの画面

今月1日(2007/11/1) NTT DoCoMoのiモード メールシステムが、迷惑メール対策の一つとして「送信ドメイン認証(Sender ID/SPF)」サービスを無料で開始しました。初期設定では、「拒否しない」設定になっていますが、インターネットメールからの迷惑メール対策には、効果的ですので、「すべて拒否する」に設定するかたが増えてくるのではないでしょうか。

現段階では、送信ドメイン認証は、迷惑メールではない一般のメールも拒否してしまう可能性があるため、実施しているインターネット・サービス・プロバイダ(ISP)は、まだまだ少ないのが現状です。

DoCoMoが開始したことで、送信ドメイン認証に対応するISPも増えてくるのではないでしょうか。

送信ドメイン認証で拒否されてしまうメールは、なにもプロバイダからのメールだけとは限りません。企業などの独自ドメインで運用してるレンタルサーバや、IT工房にんにく庵のような自営メールサーバなども、送信ドメイン認証に対応しておかないと、DoCoMo宛のメールが届かないということになりかねません。

プロバイダやレンタルサーバの独自ドメインではないメールシステムは、きちんとしたところであれば、すでに対応済みでしょうし、今回DoCoMoがサービスを開始したことで、対応を始めることと思います。

問題なのは、我々のような自営でメールサーバを構築していたり、独自ドメインでレンタルサーバ上にメールサーバを構築してるところです。
DNSサーバを自営していれば、DNSのレコードをちゃっちゃと追加してあげれば済みます。
DNSサーバを自営せず、"ドメイン取得したところで提供しているDNSサーバ"を使用している場合、自分でDNSサーバにレコードを追加するなり、追加の依頼をしなければなりません。

 

送信ドメイン認証(Sender ID/SPF)に対応しているかどうかの確認

まず、自分のメールアドレス(ドメイン)が、送信ドメイン認証に対応してるかどうかを確認してみます。

インターネットに接続されているWindowsパソコンのコマンドプロンプトから確認できます。

コマンドプロンプトを立ち上げます。赤字がキーインした例で、青字が説明です。

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

c:\>nslookup
Default Server: router
Address: 192.168.x.x

>set type=TXTレコードタイプをTXTにします
>nin29.comドメイン名nin29.comのレコードを問い合わせした例
Server: router
Address: 192.168.x.x

Non-authoritative answer:
nin29.com text =

"v=spf1 +ip4:202.224.39.0/24 ~all"
>asahi-net.or.jpドメイン名asahi-net.or.jpのレコードを問い合わせした例
Server: router
Address: 192.168.x.x

Non-authoritative answer:
asahi-net.or.jp text =

"v=spf1 include:spf-01.asahi-net.or.jp ?all"
>fc.lolipop.jpドメイン名fc.lolipop.jpのレコードを問い合わせした例
Server: router
Address: 192.168.x.x

lolipop.jp
primary name server = sv.madame.jp
responsible mail addr = admin.madame.jp
serial = 2001373123
refresh = 60 (1 min)
retry = 3600 (1 hour)
expire = 1209600 (14 days)
default TTL = 86400 (1 day)
>exit

c:\>

ここで、text=に続く "v=spf1 ・・・・・・・・"があれば、送信ドメイン認証の設定がDNSサーバにされていることになります。nin29.comやasahi-net.or.jpなどは、送信ドメイン認証の設定がされているのがわかります。ロリポップのメールサーバfc.lolipop.jpは、送信ドメイン認証の設定がされていませんでした。(サポートのお知らせにも、現在未設定との記述がありました。)
自分のメールのドメイン名がわからない人は、メールアドレスの@以降の部分です。

送信ドメイン認証(Sender ID/SPF)のためのDNSレコード設定例

では、DNSレコードの追加は、どうすればいいのでしょうか?
IT工房にんにく庵の場合を例に、説明します。同じような状況のかたの参考になれば幸いです。

IT工房にんにく庵のネットワーク構成図

IT工房にんにく庵のネットワーク構成を簡単に図解します。
にんにく庵のパソコンからにんにく庵の自営サーバへメールを送信すると、プロバイダAsahi-netのメールサーバに転送(リレー)されます。(1と2)
Asahi-netのメールサーバから宛先に応じて、メールが送信されます。(3)docomo.ne.jpドメイン宛のメールであれば、DoCoMoのメールゲートウェイ経由でDoCoMoのメールサーバへ届き、携帯電話に送られます。

DoCoMoの送信ドメイン認証は、多分メールゲートウェイでチェックしてるでしょうから、Asahi-netのメールサーバから送られてきたxxx@nin29.comのメールをメールゲートウェイで送信ドメイン認証します。送信ドメイン認証するにはDoCoMoのDNSサーバに、nin29.comドメインのTXTレコードを教えてもらい、その内容を確認します。nin29.comドメインのTXTレコーに、Asahi-netのメールサーバのIPアドレスが記述されていれば、送信ドメイン認証はパスします。もちろんDoCoMo宛てメールのアドレスの人が送信ドメイン認証をオン(すべて拒否)にしている場合の話しです。

IT工房にんにく庵のドメインは、レジストラが「livedoorドメイン」です。DNSサーバもlivedoorドメインのものを使用しています。ドメイン取得当時は、例の事件前でしたし、ドメインのレジストリ料金が安かったこともありここにしてました。レコードの登録数が最大15レコードで、MXレコードにも対応していたので、サービス的には問題ありませんでした。

まず、手持ちのDoCoMo FOMA携帯で「他のアドレスになりすましたメールはすべて拒否する」に設定しておき、nin29.comからメールを送りつけます。しばらくすると、エラーメールが返ってきました。

Date: Sat, 3 Nov 2007 10:57:44 +0900 (JST)
From: MAILER-DAEMON@mxdigger3.asahi-net.or.jp (Mail Delivery System)
To: xxx@nin29.com
Subject: Undelivered Mail Returned to Sender

This is the Postfix program at host mxdigger3.asahi-net.or.jp.

I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the message returned below.

The Postfix program

<xxx@docomo.ne.jp>: host mfsmax.docomo.ne.jp[203.138.181.112] said:
550 Unknown user xxx@docomo.ne.jp (in reply to end of DATA
command)

拒否設定すると、「Unknown user」で蹴られます。

livedoorドメインのドメイン名管理(アカウントマネージャー)画面

livedoorドメインのドメイン名管理(アカウントマネージャー)画面から、nin29.comにTXTレコードを追加します。
VALUE部分に、v=spf1 +ip4:202.224.39.0/24 ~all を記述します。 ネットワークアドレスは、Asahi-netのメールサーバのネットワークアドレスにします。にんにく庵のメールサーバはOBP25(Outbound Port Block 25)対策として、Asahi-netのメールサーバをリレーさせているので、202.224.39.0/24を指定します。自営メールサーバから直接相手メールサーバへ送信している場合、ルータに割り当てられているグローバルIPアドレスを設定します。

ちなみに、Asahi-netのメールサーバ用ドメインに設定されているTXTレコード、v=spf1 include:spf-01.asahi-net.or.jp ?all をそのままパクってもうまくいくのでは?この方が、メールサーバのIPアドレスが大幅に変わったときでも、気にしなくていいのではないかと・・・。
ということで、やってみました。予想通り、この設定でもうまくいきました。(^^)

そうそう、にんにく庵のようにプロバイダーのメールサーバをリレーしている場合、プロバイダーのメールサーバのIPアドレスを知る方法ですが、プロバイダー以外で持っているメールアドレス宛にメールを送って、そのメールのヘッダ情報を見ます。
Received: ヘッダが数個あると思いますので、その一番上の文章に注目します。大抵そこにはどこのサーバからメールが来たかが記述されてますので、それを信じれば、大抵ビンゴです。

Received: from 202.224.39.197 (EHLO mail.asahi-net.or.jp) (202.224.39.197)
by mta313.mail.ogk.yahoo.co.jp with SMTP; Sat, 03 Nov 2007 11:55:34 +0900

 

2008年01月03日

拠点間インターネットVPN構築

インターネットVPNネットワーク構成図 I-O DATA社のVPNルータETX-VRTを使った拠点間インターネットVPN構築事例です。EXT-VRTは、インターネットVPN対応のブロードバンドルータです。1台で2点間のVPN接続とインターネット接続をシームレスに実現します。3万円弱で、2台同梱されています。通常のVPNルータですと、1台で3万円はしますので、大変コストパフォーマンスは、高いです。VPNの暗号化は、ハードウェアIPSecです。複数拠点間接続には対応していませんので、1対1のVPNとなります。

導入したお客さんの要望は、工場から本社のサーバ(経理販売システム)にアクセスできることと、本社LANディスクの読み書きでした。
本社にBフレッツ、工場にYahoo!BBのリーチDSLを使用しました。本社側は、ISDNで構築していたビジネスフォンをひかり電話オフィスタイプに変更して、電話料金の削減を実施しました。

ブロードバンドルータに割り当てられるグローバルIPアドレスは、動的割り当てですので、無料のiobb.netダイナミックDNSサービスを使用します。(ETX-VRTは、iobb.net以外のダイナミックDNSサービスには対応していません)

導入後の稼働状況ですが、Yahoo!BBリーチDSLのリンク切れが、結構な頻度で起こり、iobb.netへのDNS更新が頻繁に発生しました。それが災いしてなのか、ダイナミックDNSの更新がうまくいかないことがありました。
こうなると、通常のインターネット接続は問題ないのに、VPNだけがつながらないというトラブルとなってしまいます。この状態で、インターネットから、工場のDNS名に対してpingすると、応答が無くなります。pingの応答があるのに、VPNが接続できないこともありました。

一例ですが、VPN正常接続時と、VPN接続不可時のログを掲載します。

工場ルータVPNログ【正常接続時】

[==== IKE PHASE 1(to 221.184.138.73) START (initiator) ====]
**** SENT OUT FIRST MESSAGE OF MAIN MODE ****
PAYLOADS: SA,PROP,TRANS
**** RECEIVED IKE NOTIFY PAYLOAD(NO_PROPOSAL_CHOSEN) ****
[==== IKE PHASE 1(to 221.184.138.73) START (initiator) ====]
**** SENT OUT FIRST MESSAGE OF MAIN MODE ****
PAYLOADS: SA,PROP,TRANS
**** RECEIVED IKE NOTIFY PAYLOAD(NO_PROPOSAL_CHOSEN) ****
[==== IKE PHASE 1(to 221.184.138.73) START (initiator) ====]
**** SENT OUT FIRST MESSAGE OF MAIN MODE ****
PAYLOADS: SA,PROP,TRANS
**** RECEIVED IKE NOTIFY PAYLOAD(NO_PROPOSAL_CHOSEN) ****
[==== IKE PHASE 1(to 221.184.138.73) START (initiator) ====]
**** SENT OUT FIRST MESSAGE OF MAIN MODE ****
PAYLOADS: SA,PROP,TRANS
**** RECEIVED SECOND MESSAGE OF MAIN MODE ****
PAYLOADS: SA,PROP,TRANS
**** SENT OUT THIRD MESSAGE OF MAIN MODE ****
PAYLOADS: KE,NONCE
**** RECEIVED FOURTH MESSAGE OF MAIN MODE ****
PAYLOADS: KE,NONCE
Type = ID_IPV4_ADDR,ID Data=219.46.154.35
**** SENT OUT FIFTH MESSAGE OF MAIN MODE ****
**** RECEIVED SIXTH MESSAGE OF MAIN MODE ****
PAYLOADS: ID,HASH
**** MAIN MODE COMPLETED ****
[==== IKE PHASE 1 ESTABLISHED====]
***** このあと、pahase2~6と続きます *****

工場ルータVPNログ【接続不可時】

[==== IKE PHASE 1(to 221.184.138.73) START (initiator) ====]
**** SENT OUT FIRST MESSAGE OF MAIN MODE ****
PAYLOADS: SA,PROP,TRANS
**** RECEIVED IKE NOTIFY PAYLOAD(NO_PROPOSAL_CHOSEN) ****
***** pahse1を繰り返します *****

本社ルータVPNログ【正常接続時】

[==== IKE PHASE 1(from 219.46.154.35) START (responder) ====]
**** RECEIVED FIRST MESSAGE OF MAIN MODE ****
PAYLOADS: SA,PROP,TRANS
PAYLOADS: SA,PROP,TRANS
**** SENT OUT SECOND MESSAGE OF MAIN MODE ****
**** RECEIVED THIRD MESSAGE OF MAIN MODE ****
PAYLOADS: KE,NONCE
**** SENT OUT FOURTH MESSAGE OF MAIN MODE ****
**** RECEIVED FIFTH MESSAGE OF MAIN MODE ****
PAYLOADS: ID,HASH
Type = ID_IPV4_ADDR,ID Data=221.184.138.73
**** SENT OUT SIXTH MESSAGE OF MAIN MODE ****
**** MAIN MODE COMPLETED ****
[==== IKE PHASE 1 ESTABLISHED====]
***** このあと、pahase2~6と続きます *****

本社ルータVPNログ【接続不可時】

[==== IKE PHASE 1(from 219.46.154.35) START (responder) ====]
**** RECEIVED FIRST MESSAGE OF MAIN MODE ****
PAYLOADS: SA,PROP,TRANS
ERROR# NO MATCHING ISAKMP PROPOSAL FOR DIALUP CASE
SENDING NOTIFY MSG:NO_PROPOSAL_CHOSEN
**** SENT OUT INFORMATIONAL EXCHANGE MESSAGE(NOTIFY_PAYLOAD) ****
***** pahse1を繰り返します *****

工場がinitiatorで本社がresponderですので、工場から本社へVPN接続を張りにいっています。
接続不可時のログを見ると、工場ルータから本社ルータに対してISAKMPにてIKEの鍵交換方式と鍵交換の暗号・認証方式をネゴシエーションしようとしたが、ネゴシエーションができなかったというようなことが書かれています。
このようなとき、どちらかのルータを再起動することで、回復するケースがほとんどでした。

 

IT工房にんにく庵関連ページ

 

インターネットVPN構築

2008年02月09日

フルーツネットに接続できません

山梨CTAVが提供しているケーブルテレビ共用型のインターネット接続サービスがフルーツネットです。山梨県山梨市を営業エリアにしています。山梨県は、電波状況が悪くCATVの普及率が高いそうです。また、ADSLは、局舎までの距離が遠いため、使えないかたもかなりいらっしゃいます。FTTH(光)サービスは、まだまだ先です。かといってISDNじゃ最近のホームページは重くてイライラしてしまうような状況です。CATVのインターネット接続サービスは、地方にあって貴重なブロードバンド選択肢です。

WZR-AMPG300NH

WZR-AMPG300NH

お伺いしたお客さんは、フルーツネットのCATV共用型から、FTTHサービス(フルーツネットひかり)に乗り換えたそうです。古い無線LANアクセスポイント一体型ルータから、無線LAN Draft11n対応のルータ(バッファローWZR-AMPG300NH)を購入し、マニュアル通り設定したのですが、ネットに接続できないそうです。フルーツネットのサポートに電話対応してもらったそうですが、解決しないとのこと。

お伺いして聞いてみたところ、IPアドレスのpingまではOKで、FQDNでのpingが駄目だそうです。IPアドレスでのhttp接続も問題ありません。

ルータのステータスを確認したところ、WAN側は、プライベートIPアドレスやDNSサーバを自動取得できていました。

ルータ内蔵のping機能を使用したところ、やはりFQDN名でのpingがエラーになりました。LAN側に接続したパソコンからnslookupコマンドで名前解決すると、タイムアウトになってしまいます。

DNSサーバの障害?と思いましたが、1stDNS(IPアドレス172.30.10.1)と2ndDNS(IPアドレス210.134.92.20)ともに名前解決できませんでした。

古いルータを使うと、全く問題ありません。WZR-AMPG300NHのWAN側でDNSパケットを遮断しているのでないかと推測しました。出て行くパケットか戻ってきたパケットのどちらかが遮断されている可能性があります。

当日、ONUとルータ間のパケットをキャプチャする道具を持ってきていなかったため、この日は退散となりました。

バッファローのサポートにWebから質問してみましたが、「CATVでの確認はとれていて、個別のCATV会社まではサポートできない。」とのことでした。ま、予想通りの回答です。

後日あらためてお伺いし、原因追及しました。

結果的にONUとWZR-AMPG300NH間のネゴシエーションが1000BASE-Tで接続されるとDNSパケットがロスするようです。1000BASE-TのパケットをキャプチャするインテリジェントL2スイッチを持ち合わせていないため、パケットが出てるのかどうかまで確認できませんでした。

パケット解析構成

パケットをキャプチャするために、100BASE-TXタイプのインテリジェントL2スイッチをONUとWZR-AMPG300NHの間にかますと。正常に通信できます。

そこで、ONUとWZR-AMPG300NHの間にノンインテリジェントタイプのL2スイッチ(3,000円程度)をはさんで、強制的にスピードを100Mbpsにしました。

代替え構成

DNSパケットは、レイヤー4です(UDPパケット)。それが、レイヤー2で影響を受けるというのは、何とも不可解な障害でした。

 

IT工房にんにく庵関連ページ

 

パソコンのトラブル、修理、故障などハード・ソフトとも対応しています

検索


Feed

Really Simple Syndication 2.0 The Atom Syndication Format Really Simple Discoverability