カテゴリー別アーカイブ: RTX-1200

IPv6 PPPoE で問題発生

突然IPv6でアクセスできなくなった。

ルータ(RTX-1200)を確認したところPPPが確立していない。

RTX-1200のログはこんな感じ

RTX-1200ログ
2014/05/31 21:11:54: PPPOE[02] Connecting to PPPoE server
2014/05/31 21:11:54: PPPOE[02] PPPoE Connect
2014/05/31 21:12:24: PP[02] Give up establishing PPP/IPCP in REQSENT
2014/05/31 21:12:24: PP[02] Give up establishing PPP/IPV6CP in ACKSENT
2014/05/31 21:12:30: PPPOE[02] Disconnecting, cause [PPP: IPCP Timeout]
2014/05/31 21:12:30: PPPOE[02] Disconnected, cause [PPP: IPCP Timeout]

プロバイダはぷららさんなので、問い合わせをしたがなにぶん土曜の夜で早期の回答は望めません。

以前はユーザーの部屋というBBSが有ったのですが、いまはこちら

http://okbizcs.okwave.jp/nttplala/questiondetail/?qid=8618514

早速投稿してみました。

翌朝も同様な状態。

RTX-1200はそのほかにも2セッション張っているので下手に弄るわけにもいかず

手持ちのMA-100をPR400NE直下につなぎ監視することにする。

しかしこれはIPv6しか使えない。仕方が無いのでチェックするときだけ

直下にPCをぶら下げhttp://[fe80::1]でMA-100にアクセスして確認する。

p_big

MA-100

pr_400ne

PN400NE

MT-100 ログ

1 2014/06/02 06:38:31 PPPの認証成功[メインセッション]
2 2014/06/02 06:38:31 PPP-LCPの確立[メインセッション]
3 2014/06/02 06:38:30 PPPoE セッション開始成功[メインセッション]
4 2014/06/02 06:38:30 PPPoE AC発見成功[メインセッション]
5 2014/06/02 06:38:25 PPPoE セッション開放[メインセッション]
6 2014/06/02 06:37:43 PPPの認証成功[メインセッション]
7 2014/06/02 06:37:43 PPP-LCPの確立[メインセッション]
8 2014/06/02 06:37:42 PPPoE セッション開始成功[メインセッション]
9 2014/06/02 06:37:42 PPPoE AC発見成功[メインセッション]
10 2014/06/02 06:37:37 PPPoE セッション開放[メインセッション]

PPP認証には成功している、しかしDHCPv6アドレスの取得が出来ない。

後は回答を待つしかないので用事を済ませて戻ってみるとDHCPv6アドレスを取得していました。

ログはこんな感じでした。
1 2014/06/02 13:30:01 PPP-IPv6CPの確立[メインセッション]
2 2014/06/02 13:30:00 PPPの認証成功[メインセッション]
3 2014/06/02 13:30:00 PPP-LCPの確立[メインセッション]
4 2014/06/02 13:29:59 PPPoE セッション開始成功[メインセッション]
5 2014/06/02 13:29:59 PPPoE AC発見成功[メインセッション]
6 2014/06/02 13:28:20 PPPoE セッション開放[メインセッション]
7 2014/06/02 13:15:24 LAN4インタフェース リンクアップ
8 2014/06/02 11:31:13 ISPアドレスの取得
9 2014/06/02 11:31:10 PPP-IPv6CPの確立[メインセッション]
10 2014/06/02 11:31:09 PPPの認証成功[メインセッション]
11 2014/06/02 11:31:09 PPP-LCPの確立[メインセッション]
12 2014/06/02 11:31:08 PPPoE セッション開始成功[メインセッション]
13 2014/06/02 11:31:08 PPPoE AC発見成功[メインセッション]
14 2014/06/02 11:31:03 PPPoE セッション開放[メインセッション]
15 2014/06/02 11:31:02 PPPの認証失敗[メインセッション]

さっそくRTX-1200に切り替えました。

rtx1200_style

2014/06/02 13:39:11: PPPOE[02] Connecting to PPPoE server
2014/06/02 13:39:11: PPPOE[02] PPPoE Connect
2014/06/02 13:39:11: PP[02] PPP/IPV6CP up

もとどうり!!!・・・なんだったんでしょうか?

 

 

スマホde光電話のアリバイを崩す!

スマホで外出先から光電話で通話して、本当にアリバイが

証明されるのでしょうか?検証してみました。

ここからは素人のなんちゃって脚本になりますが・・・笑

会社社長のA氏は、倒産寸前の会社を立て直す為に、保険金殺人を企てました。

妻B子に多額の保険金を掛け、妻を自宅から300km離れた別荘で殺害します。

その直後、妻の携帯にスマホde光電話を利用して電話をし数十秒通話後切ります。

話をしている途中に来客があり、妻が”後で電話すると言って電話を切った”と証言する為です。

その後車で自宅に戻りながら、妻の携帯に数回スマホde光電話で着信履歴を残します。

明朝、隣人に”別荘に行った妻と連絡が取れなくなった”と話してから別荘に行き

妻を発見し、警察に通報する・・・・とドラマでよくありそうな設定です。

ドラマでは敏腕刑事がアリバイを崩していくわけですが・・・・・・

まず光電話ルータにはどのようなログが残るのでしょうか

実際に177あてに電話してみます。

光電話ルータPR-400NEの通話ログは、管理画面から見る事が出来ます。

通話に関するログは 、以下の2行です。

こちらから発信したときのログで、”自切断”とは自ら電話を切ったということでしょうか?

2012-12-18 09:47:32 voip -28.ntc: 通話 [自宅電話番号] [通話先電話番号]
2012-12-18 09:48:01 voip -30.ntc: 通話切断 [自宅電話番号] [相手先電話番号] 自切断

どの電話機から発信したかのログはありませんので、証拠は残りませんね!

次にルータRTX1200のログを見てみます。
2012/12/18 09:45:59: TUNNEL[20] PPTP connection is established: [スマホのグローバルIP]
2012/12/18 09:46:00: PP[ANONYMOUS01] PPTP Connect
2012/12/18 09:46:04: PP[ANONYMOUS01] Call detected from user ‘ユーザー名’
2012/12/18 09:46:07: PP[ANONYMOUS01] PPP/IPCP up (Local:[RTX1200のIP], Remote: [スマホに払い出されたIP])
2012/12/18 09:48:30: TUNNEL[20] PPTP connection is closed:  [スマホのグローバルIP]

PPTPに関するログは以上です。PPTPで接続したグローバルIPと接続ユーザー名はわかります。

ここから先は、私には調べる手段はありませんが・・・・

問い合わせれば、そのグローバルIPが払い出されていたスマホの特定は出来るかもしれません。

また特定したスマホがどこの基地局を使用していたかも分かるかもしれません。

しかし用意周到な犯人Aがそのようなログを消さずに残しているでしょうか?

素人ではこの辺までの推理しか出来ません。

しかし犯罪レベルではなく、家庭や、恋人へのアリバイ工作には使えるかもしれません。

あくまでもご自分の責任で・・・・・・・・・・

スマホ de 光電話公式ホームページ

RTX-1200配下nat越で”スマホdeひかり電話”を使う

前記事

家電(いえでん)の発着信履歴はアリバイにならず?

以前”RTX-1200配下nat越で”スマホdeひかり電話”を使う”という投稿をしましたが、

これをPPTP(L2TP)で外出先から使用すれば自宅にいなくても家電からの発着信が

出来てしまいます。

TVドラマで、家電での発着信履歴が不在証明となるシーンがありますが成り立たなくなりますね~

nat越えでスマホdeひかり電話が動作していれば、PPTPで同IPを割り当てるだけで使用できます。

VPNルータ(PPTP orL2TP)は、ひかり電話ルータの内部に設置することになりますので

natの設定は必須事項となります。

PPTPの設定はこちらの投稿を参照してください。


Rebooted by XTLB unmatch [load/fetch](19) その後

多いときは毎日”Rebooted by XTLB unmatch”というログを残してrebootしていた

RTX1200がここ数日は、安定しています。

設定変更したことといえば

1:pp2はIPv6用なのでIPv4をすべてフィルタリングした

2:pp3(PPPoE)を追加、ルーティングの設定を変更 http://www.hstech.jp/?p=390

思い当たるのはそれくらいです。

まだ5日目なのでもう少し様子を見ないと分かりませんが・・・

以前の設定変更時にも、reboot回数が減ったのですがいつの間にか元に戻ってしまったので

http://www.hstech.jp/?p=240

しかしこの情報は、ネットで検索しても少ないですね~

 

RTX1200 filterでルーティング追加

IPv4とIPV6の2つのPPPoEセッションでデュアルスタック運用してますが

フレッツ光ネクストが3セッション可能な契約なので、もうひとつISPを追加する為

RTX1200の設定を変更しました。

現状、IPv4(PP1)は/29でもらっているので、サーバー用にIP2つ、2つのローカルエリアネットワークから

それぞれNATで出る為に2IP使用しています。IPv6(PP2)はRAまかせです。

そこにPP3を追加するわけですが、ルーティングをどうするかです。

そこでデフォルトルートにフィルターかけて家庭用のLANをpp3に向けることにしました

現状のルーティング(他の拠点へのルートはIPsecトンネルへ向けています。)

ip route default gateway pp 1

ip route 192.168.0.0/24 gateway tunnel 1

ip route 192.168.1.0/24 gateway tunnel 2

ip route 192.168.2.0/24 gateway tunnel 3

ip route 192.168.3.0/24 gateway tunnel 4

ip route 192.168.4.0/24 gateway tunnel 5

ip route 192.168.5.0/24 gateway tunnel 6

ip route 192.168.6.0/24 gateway tunnel 7

ip route 192.168.7.0/24 gateway tunnel 8

 

新設定

新しく新ISP用にPP3を作成する

pp select 3

ip pp nat descriptor 100

pp enable 3

デフォルトルートに追加設定

ip route default gateway pp 1 gateway pp 3 filter 100

フィルター100に合致したものはPP3にルーティングされます。

ip filter 100 pass 192.168.99.2-192.168.99.254 * * * *

この設定では、192.168.99.0/24のネットワークからのルートがPP3にルーティングされます。

nat descriptor address inner 100 192.168.99.2-192.168.99.254

natの設定も必要ですが、nat descriptor address inner の設定だけで動作しています。

 

docomoスマホSPモードでテザリングVPN接続

iPhoneを使用してPPTPで自社ネットワークに接続していた方が、docomoのスマホに変えたら

接続が出来なくなったとのお話で、調べてみたらdocomoのSPモードではPPTPは使用できないらしい。

docomoのテザリングで旧iPhoneもVPNで使用する意向なのにこれでは何にもならない。

調べたところ。spモードでもL2TPならVPN接続が出来るらしい。

幸いなことにL2TPに対応しているRTX1200を使用しているので早速チャレンジしてみました。

YAMAHAのサイトを参考にして設定してみましたがどうもうまくいきません。

はまったのは、トンネルの暗号アルゴリズムと認証アルゴリズムの設定、上記サイトには複数のプロトコル

に対応しているとありましたが、成功したのは1組だけでした。

RTX1200のスマホ対応のL2TP設定は、以下です

RTX1200コンフィグ抜粋

pp select anonymous

pp bind tunnel20-tunnel22 トンネルは、同時接続するユーザー分必要なようです。

pp auth request mschap-v2  iPhone アンドロイドどちらもmschap-v2で認証できました。

pp auth username ユーザー1 パスワード

pp auth username ユーザー2 パスワード

pp auth username ユーザー3 パスワード

ppp ipcp ipaddress on

ppp ipcp msext on

ppp ccp type mppe-40  “mppe-any”ではNGでした

ppp ipv6cp use off

ip pp remote address pool 192.168.*.30-192.168.*.35

ip pp mtu 1258

pptp service type server

pp enable anonymous

トンネルコンフィグPPTPとL2TP両方使用するため混在してます。

PPTPトンネル

tunnel select 20

tunnel encapsulation pptp

tunnel enable 20

L2TPトンネル1

tunnel select 21

tunnel encapsulation l2tp

ipsec tunnel 101

ipsec sa policy 101 21 esp aes-cbc sha-hmac   この組み合わせでiPhone アンドロイドともOK

ipsec ike keepalive use 21 off

ipsec ike local address 21 192.168.*.1

ipsec ike nat-traversal 21 on

ipsec ike pre-shared-key 21 text パスワードL2TPトンネルでは同じ共有キーにする

ipsec ike remote address 21 any

l2tp tunnel disconnect time off

l2tp keepalive use on 10 3

l2tp keepalive log on

l2tp syslog on

ip tunnel tcp mss limit auto

tunnel enable 21

L2TPトンネル2

tunnel select 22

tunnel encapsulation l2tp

ipsec tunnel 102

ipsec sa policy 102 22 esp aes-cbc sha-hmac

ipsec ike keepalive use 22 off

ipsec ike local address 22 192.168.*.1

ipsec ike nat-traversal 22 on

ipsec ike pre-shared-key 22 text トンネル1と同じキー

ipsec ike remote address 22 any

l2tp tunnel disconnect time off

l2tp keepalive use on 10 3

l2tp keepalive log on

l2tp syslog on

tunnel enable 22

トランスポート設定

ipsec transport 1 101 udp 1701

ipsec transport 2 102 udp 1701

サービス開始

pptp service on

l2tp service on

別途静的NATの設定が必要(上記YAMAHAのサイトを参照)

例:ご自分の環境に読み替えてください

nat descriptor masquerade static 1 1 192.168.100.1 esp

nat descriptor masquerade static 1 2 192.168.100.1 udp 500

nat descriptor masquerade static 1 3 192.168.100.1 tcp 1723

nat descriptor masquerade static 1 4 192.168.100.1 gre

フィルターを通す設定

例:ご自分の環境に読み替えてください

ip filter 200080 pass * 192.168.100.1 esp * *

ip filter 200081 pass * 192.168.100.1 udp * 500

ip filter 200082 pass * 192.168.100.1 udp * 1701

RTX1200側の設定は以上です。

次にdocomoのスマホの設定をします。

YAMAHAのサイトにアンドロイドの設定法がありますのでこれを参考にします。

L2TP/IPsec PSK VPNを追加を選択します。

L2TPセキュリティ保護云々はスルーします。

説明どおりに進めます。これでSPモードのスマホからVPN接続が出来ます。

おめでとう!

次にこのスマホのテザリング機能を使用してiPhoneでVPN接続をします。

テザリングで使用できていれば

YAMAHAのサイトの方法で問題なく使用できました。

わたしのソフトバンクiPhone5のテザリング機能は来月15日にならなければ使用できないので

検証できませんが、PPTPが使えなくてもL2TPで使用できることがわかって安心しました。

後日検証出来たら報告したいと思います。

 

WindowsUpdate KB2661254でトラブル発生

参照アドレス

http://technet.microsoft.com/ja-jp/security/advisory/2661254

”長さ 1024 ビット未満の RSA キーを使用する証明書を信頼しなくなります”

との事で1024ビット未満のキーを使用していたWebminにアクセスできなくなりました。

原因が分かればなあーんだ!ということなのですが、最初は悩みました。

サーバーと、PCは同一ルータ配下にはあるのですが、別ネットワークになっているので

ルータを色々弄ったが解決せず。SSHでもVNCでも接続できたので不便はなかったのですが

Webmin の SSL 暗号化でRSA鍵長を2048に変更して元に戻りました。

参考サイト http://www.miyabi-solutions.com/blog/?p=1065

 

12時間続いたUDP bomb攻撃

202.101.42.30  から 自鯖宛に 15日23:37から16日12:07までおよそ2分間隔で

UDP bombパケットが送られてきました。

このIPのwhois情報は、以下 いい加減にして欲しいですね!

[whois.apnic.net]
% [whois.apnic.net node-2]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 202.101.0.0 – 202.101.63.255
netname: CHINANET-SH
descr: China Telecom
descr: SHANGHAI PROVINCE NETWORK
country: CN   → (中国)
admin-c: CH93-AP
tech-c: XI5-AP
mnt-by: APNIC-HM
mnt-lower: MAINT-CHINANET-SH
changed: hm-changed@apnic.net 20031104
changed: hm-changed@apnic.net 20031112
status: ALLOCATED PORTABLE
source: APNIC
person: Chinanet Hostmaster
nic-hdl: CH93-AP
e-mail: anti-spam@ns.chinanet.cn.net
address: No.31 ,jingrong street,beijing
address: 100032
phone: +86-10-58501724
fax-no: +86-10-58501724
country: CN   → (中国)
changed: dingsy@cndata.com 20070416
mnt-by: MAINT-CHINANET
source: APNIC
person: Wu Xiao Li
address: Room 805,61 North Si Chuan Road,Shanghai,200085,PRC
country: CN   → (中国)
phone: +86-21-63630562
fax-no: +86-21-63630566
e-mail: ip-admin@mail.online.sh.cn
nic-hdl: XI5-AP
mnt-by: MAINT-CHINANET-SH
changed: ip-admin@mail.online.sh.cn 20010510

ルーターログです。最後のほうは攻撃もとのIPが変わってます。

この2つのIPの共通点は

ns.yovole.com : 61.129.88.186 ns1.yovole.com : 202.101.  42.30と

どちらもyovole.comドメインのネームサーバーのようです。

日時 攻撃の名称 攻撃元アドレス 攻撃先アドレス

2012/10/16 07:22:33 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 07:25:12 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 07:27:19 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 07:30:30 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 07:33:05 UDP bomb 202.101.42.30 ***.***.***.39

2012/10/16 07:37:58 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 07:44:23 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 07:55:48 UDP bomb 202.101.42.30 ***.***.***.36

2012/10/16 07:56:30 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 07:57:58 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 08:09:46 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 08:19:59 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 08:20:56 UDP bomb 202.101.42.30 ***.***.***.39

2012/10/16 08:29:39 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 08:32:43 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 08:35:48 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 08:54:44 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 08:59:27 UDP bomb 202.101.42.30 ***.***.***.39

2012/10/16 09:03:50 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 09:05:25 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 09:06:26 UDP bomb 202.101.42.30 ***.***.***.39

2012/10/16 09:09:29 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 09:11:37 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 09:12:42 UDP bomb 202.101.42.30 ***.***.***.39

2012/10/16 09:15:01 UDP bomb 202.101.42.30 ***.***.***.39

2012/10/16 09:17:22 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 09:18:36 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 09:19:36 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 09:24:52 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 09:26:59 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 09:27:28 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 09:30:37 UDP bomb 202.101.42.30 ***.***.***.39

2012/10/16 09:31:29 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 09:32:54 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 09:33:17 UDP bomb 202.101.42.30 ***.***.***.39

2012/10/16 09:35:37 UDP bomb 202.101.42.30 ***.***.***.39

2012/10/16 09:39:44 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 09:47:18 UDP bomb 202.101.42.30 ***.***.***.39

2012/10/16 10:06:53 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 10:13:00 UDP bomb 202.101.42.30 ***.***.***.39

2012/10/16 10:13:59 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 10:17:41 UDP bomb 202.101.42.30 ***.***.***.33

2012/10/16 10:21:52 UDP bomb 202.101.42.30 ***.***.***.35

2012/10/16 10:31:11 UDP bomb 202.101.42.30 ***.***.***.39

2012/10/16 10:34:46 UDP bomb 61.129.88.186 ***.***.***.38

2012/10/16 11:19:39 UDP bomb 61.129.88.186 ***.***.***.39

2012/10/16 11:19:43 UDP bomb 61.129.88.186 ***.***.***.38

2012/10/16 11:27:26 UDP bomb 61.129.88.186 ***.***.***.39

2012/10/16 11:56:43 UDP bomb 61.129.88.186 ***.***.***.33

2012/10/16 12:05:08 UDP bomb 61.129.88.186 ***.***.***.33

Rebooted by XTLB unmatch [load/fetch](19)

RTX-1200がときどきREBOOTしている。

理由は分からないが、必ずこのログが残っています。

Rebooted by XTLB unmatch [load/fetch](19)

ググっても情報が得られずそのままになってましたが、IPv6のプロバイダ変更した際

いろいろいじってみたところ確証は無いがnatの設定の変更でREBOOTが減ったようです。

もう少し様子を見る必要がありますが・・・

LAN2にppインターフェースを2つ設定し(pp1:IPv4固定8IP pp2:IPv6)pp1に対し2つの

natディスクリプタ(lan1⇒pp1とlan2⇒pp1)をセットしていましたが、この内ひとつを

削除したところREBOOTの回数が減ったようです。

もう2、3日様子を見てから結論を出したいと思います。