ページ

2014年8月29日金曜日

FON2100E を DD-WRT 化に成功しました

先日入手した FON2100E ですが、すぐに fon-flash-gui でファームウェアの書き換えをしようとしたところ、書き換えができずに断念してしまいました。 本日はこの引き続きで、DD-WRT のファームウェアに書き換えを行い、成功しました。

ファームウェアの書き換えに成功した FON2100E です。

実のところ DD-WRT のファームウェアに書き換えはできたものの、各種の設定が保存することができない不具合が生じてしまいました。結局 gargoyle のファームウェアに書き換えて正常に動作をしていることを確認できました。

この記事は FON2100E の書き換えを行った備忘録として記述しています。

FON2100E は FON2201E のときとは大きくことなり、いきなり fon-flash-gui では書き換えができない状態です。一度ファームウェアの書き換えに成功すると fon-flash-gui で書き換えができるようになります。

それでは FON2100E のファームウェアの書き換えの手順の大まかな方法を紹介します。

参考にしたウェブサイトは次のものです。
LaFonera Software Flashing
http://www.dd-wrt.com/wiki/index.php/LaFonera_Software_Flashing

ファームウェアの書き換えに必要な電源投入時に telnet で redboot コンソールへ接続できるようにすることが大切で、その後にファームウェアの書き換えを行うようになっています。この telnet で redboot のコンソールへ接続するまでがいくつかの手順を踏まないとできない点に注意が必要です。大まかには次のとおりです。

  1. FON2100E へ SSH ログインできるようにする。
  2. SSH ログインを行って redboot の設定を変更できる拡張 FON ファームウェアを書き込む。
  3. SSH ログインを行って redboot の設定ファイルを書き換える。
  4. telnet で redboot のコンソールへと接続する。
  5. redboot のコンソールからファームウェアの書き換えを行う。
  6. redboot の起動方法の設定変更を行う。
  7. 再起動させて、無事に起動することを祈る。

参考にしたウェブサイトと一部変更してファームウェアの書き換えを行っていますが、基本は同じと考えてください。

1. FON2100E へ SSH ログインできるようにする。

まず最初に FON2100E のオリジナルのファームウェアを古い 0.7.1 r1 にします。 方法は簡単で、電源が入ったままの FON2100E のリセットボタンを30秒以上押し続けて離すだけです。これで 0.7.1 r1 のファームウェアに戻ります。なおインターネットへ接続できる状況に FON2100E を置いておくと、再び最新のファームウェアをダウンロードして設定し直してしまいます。そのためファームウェアの書き換え終了までは、インターネットへ接続できるようにルータなどへ接続するこは禁止となります。

古いバージョン 0.7.1 r1 に戻った FON2100E

FON2100E のファームウェアが 0.7.1 r1 に戻ったところで次のウェブサイトを参考にしてブラウザから SSH ログインができるようにする二種類のスクリプト(step1.html , step2.html)をファイルに保存します。
Hacking Fonera
http://blog.blase16.de/index.php?url=2006/11/28/Hacking-Fonera

--- step1.html ---
ここにスクリプトを記述したかったのですが、このブログでは上手く表記できないようです。

--- step2.html ---
ここにスクリプトを記述したかったのですが、このブログでは上手く表記できないようです。

ブラウザから step1.html と step2.html を順番に開きます。これで端末から SSH ログインができるようになります。パスワードは admin となります。なお最初に端末から SSH ログインするときには SSH のハッシュの認証を行う表示がでます。ここでは yes を入力して先に進みます。
$ ssh root@192.168.10.1

FON2100E へ SSH ログインができたら、SSH ログインを許可する dropbear の起動スクリプトの名称を変更します。
root@OpenWrt:~# mv /etc/init.d/dropbear /etc/init.d/S50dropbear


ファイアウォールの設定(/etc/firewall.user)を変更します。
root@OpenWrt:~# vi /etc/firewall.user

次に表示する2行の行頭にある # マークを削除して設定を有効にします。
# iptables -t nat -A prerouting_rule -i $WAN -p tcp --dport 22 -j ACCEPT
# iptables -A input_rule -i $WAN -p tcp --dport 22 -j ACCEPT

           ↓

iptables -t nat -A prerouting_rule -i $WAN -p tcp --dport 22 -j ACCEPT
iptables -A input_rule -i $WAN -p tcp --dport 22 -j ACCEPT

/bin/thinclient スクリプトの修正
root@OpenWrt:~#  vi /bin/thinclient

最終行の行頭へ # をつけてコメント化します。
#. /tmp/.thinclient.sh

そして最終行へ追加します。
cp /tmp/.thinclient.sh /tmp/thinclient-$(date '+%Y%m%d-%H%M')
これで vi を終了します。

以上で SSH ログインが常にできるようになりました。ここで一度 FON2100E の電源を切り、再投入しておきます。

2. SSH ログインを行って redboot の設定を変更できる拡張 FON ファームウェアを書き込む。

端末から FON2100E へ SSH ログインを行います。パスワードは admin です。
$ ssh root@192.168.10.1

参考ウェブサイトではインターネット上から拡張 FON ファームウェアをダウンロードして書き込むようになっています。しかし表記された場所に拡張 FON ファームウェアは存在しません。参考ウェブサイトに案内された別の場所から拡張 FON ファームウェア(openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma)と redboot の設定ファイル(out.hex)をパソコンへ事前にダウンロードしておきます。そしてパソコンに保存してあるファイルを nc コマンドを使って FON2100E へ転送します。

まず最初に FON2100E へ SSH ログインしている端末上で次のコマンドを実行します。
root@OpenWrt:~# cd /tmp
root@OpenWrt:~# nc -l -p 7000 > /tmp/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma

そして新しく端末を開き、拡張 FON ファームウェア(openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma)をダウンロードしたディレクトリへ移動して、 nc コマンドで転送させます。
$ cd (openwrt-ar531x-2.4-vmlinux-CAMICIA.lzmaが存在するディレクトリ)
$ nc 192.168.10.1 7000 < openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma

おそらく一瞬で転送が終了しているはずです。FON2100E へ SSH ログインしている端末上で ls コマンドで確認をしてみてください。
root@OpenWrt:~# ls
dhcp.leases
hostapd.conf
log
network-config
openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
resolv.conf
run
spool

拡張 FON ファームウェアを書き込みます。
root@OpenWrt:~# mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7

Unlocking vmlinux.bin.l7 ...
Erasing vmlinux.bin.l7 ...
Writing from openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma to vmlinux.bin.l7 ...  [w]

行尾の [w] の部分は、書き換え動作中は [w] と [e] を繰り替えして表示します。

書き換えが終了したら再起動します。
root@OpenWrt:~# reboot

3. SSH ログインを行って redboot の設定ファイルを書き換える。

再度 FON2100E へ SSH ログインをします。パスワードは adminです。
$ ssh root@192.168.10.1

拡張 FONファームウェアの転送と同じ要領で redboot の設定ファイル(out.hex)の転送を行います。
root@OpenWrt:~# cd /tmp
root@OpenWrt:~# nc -l -p 7000 > /tmp/out.hex

パソコン側の端末から redboot の設定ファイル(out.hex)を nc コマンドで発信します。
$ nc 192.168.10.1 7000 < out.hex

これも一瞬でファイルの転送が終了します。そしてファイルが存在するか確認します 。
root@OpenWrt:~# ls
dhcp.leases     log             out.hex         run
hostapd.conf    network-config  resolv.conf     spool

redboot の設定ファイル(out.hex)を書き換えます。
root@OpenWrt:~# mtd -e "RedBoot config" write out.hex "RedBoot config"
Unlocking RedBoot config ...
Erasing RedBoot config ...
Writing from out.hex to RedBoot config ...  [w]

再び FON2100E を再起動させます。
root@OpenWrt:~# reboot
 

4. telnet で redboot のコンソールへと接続する。

参考ウェブサイトでは、再起動(電源再投入)から10秒以内に telnet ログインするように記述されていますが、私の場合には redboot の状態で停止しており、いつでも telnet で redboot のコンソールへログインできる状況となっていました。

なおこの telnet ログインを行う前にパソコンの IP アドレスを設定変更しておきます。
192.168.1.166 / 255.255.255.0
なおパソコン上でデフォルト・ゲートウェイを設定しなければならないときには、192.168.1.1 でも入力しておいてください。

それでは telnet コマンドを使って FON2100E の redboot コンソールへログインします。
$ telnet 192.168.1.254 9000

Trying 192.168.1.254...
Connected to 192.168.1.254.
Escape character is '^]'.

この状態のままで redboot のプロンプトが表示されない場合には一回リターン・キーを押せば表示されるはずです。
RedBoot>
これで redboot のコンソールへログインできました。この後、ファームウェアの書き換えなどを行います。

5. redboot のコンソールからファームウェアの書き換えを行う。

次のように redboot のコマンドを使用して FON2100E のネットワーク環境の設定を行います。
RedBoot> ip_address -l 192.168.1.254/24 -h 192.168.1.166

IP: 192.168.1.254/255.255.255.0, Gateway: 0.0.0.0
Default server: 192.168.1.166
そしてフラッシュメモリのシステム部分の初期化を行います。
RedBoot> fis init

About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .

パソコン上にある DD-WRT のファームウェアを転送してきます。この場合、パソコン側で TFTP サーバの設定が必要です。また TFTP サーバのダウンロード・ディレクトリへ DD-WRT のファームウェア( linux.bin )を用意しておく必要があります。私の場合、以前から使用していた tftpd を使いました。この tftpd は、参考ウェブサイトで推奨の tftpd-hpa ではなく、debian 標準のもの(無印 tftpd )を使用しました。TFTP サーバ(tftpd)のインストールや設定は割愛します。
RedBoot> load -r -b 0x80041000 linux.bin
Using default protocol (TFTP)
Raw file loaded 0x80041000-0x8066efff, assumed entry at 0x80041000
転送してきたファームウェアを展開します。この部分で30分以上の時間が掛かりました。気長に待ちましょう。
RedBoot> fis create linux
... Erase from 0xa8030000-0xa865e000: ...................................................................................................
... Program from 0x80041000-0x8066f000 at 0xa8030000: ...................................................................................................
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .

redboot のプロンプトが表示されて処理が終了したことを確認して reset コマンドで再起動させます。
RedBoot> reset

6. redboot の起動方法の設定変更を行う。

現状のままでは、 redboot のコンソールの部分で停止した状態となっています。そこで redboot の設定を変更して DD-WRT が自動的に起動するようにします。
端末から再び telnet コマンドで FON2100E の redboot コンソールへログインします。
$ telnet 192.168.1.254 9000

Trying 192.168.1.254...
Connected to 192.168.1.254.
Escape character is '^]'.

redboot のコンソールから設定スクリプトを実行します。
RedBoot> fconfig
Run script at boot: true
Boot script:
.. fis load -l vmlinux.bin.l7
.. exec
Enter script, terminate with empty line
>>
ここで次のようにコマンドを入力します。
>> fis load -l linux
>> exec
>> 
この状態で次の表示が出てこないときにはリターン・キーを一回押します。
そして次のように質問が表示されますので次のとおりに回答して行きます。
Boot script timeout (1000ms resolution): 10
Use BOOTP for network configuration: false
Gateway IP address: 192.168.1.254
Local IP address: 192.168.1.254
Local IP address mask: 255.255.255.0
Default server IP address:
Console baud rate: 9600
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .


以上で redboot の設定は終了です。reset コマンドで再起動させます。
RedBoot> reset

7. 再起動させて、無事に起動することを祈る。

しばらく放置していると無線 LAN の電波に DD-WRT の SSID が表示されてくると思います。無線 LAN は何もセキュリティの無い状態ですのでそのままログインできます。そしてブラウザから 192.168.1.1 へアクセスを行って DD-WRT の設定を行います。

ここで私の場合ですが、ログインパスワードの設定の部分は無事に設定することができたのですが、その後の設定がすべてできない状態となってしまいました。設定を反映させようとするとブラウザの接続が切れてしまいます。再び 192.168.1.1 へアクセスすると変更前の内容が表示されています。

一番最初に DD-WRT のビルド 14896 のファームウェアを使用しましたが、その後 fon-flash-gui を使って、ビルド 13064 も書き込んでみましたが同様の症状が発生しました。

そこで再び fon-flash-gui を使ってgargoyle 1.2.5 のファームウェアを書き込んでみると、設定もちゃんと保存されて、設定も反映させることができました。現在のところ DD-WRT が正常に動作しない理由は不明です。

DD-WRT のステータス画面です。

2014-08-30 追記

DD-WRT が正常に動作しなかった件ですが、gargoyle を導入した後、再度 DD-WRT ( Build 14896 ) を焼き直したところ、正常に動作するようになりました。結局 DD-WRT が動作不良となっていた原因については不明です。リージョン(region)に JP を指定できる DD-WRT において しばらく使用してみたいと思っています。

DD-WRT でも稼働するようになった FON2100E

Linksys BEFSX41 ルータを入手しました

インターネット・オークションにて Linksys 社のルータ BEFSX41 ver2.1 を入手しました。

入手した Linksys BEFSX41 です。

インターネット・オークションには似た型番の BEFSR41C という機種のルータが数多く出品されていますが、本機 BEFSX41 は日本では未発売の機種のようです。物珍しさから落札してきました。

なおインターネット上でも BEFSX41 について記述された日本語のブログ類が見当たりません。情報収集は主にアメリカ圏の英語で記述されたものが頼りとなっています。

BEFSX41 の前面
BEFSX41 の背面
ポート 4 が DMZ 対応ポートとなっています。

外観は Linksys 社の無線LANルータの WRT54G シリーズと同じ筐体を使用しています。そのため無線LANルータとの積み重ねも出来ます。このように同一の筐体の使いまわしはコストダウンの他、デザイン性の統一などいろいろなメリットもあるようです。

二段重ねにした BEFSX41 と WRT54GS です。
上段が BEFSX41 , 下段が WRT54GS です。



まず最初に動作確認のために背面にある初期化ボタン(リセットボタン)を押して、初期化した後、BEFSX41 へブラウザからアクセスしてみました。BEFSX41 の初期値の IP アドレスは 192.168.1.1 です。そしてパスワードは、ユーザ名: 空欄 、パスワード: admin となっています。

ファームウェアのバージョンを確認してみると 1.52.9 となっていました。Linksys 社のウェブサイトでファームウェアの存在を確認すると、有りませんでした。どうもこの 1.52.9 のバージョンが最初で最後のファームウェアのようです。

BEFSX41 の設定画面です。

いつものようにデータ転送速度の計測を行ってみました。BEFSX41 の測定条件は、初期化した状態のまま、DHCP クライアントで家庭内 LAN へ接続して、自宅サーバから FTP 転送でおよそ 100MB の単一ファイルをダウンロードすることで計測しました。5回計測の平均値を求めました。

データ転送速度 計測結果
1,619 KB/s ( 12,951 Kbps )

なんともしょぼい計測結果となってしまいました(笑)。

2000 年代前半に製造された商品なので、ADSL モデムを経由しての通信であれば問題ない程度の性能となっていました。ちょうどヤマハの RTA55i と同程度の性能でした。

余談ですが 2ch のプロバイダのスレッドなどを閲覧していると、夜間の19時から24時ごろにかけて光回線にも係わらず一部のプロバイダで激しい速度低下(場合によっては 1Mbps を下回る)が見られるなどの書き込みが見られることから、意外とこの 12Mbps 程度の速度のルータでも現役で通じるのではないかとも思ってしまいます(笑)。

BEFSX41 の設定を変更して、PPPoE 接続で直接インターネットへ接続して、BEFSX41 へ接続したパソコンから我が家の OpenVPN サーバへ接続をしてみました。なお BEFSX41 本体には VPN 接続の機能は存在していません。

OpenVPN で接続は可能だったのですが、どうもデータの受け渡しが上手くできないようです。ブラウザで各ウェブサイトを巡ると画像が表示されなかったり、接続ができないことがありました。なお PPTP 接続では問題は発生しませんでした。

BEFSX41 へ接続しているパソコンを DMZ として設定すると問題なく通信を行って、問題が発生したウェブサイトも閲覧できるようになりました。

そこでいろいろと調査してみるとファイアウォール機能の SPI ( Stateful Packet Inspection ) を無効にすると OpenVPN の接続が正常に行えることが判明しました。

この現象は SPI の誤動作と言うよりは、時代的に OpenVPN を配慮した設計となっていないことが原因のようです。SPI は完全ではありませんが、ファイアウォール機能としては有効な手段のため無効にしてまで OpenVPN 接続をする必要性はないと思われます。

OpenVPN を使用するにはファイアウォール機能を無効にする必要があります。
PPTP であればそのまま使用できます。

無線LANルータの WRT54G のように第三者が作成したファームウェアの導入ができるものであれば、もう少し遊べたかもしれません。本機 BEFSX41 は私の Linksys コレクションの一つとして保管することとしました。

2014年8月28日木曜日

FreeBSD PHP5 と Asterisk のアップデート

FreeBSD の ports へ php5 のアップグレード(php5-5.4.31_1 --> 5.4.32)と Asterisk のアップデート(asterisk18-1.8.30.0 --> 1.8.30.0_1)が到着していました。

いつもと同じように portupgrade で更新をしておきました。

なんだか最近は php5 のアップグレードが頻繁に行われているように感じます。

2014年8月27日水曜日

FON2100E を入手

インターネット・オークションにて FON2100E を入手しました。先日の FON2201E や FON2405E に引き続いて三台目のものとなります。

今回入手した FON2100E です。

届いた FON2100E の状態はなかなか良いもので、梱包箱や説明書や fon ステッカーなどの備品も揃っていて、本体そのものも表面の保護シールも残されていて綺麗な状態でした。

FON2100E を入手した状態です。

しかしこの保護シールを剥がしてみると、シールのラベル部分を残して日焼けをしている状態でした(笑)。このような保護シールで表面を保護することは傷から本体を守ってくれますが、変な日焼けを引き起こしてしまうようです。もっと別の方法で表面を保護することを考えた方がよいようです。

FON のロゴマークの周囲の白いプラスチックが黄色く変色しています。

早速電源を投入して動作状況を確認してみました。無線 LAN の電波が発射されていない状況でしたが、しばらくすると FON_AP や MyPlace の電波が発射されているのを確認しました。どうもファームウェアのアップグレードが行われていたのではないかと思われます。FON のファームウェア・バージョンは 0.7.2 r2 でした。

とりあえず MyPlace のところから FON2100E を経由してインターネットへ接続してみました。問題なくインターネットへアクセスができました。ハードウェアには問題はないようです。ただネット上では FON2100E の発熱が酷いとのことでしたが、確かに本体が熱くなっています。真夏の猛暑日や酷暑日に使用するには躊躇させられます(笑)。

そこで早速 DD-WRT 化を行なってみることとしました。

FON2100E へファームウェアを書き込みます。

いつものようにイーサネット・スイッチを経由してファームウェアを書き込むパソコンと FON2100E を接続しました。そして fon-flash-gui で DD-WRT のファームウェアを書き込もうとしました。すると初期段階で停止してしまいました。
Telnet for RedBoot not enabled

どうも現状では fon-flash-gui でファームウェアの書き込みができないようです。

ssh ログインができる 0.7.1 r1 以前のファームウェアでないと設定できないのでしょうか?

もしかして本体を開いてシリアルコンソールから接続をする必要性があるのでしょうか?できることであれば、解体せずに書き換えができればよいのですが・・・。

FON2201E でトントン拍子にファームウェアの書き換えが成功していたので、この FON2100E でも同様の感覚でできるものと思い込んでいました(涙)。

ネット上をしばらく検索して今後の対応を考えてみたいと思っています。

FON2100E(左) と FON2201E(右) の比較

2014年8月25日月曜日

FreeBSD 9.3 へアップグレード

FreeBSD 9.2 から 9.3 へアップグレードを行いました。

どうも8月5日にはすでに FreeBSD 9.3 が発表されていたようですが、全然気づかないままでした。まあ、いきなり飛びつくほどのものではないので、ちょっと様子見をした感じでアップグレードをしたこととなります。
FreeBSD 9.3-RELEASE アナウンス
http://www.freebsd.org/ja/releases/9.3R/announce.html

FreeBSD 9.3 へアップグレードを行って特に問題は発生していません。いつものように我が家のサーバとして活躍しています。

またアップグレードの方法は subversion で /usr/src のソースツリーを更新した後、buildworld と buildkernel でビルドするという従来から行ってきた方法です。出来上がったシステムは、サーバマシンで使用されているプロセッサの P4-Prescott に適応したものとなっています。通常の i686 ビルドによるものとの速度の違いがどれほどあるのかは不明で、まったく気分の問題となっています(笑)。プラシーボ効果と言ったところでしょうか。

2014年8月23日土曜日

FreeBSD php5-5.4.31_1 へアップデート

FreeBSD の ports へ php5 のアップデートが到着していました。

具体的な修正点は不明ですが、ネットワーク関連でもよく使われる php5 だけに、アップデートが到着したときには速やかに対応するようにしています。

もちろん今回の pho5 のアップデートに伴ってウェブサーバの Apache の php5 のモジュール(mod_php5-5.4.31_1,1)もアップデートが行われました。

2014年8月22日金曜日

Asterisk 1.8.30.0 へアップグレード

FreeBSD の ports へ Asterisk のアップグレード(1.8.30.0)が到着していました。

いつものように portupgrade で更新を行なっておきました。

とりあえず我が家では問題なく動作しています。

Asterisk 1.8.30.0 のビルド設定画面

2014年8月20日水曜日

@nifty のメール送信の認証

今日8月20日からニフティのメール送信が SMTP 認証へと全面移行しました。

私のところではすでに SMTP 認証に切り替えを行なっていましたが、実際に全面切り替えで正常に動作するか一抹の不安が残っていました。

本日メールを送信してみるとちゃんとメールの送信が行われました。SMTP 認証の設定に問題はなかったようです。

ニフティのメール認証については公式ウェブサイトにも設定案内がありますので、ニフティのメールが送信できない症状を抱える人は一読してみることをおすすめします。

2014年8月20日以降、@niftyのメール送信ができなくなりました。どうしたらいいですか。
http://qa.nifty.com/cs/catalog/faq_nqa/qid_14931/1.htm

2014年8月19日火曜日

岩通 BR-1000v の syslog を取得してみました。

岩崎通信機の BR-1000v には syslog を出力する機能があります。そこで Debian Wheezy がインストールされているマシンへ syslog を出力して、動作状況を取得してみました。

BR-1000v の設定は [システム設定] [SYSLOG設定] で設定を行います。ホストアドレスへ syslog を受信するマシンの IP アドレスを指定して [登録] ボタンをクリックしたら設定は終了です。

syslog を受信する Debian Wheezy マシンでは /etc/rsyslog.conf を設定します。

設定ファイル(/etc/rsyslog.conf)の冒頭付近にある以下の二行の行頭にある # マークを削除して外部からの syslog を受信できるようにします。
# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514
    ↓
$ModLoad imudp
$UDPServerRun 514

設定ファイル(/etc/rsyslog.conf)の修正が終了したら、rsyslog デーモンの再起動を行います。
# /etc/init.d/rsyslog restart

この状況で BR-1000v を再起動させるなど内部イベントが発生する状況を作り出します。Debian Wheezy マシンの /var/log/user.log を観察してみます。ちゃんと記録されていれば syslog の設定成功です。 以下は syslog への出力例です。
Aug 19 17:11:10 Firmware Ver. 1.120 : system checksum
Aug 19 17:11:10 br-1000v MD5: 14a607b1-63e1f2f0-758394c5-e94c19a5
Aug 19 17:11:15 DHCP Client bind address success.
Aug 19 17:11:15 DHCP Client server ip address 192.168.24.100
Aug 19 17:11:15 DHCP Client get my address 192.168.24.34/24
Aug 19 17:11:15 DHCP Client add default gw 192.168.24.1
Aug 19 17:11:15 DHCP Client get DNS1 server address 192.168.24.100
Aug 19 17:11:15 DHCP Client get domain name example.com
Aug 19 17:11:15 Connecting to time server...
Aug 19 17:11:15 Send NTP requst packet to server 1 ( 192.168.24.100 )
Aug 19 17:11:15 Now adjusted time at 2014/08/19 17:11 .
Aug 19 17:11:16 br-1000v SIP: send request method [REGISTER]

この状態でプリンタの印刷を BR-1000v のプリンタサーバを経由して行なってみました。
Aug 19 17:26:47 br-1000v LPD: tiny lp deamon start tn=c6cb084
Aug 19 17:26:48 br-1000v LPD: tiny lpd printer initialize success
Aug 19 17:26:48 br-1000v LPD: tiny lpd print start (queue name:PASSTHRU#012,data name=dfA639t, data size=275667byte)

こんな感じで syslog へ出力されていました。ちゃんと BR-1000v の lpd デーモンは Debian Wheezy マシンからのプリントデータは受信しているようでした。

このまま放置しても印刷は途中で中断されたまま、 lpd デーモンからの syslog も新しい出力はありませんでした。一体どうして印刷が途中で中断してしまうのでしょうか? ホント困りました。

今回得られた新しい情報として BR-1000v のプリンタサーバには tiny lpd というものが使用されていることが判明しました。しかし tiny ftp の情報はインターネット上にたくさん有りますが、tiny lpd の情報はほとんど存在しないようです。

PLANEX Mini100plus プリントサーバ

プラネックス社のプリントサーバの Mini100plus をインターネット・オークションにて入手してきました。

プラネックス Mini100plus プリントサーバ
プリンタ側
プラネックス Mini100plus プリントサーバ
イーサネット端子側

私は引きずる性格なのか、先日の岩通 BR-1000v にてプリントサーバが上手く動作しなかったことから、この手のプリントサーバの設定方法に何か問題があるのか探り当てるために、新しく別種のプリントサーバを入手してきたわけです。

今回のプリントサーバを入手するにあたり、linux の lpr コマンドに対応したものを選択するようにしました。いわゆるプリントサーバ側で lpd デーモンが稼働している状態のものです。

早速の結論ですが、Debian Wheezy がインストールされたパソコンで問題なく印刷することができました。それもあっさりとです。岩通 BR-1000v と同じ要領で設定して正常に印刷が可能であったことから、やはり BR-1000v のプリントサーバ機能は linux マシンからは使い難いものとなっているようです。

さてプラネックス Mini100plus の設定の紹介です。

このプラネックスのプリントサーバの mini100 シリーズをネット検索していると arp コマンドで IP アドレスを設定したあと、機能設定をする方法が紹介されていたため、この arp コマンドを使用してみることとしました。

特権ユーザになったあと、次のようにコマンドを実行すれば、プリントサーバの Mini100plus へ IP アドレスをパソコン側へ設定することができます。
# arp -s 192.168.24.191 00:90:cc:1c:3b:77
この例では mac アドレス 00:90:cc:1c:3b:77 のプリントサーバへ 192.168.24.191 の IP アドレスをパソコンのシステム内部へ設定したこととなります。プリントサーバ本体には、まだ IP アドレスは設定されていません。または違う IP アドレスが設定されています。

この状態でパソコンのブラウザから 192.168.24.191 へアクセスするとプリントサーバの設定画面を開くことができます。

この設定画面から TCP/IP で使用する IP アドレスを設定します。これで正式にプリントサーバへ IP アドレスが設定されます。

設定画面で TCP/IP の設定を行います。

プリントサーバの設定は TCP/IP の IP アドレスの設定だけで印刷可能な状態となります。がしかし、設定画面でプリンタの状態を確認するとメーカー名やモデル名などを取得できていないようです。そこでプリンタ設定の双方向通信の項目を [無効] から [自動認識] へ切り替えてみると、プリンタの情報を取得して表示することができました。今回実験で使用したキヤノン BJF850 ではこのプリンタの双方向通信をどちらの設定にしても印刷は正常に行われました。

プリンタの双方向通信を自動認識にするとプリンタ情報を取得できます。


Debian Wheezy がインストールされたパソコン側では CUPS 上で lpd プロトコルで通信をするように設定をするだけでした。

lpd://192.168.24.191/lp

この設定では、プリンタのキュー名の指定は特に無かったことから、一般的な lp で設定しておきました。

パソコン側の CUPS の設定状況です。

Mini100plus をプリンタへ接続したところです。
直接プリンタのコネクタへ接続する形式となっています。
二個の LED ランプがあります。
緑色が電源表示で、黄色が通信時に点滅するようになっています。
電源アダプタは本体に比べて大きめのものです。
しかしスイッチング方式なのか重さは軽いです。
直流 5 ボルト 2 アンペア仕様

2014年8月17日日曜日

Asterisk 1.8.29.0_1 へアップデート

FreeBSD の ports へ Asterisk 1.8.29.0_1 のアップデートが到着していました。

いつものように portupgrade で更新しておきました。

それから、おそらく前回の 1.8.28 から 1.8.29 へのアップグレードのときだったと思われるのですが、保留音の設定が変更されていたようです。musiconhold.conf の設定の見直しも行なっておきました。以前設定していた保留音が流れなくて、少し驚いてしまいました(笑)。

2014年8月16日土曜日

プリンタのカバーを修理

もう購入して何年になるのでしょうか? もう10年以上昔に購入したキヤノンのレーザープリンタ LBP-A404GII の天板カバーの蝶番が折れてしまいました。紙詰まりを起こす度に何度も開け閉めを行う部分なので、疲労が溜まっていたものと思われます。この天板が開いたままだどプリンタとしての動作が行われない構造となっているため、この壊れた蝶番の部分の修理をしてみました。

天板の蝶番が破損した LBP-A404G2 です。
写真の向かって左側の蝶番が破損しました。

修理とは言っても、エポキシ接着剤で固定するだけです。

ただ接着剤の力だけでは接触面積の小さなところを固定するには無理があります。そこで少し太めの針金を短く切って、エル字型に曲げて補強としました。この蝶番の部分にはバネの力で天板を推し上げようとする力が加わるので、こうした補強は大切だと思っています。

写真はエポキシ接着剤が固着した後の様子です。この状態で天板を閉じてみると、問題なく閉じることができました。強度が不足した感じもありませんでした。

接着した蝶番の部品の様子です。
銀色に光る針金は補強のためのものです。

この写真は接着途中の様子です。セロテープで針金が脱落しないように押さえています。まだ蝶番の下の部品が下方向へ逃げないように固定するために小さなプリント印刷基盤を差し込んでいます(笑)。

接着途中の様子です。セロテープで仮止めをしています。
もう殆ど使用しなくなったプリンタですが、まだトナーが残っていることからまだ残しています。レーザープリンタは何台も購入してきましたが、残ったのはこの一台だけです。

2014年8月15日金曜日

岩通 BR-1000v のプリント・サーバ機能

岩崎通信機 BR-1000v のプリント・サーバ機能を試してみました。

Debian Wheezy がインストールされたマシンから CUPS 経由で印刷ができるかどうかの確認を行なってみました。プリンターにはキヤノン BJ F850 (海外形式 BJC-8200)を使用しました。

まず最初に使用するパソコンのプリンタ・ポートへ直接プリンタを接続してテスト印刷ができることを確認しました。

この上で、プリンタを BR-1000v へ接続し直して、CUPS の設定をネットワーク印刷へと切り替えました。

BR-1000v のマニュアルによると、プリント・キューは PASSTHRU ということなので、BR-1000v の IP アドレスと、このキュー名を使用して以下のように設定しました。なお BR-1000v の IP アドレスの初期値は 192.168.0.1 ですが、192.168.32.1 へ変更してあります。初期値で使用している読者さんが参考にする場合には、初期値の 192.168.0.1 と読み替えてください。
lpd://192.168.32.1/PASSTHRU

そしてプリンタドライバはローカル接続をしていたときと同じ Canon BJC-8200 - CUPS+Gutenprint v5.2.9 を選択して終了しました。

テスト印刷を行なってみましたが、なぜか上手く動作してくれませんでした。

テスト印刷の最初の部分(上部の部分)をほんの少し印刷しただけで中断してしまうのです。何か設定が悪いようですが、解決できませんでした。


岩通 BR-1000v のファームウェア・アップデート

昨日入手した岩通 BR-1000v ですが、ファームウェアのバージョンが 1.112 であり、最新のファームウェア・バージョンが 1.120 であったので、アップデートを行なっておきました。

メーカー公式ウェブサイトから最新のファームウェアをダウンロードしてきました。
http://download.iwatsu.co.jp/download/br1000v/

ファームウェアは LHA 形式の自動解凍実行ファイルとなっています。Windows マシン上でファイルを実行させて、内容を解凍させました。

ファームウェアのアップデートの方法は、同梱されていた PDF 形式の書類の中に詳しく記述されていて、だれでも問題なくアップデートができるようになっていました。

BR-1000v 本体側を [Firm Utility 使用モード] へと切り替えて、Windows マシン上で setup.exe を実行させます。すると Firm Utility が起動します。ここでアップデートするファームウェアを選択して、さらに BR-1000v の IP アドレスを入力します。これで実行ボタンをクリックするとファームウェアのアップデートが行われました。

ファームウェアのアップデートが終了すると BR-1000v 本体が自動的に再起動して Firm Utility の画面もファームウェアの更新が終了したことを表示していました。

このあと、 BR-1000v の設定画面へブラウザでアクセスすると、ファームウェアのバージョンが 1.120 へアップデートしているのが確認できました。

BR-1000v へ以前から設定していた項目はそのまま引き継がれており、問題なく動作もしているようです。また 1.112 から 1.120 へのアップデートでは、新しい項目の追加などは見られないようです。

2014年8月14日木曜日

岩崎通信機 BR-1000v を入手

インターネット・オークションにて岩崎通信機 BR-1000v を入手しました。

今回入手した岩崎通信機 BR-1000v です。

この BR-1000v は、いわゆる家庭用のルータですが、オプションで取り付ける無線 LAN 機能や SIP クライアント、プリンタ・ポートを備えている多機能ルータの一種です。今回 SIP クライアント機能に目をつけて落札してきました。

BR-1000v の背面

入手した BR-1000v には電源アダプタが付属していませんでした。そのため、この電源アダプタを用意することから始めました。メーカー公式ウェブサイトからマニュアル類をダウンロードして調べてみると、電源アダプタは直流12ボルトのもののようです。そこで手持ちの12ボルトの電源アダプタを挿して起動させてみました。電源アダプタは 400mA の出力のものでしたが、この電源アダプタでも動作させることができました。本当は 1A か 2A 程度のものを使う方がよいと思われます。

BR-1000v の LAN 端子へパソコンを接続して、BR-1000v の DHCP 機能でパソコンへ IP アドレスの設定を行わせてみました。192.168.0.10 の設定となっていて、この BR-1000v が 192.168.0.0/24 のサブネットを使用していることが判明しました。そこで 192.168.0.1 へアクセスしてみると、BR-1000v の設定画面が表示されました。運良くパスワードによる保護が行われていなかったので、そのまま設定を開始することができました。

設定の様子を確認すると、以前の所有者さんの設定がそのまま残っていました。そこでこの設定画面上から初期化を行なって古い設定をすべて消去しました。

ネットワークの設定は WAN 側は DHCP の受信設定としました。これで WAN 端子をそのまま家庭内 LAN へ接続して SIP クライアント機能を確認してみることとしました。

この BR-1000v の電話機能は、一般電話回線と SIP クライアントを通じた VoIP 通信ができるようになっています。しかし一般電話回線で使用することはないため、「電話回線のみ」「VoIPのみ」「両方」のように切換設定がありましたが、VoIP のみの設定としておきました。

SIP クライアント機能を設定する「VoIP設定」の部分にて、自宅の Asterisk サーバ設定へ設定を行なってみました。

設定ポイントとしては「VoIP接続設定」で [接続方法の選択] = [その他] を選択することでした。下図参照。

「VoIP接続設定」では [その他] を選択する。

そして「SIP設定」において [SIPサーバ設定] のところでユーザ名やパスワードの設定の他、 [登録時間] の設定へ登録時間の秒数を設定する必要がありました。ここが空欄だと発信は可能ですが、着信ができない状況となってしまいます。私の場合、1時間の秒数の 3600 を入力しました。

SIP クライアントの設定の様子。

以上で無事、自宅の Asterisk サーバへ登録することができました。発信、着信、転送がちゃんとできました。

通話音質もまずまずで、エコーキャンセラーを切った方が音声がクリアになるように感じました。
気になることは、受話器をあげてダイヤルを開始するまでの間に流れる「ツー」音が、なんだか途切れ途切れになっていることです。このツー音の影響のためか?通話中の音声も途切れる印象がありました(笑)。


プリンタ機能などまだ確認をしていない機能もあり、もう少し BR-1000v で遊んでみたいと思っています。

丸い LED ランプを直接露出するという昔なつかしいデザイン
無線LANカードをスロットへ挿してみました。
写真のものでは通信できないようです。

2014年8月7日木曜日

dyn の IP チェックサイトが危ない?んですけど

以前からダイナミック DNS サービスの dyn において、IP チェックサービス用のウェブサイトからの返答がなく、タイムアウト・エラーになったことを知らせるシステム・メールが頻繁に届くようになりました。
WARNING:  TIMEOUT: checkip.dyndns.com after 120 seconds
dyn のサービスはすべて有料に切り替わった時点で我が家は no-ip のサービスへと乗り換えています。しかし IP アドレス更新用のソフトウェアの ddclient はそのまま使い続けています。

この ddclient で使用出来る公開された IP チェックのホームページはほぼ皆無に近く、以前のように dyn の IP チェックのホームページ(checkip.dyndns.com)を使い続けるしかないようです。本来は no-ip に乗り換えた時点で no-ip の方で用意している IP チェックのホームページを使用すべきもののはずなのですが、なぜか no-ip の IP チェックのページが見当たりません。

そろそろ IP チェックが出来なくなることを予想して、何らかの対策をしておかなければならないようです。

一つとしては、以前から借りていた外部のホームページ用領域に IP アドレスをチェックするスクリプトを一時的に組み込んで使用してみることとしました。ddclient の設定も新しい IP チェック用のホームページへアクセスするように変更しておきました。

この外部のホームページ領域へ IP チェック・スクリプトを組み込むのが一番簡単なような気がしますが、最近ではブログではなく、旧来からの手作りホームページをアップロードできるレンタル・スペースも減少している模様です。

そこでルータ(フレッツ光ネクスト隼の HGW : PR-400NE)の設定ページの中に記述されているグローバル IP アドレスを読み出す方法はないものかと、少しシェルスクリプトを考えてみました。

まだ未完成ですが次の二段階でグローバル IP アドレスが PR-400NE から取得できます。試した環境は Debian Wheezy の bash シェルのです。

1. PR-400NEの「現在の状況」のページの取得します。
$ wget --http-user user --http-passwd PASSWORD http://192.168.1.1/index.cgi/info2_main
info2_main の名前で「現在の状況」のページが保存されます。ユーザは user 固定です。パスワードは PASSWORD へ手持ちの機械のパスワードを設定してください。

2. 保存した「現在の状況」のページ(info2_main)の中から sed コマンドでグローバル IP アドレスを抽出します。
$ egrep -o '[0-9]+(\.[0-9]+){3}' info2_main | sed -n '1p'


このシェルスクリプトを crontab で定期的に実行させて、出力した IP アドレスの変化を ddclient で検出するようにすれば、外部の IP チェックに頼らずにダイナミック DNS の IP アドレスを更新することができるようになるはずです。

またシェルスクリプトに進展がありましたら、報告します。

2014年8月6日水曜日

OpenVPN を通じてソフトフォン(Ekiga Phone)を使う

自宅サーバへインストールした OpenVPN ですが、だんだんと実用的になってきました。

先日からソフトフォン(Ekiga Phone)を外部で使用するパソコンへインストールして家庭内の Asterisk サーバへ接続してみました。

意外とあっさりとダイヤルや通話ができてしまって驚いてしまいました。

しかし気になる点がいくつか発生していました。
  • 第一点目は、通話終了後に電話を切ってももう片方の電話機が通話中のままだったのでした。
  • 第二点目は、ソフトフォンの Ekiga Phone の通話中に表示される通話先の電話番号にグローバル・アドレスが表示されていることでした。

これらの二点から、どうもダイヤルを行なっている最中の SIP プロトコルは OpenVPN の中を経由して通信を行なっているようですが、通話が開始されて RTP プロトコルへ移行した段階で OpenVPN 経由ではなく、単純にインターネット環境の通信へ移行してしまっているようです。このため一般のインターネット環境を経由した状態では通話後の BYE 信号(Hangup)がルータなどのパケットフィルタで遮断されてしまって通話が持続し続ける現象が発生している模様です。さらにこの仮定を裏付けるものとして、一時的にルータのパケットフィルタ( UDP : 5060 )を 開放するとちゃんと通話が正常終了するのです。

そこでこの OpenVPN を通じて通話パケットが流れて行かない原因と対策を行なってみました。

基本的な原因は Asterisk サーバにありました。そこで Asterisk サーバの設定の見直しを行いました。

それは Asterisk サーバが家庭内 LAN だと認識するネットワーク領域(サブネット: Subnet )に家庭内の LAN のサブネット( 192.168.24.0/24 )しか登録していませんでした。そのため、OpenVPN 経由で到達するパケット( 192.168.66.0/24 )は家庭内 LAN からのものではなく、外部からのものだと認識していました。OpenVPN によって家庭内 LAN に接続している 192.168.66.0/24 のサブネットも同様に家庭内の LAN だと認識するように設定を見直しました。

設定は sip.conf で行います。localnet= の項目がそれで、ここに現在の 192.168.24.0/24 の他に OpenVPN で使用する仮想 LAN の 192.168.66.0/24 のサブネットも追加します。これで OpenVPN 経由で届いてきたパケットは家庭内 LAN のものだと認識して、自分自身の IP アドレスとしてグローバル・アドレスを通知するのではなく、家庭内 LAN の IP アドレスを通知するようになります。

localnet=192.168.24.0/24
localnet=192.168.66.0/24  <単純に追加するだけです

設定が終了したところで Asterisk サーバを再起動させて OpenVPN 経由で通話テストを行なってみました。今回行った私の環境ではこれだけで通話ができるようになりました。

[問題発生時のヒント?]

もしダイヤル開始から通話、終話まで正常終了しない場合には、ソフトフォン(Ekiga Phone)の次の点を見直してみてください。

ソフトフォンの Ekiga Phone の設定ですが、ここも外部で使用しているノートパソコンの IP アドレス(どこかの LAN の IP か、グローバル・アドレス)が、そのままソフトフォンの IP アドレスになっています。

Ekiga Phone の場合、外部のプロキシサーバを登録することができるようになっています。ここへ OpenVPN の Asterisk サーバ側の出口の IP アドレス(我が家の場合 192.168.66.1 )を指定すると、Ekiga Phone からのパケットが OpenVPN を経由して Asterisk サーバと行き来するようです。
メニュー > [編集] > [設定] > [プロトコル] > [SIP の設定] の中の [外部のプロキシ] の欄です。
これは、たまたま検証途中で発見したものです。上記の Asterisk サーバの設定見直しだけで上手く動作しないときには試してみてください。

2014年8月5日火曜日

FreeBSD の自宅サーバへ OpenVPN をインストール(ルーティング方式)

DD-WRT 上の OpenVPN で VPN 環境を試験的に構築してみましたが、なかなか使い勝手もよく、恒常的に環境を維持しておきたいと思いました。そこでビルドが 2010 年ごろの DD-WRT の OpenVPN を使い続けるのはセキュリティ上問題もあると考えて、最新のバージョンを FreeBSD で構築している自宅サーバへインストールすることとしました。OpenVPN の接続形式は、ルーティング( Routing )方式を採用しました。

参考にしたウェブサイは次のものです。大切な情報ありがとうございます。

FreeBSD OpenVPN Server/Routed
https://www.secure-computing.net/wiki/index.php/FreeBSD_OpenVPN_Server/Routed

OpenVPN with FreeBSD 6.x 7.x
http://www.isgsp.net/freebsd/freebsd-openvpn.html
[自分用メモ] FreeBSDマシンにOpenVPNをインストールしてVPNサーバを構築した ~ サーバ設定編
http://ultrah.zura.org/?p=3510

OpenVPN のインストール

インストールそのものは、いつもの portupgrade で行いました。
# cd /usr/ports
# portupgrade -N security/openvpn
OpenVPN のビルド設定画面

以下の二つの ports が依存関係で自動的にインストールされました。
  • security/easy-rsa
  • archivers/lzo2

久々に ports によるインストール後に設定ファイルを置くディレクトリを作るなど、昔ながらの FreeBSD 流儀?の ports に驚かされたというか?喜びの声(笑)を挙げました。

設定ファイルの作成

どうも世間一般には /usr/local/etc/openvpn のディレクトリを作って、ここに設定ファイルを設置するのが主流のようです。FreeBSD の自由度の高さを謳うことよりも、もうここまで ports でやってもらって構わないのですが・・・。
# mkdir /usr/local/etc/openvpn

ここへ openvpn の設定ファイルをサンプルからコピーして設置します。参考にしたウェブサイトとは ports が新しいためかサンプルのディレクトリが異なっていました。
# cp /usr/local/share/examples/openvpn/sample-config-files/server.conf /usr/local/etc/openvpn/openvpn.conf

設定ファイルの編集は DD-WRT の時のものを参考にしました。事前に openvpn を設定していると、このような設定ファイルを操作するのも楽勝です。以下は設定事例です。

------------ openvpn.conf --------------
port 1194
proto udp
dev tun

ca   /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key  /usr/local/etc/openvpn/keys/server.key
dh   /usr/local/etc/openvpn/keys/dh1024.pem

server 192.168.66.0 255.255.255.0

keepalive 10 120
# client-to-client
comp-lzo

# user nobody
# group nobody

persist-key
persist-tun

status      /var/openvpn/openvpn-status.log
log-append  /var/log/openvpn.log
verb 4

push "route 192.168.24.0 255.255.255.0"
push "redirect-gateway def1"
push "dhcp-option DNS 192.168.24.100"
push "dhcp-option DOMAIN example.com"
------------ openvpn.conf --------------
ここで設定ファイル(openvpn.conf)に記述した動作状況ファイル(openvpn-status.log)のためのディレクトリを作成しておきます。
# mkdir /var/openvpn
なおログファイル(openvpn.log)は、一般的なログファイルを保存する /var/log に指定してあります。

ついでにログファイルは過去のデータをどんどん蓄積してしまうので、適当なところでログ・ローテーションをしてもらうように /etc/newsyslog.conf に登録しておきます。以下の一行を最後尾へ追加しました。

/var/log/openvpn.log     600  7     100  *     JC


証明書の作成

easy-rsa の雛形があるディレクトリへ移動して作業をします。必要であれば作業ディレクトリの内容を作業前にコピーして保管しておくことをお奨めします。
# cd /usr/local/share/easy-rsa

ここで設定ファイルの vars を編集します。これは上記の参考ウェブサイトを参照しながら編集しました。
# ee vars

一連のビルド作業では FreeBSD で一般に使用されている tcsh シェルでは動作しないため sh シェルで操作します。
# sh
# . ./vars
# . ./clean-all
# . ./build-ca

サーバ鍵の作成
# ./build-key-server server
# ./build-dh

クライアント鍵
# ./build-key client1

作業が終了したら sh シェルから抜けます。
# exit

作成された証明書や鍵などは /usr/local/share/easy-rsa/keys へ保存されています。この keys ディレクトリを openvpn の設定ファイルディレクトリへコピーします。
#  cp -Rp /usr/local/share/easy-rsa/keys /usr/local/etc/openvpn/.


起動ファイルの設定

サーバ起動時に openvpn も自動で起動するように /etc/rc.conf へ設定を追加します。
# ee /etc/rc.conf

以下の三行を追加しました。
# OpenVPN Server
openvpn_enable="YES"
openvpn_configfile="/usr/local/etc/openvpn/openvpn.conf"
gateway_enable="YES"

以上でインストールは終了です。手動で openvpn を起動させてみます。
# /usr/local/etc/rc.d/openvpn start
なお停止の時には stop 、設定ファイル変更で再起動の時には restart で操作します。

これでログファイル(/var/log/openvpn.log)や動作状態ファイル(/var/openvpn/openvpn-status.log)の様子を観察して問題点を洗い出します。



関連して修正(DNS の見直し)

今回 DD-WRT の時から気になっていた 名前の解決 が上手く動作しないことがある点を見直しました。

この OpenVPN をインストールしたサーバには DNS の動作をする BIND9 がシステムに元々組み込まれています。この BIND9 を利用して、家庭内 LAN 内のドメインの名前の解決を行なっています。この家庭内 LAN の独自のドメイン名の名前の解決が出来ない場合がありました。原因が BIND9 の設定ファイル(/etc/namedb/named.conf)にありました。

最近何かと話題となっている DNS アンプ攻撃にも関連する項目も修正が加わるだけに、注意をしながら設定を変更しました。具体的には named.conf の option の以下の二点を変更しました。


  • allow-recursion の項目追加
allow-recursion { 127.0.0.1; 192.168.24.0/24; 192.168.66.0/24; };
  • listen-on の修正
listen-on       { 127.0.0.1; 192.168.24.0/24; 192.168.66.0/24; };
OpenVPN で使用する仮想 LAN の部分のアドレス領域を追加しました。

以上で OpenVPN 経由でも名前の解決が正常に行えるようになりました。

FreeBSD php5, mysql55 アップデート

FreeBSD の ports へ php5-5.4.31 , mysql55-5.5.39 へのアップデートが到着していました。

いつものように portupgrade で更新をしておきました。

我が家では動作上の問題は発生していません。

2014年8月4日月曜日

Debian Wheezy の Icedove がアップデート

Debian Wheezy の Icedove ( Thunderbird ) にアップデートが到着しました。

これで Icedove 24.6 から 24.7 へ更新しました。Ubuntu のように 31.0 へのアップグレードではありませんでした。

Debian は、なかなか歩みが遅いようで Ubuntu のように積極的なアップグレードを行わないようです。まあ、このアップグレードが遅いのは昨日今日のことではないので、よく承知していることではあります(笑)。この堅実性が Debian の良さなのかもしれません。

2014年8月3日日曜日

DD-WRT で OpenVPN サーバを設定

諸事情があり、自宅外からの自宅内 LAN へのアクセスが必要となりました。そこで DD-WRT の VPN ビルドを行ったファームウェアをインストールした無線 LAN ルータ(Linksys WRT150N)を用意して設定してみました。

参考にしたウェブサイトは次のものです。大切な情報ありがとうございます。
VPN (the easy way) v24+ (英語)
http://www.dd-wrt.com/wiki/index.php/VPN_%28the_easy_way%29_v24%2B

DD-WRTで遊んでみる -OpenVPNでリモートアクセスルータにする(日本語)
http://linuxandxx.blog.fc2.com/blog-entry-47.html

サーバの証明書の作成方法は上記の参考ウェブサイトの方法で問題なく作成することができました。

OpenVPN には二種類のアクセス方法があります。ルーティング方式(Routing)とブリッジ方式(Bridging)ですが、ルーティング方式が設定が容易であると説明がありました。しかし私は OpenVPN サーバの家庭内 LAN の設置場所の関係で簡単に設置することができませんでした。なお OpenVPN サーバを設置した無線 LAN ルータが外部のインターネットへ接続を行うような設置方法であれば問題なく動作します。

ルーティング方式で動作する配置
[インターネット]
   │
[無線 LAN ルータ](OpenVPN サーバ)
   │
[家庭内サーバ類](ウェブサーバ、メールサーバ)

意外なことにブリッジ方式の方が最初に成功しました。これは上記の参考ウェブサイトどおりで問題ありませんでした。注意点としては外部からアクセスするマシンのクライアント設定においてデバイスとして tun ではなく tap を使用するように設定するだけでした。

さて我が家での家庭内 LAN の配置です。DD-WRT をインストールしてある無線 LAN ルータは WAN 端子を無効(disable)として無線 LAN アクセスポイントとして使用しています。

我が家の配置
[インターネット]
   │
   │ドメイン名 : example.com
   │
[NTT西 フレッツ光 HGW](PR-400NE)
   │(192.168.24.1)
   │
   ーーーーーーーーーーーーーーー
   │             │
[無線LANルータ](OpenVPN)   [家庭内サーバ]
 (192.168.24.8)        (192.168.24.100)
-- 家庭内サーバは DNS, DHCP, WEB, MAIL, Asterisk を管理 --

我が家の配置でのルーティング方式での DD-WRT の OpenVPN の設定です。

ここも上記の参考ウェブサイトを参考に行いましたが、一部変更をしています。

[OpenVPN Daemon] - [OpenVPN Config] の設定の push の項目の定義を見直しました。DNS サーバの設定を家庭内サーバ(192.168.24.100)へ振り向けて、さらにドメイン名(example.com)もクライアントのマシンへ登録させるようにしました。この push 設定でクライアント・マシンの resolv.conf へも自動的に登録されていました。
push "route 192.168.24.0 255.255.255.0"
push "dhcp-option DNS 192.168.24.100"
push "dhcp-option DOMAIN example.com"
server 192.168.66.0 255.255.255.0

dev tun0
proto udp
keepalive 10 120
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem

# Only use crl-verify if you are using the revoke list - otherwise leave it commented out
# crl-verify /tmp/openvpn/ca.crl

# management parameter allows DD-WRT's OpenVPN Status web page to access the server's management port
# port must be 5001 for scripts embedded in firmware to work
management localhost 5001
OpenVPN の設定画面

無線 LAN ルータのパケットフィルタの設定も上記の参考ウェブサイトどおりに設定しました。[Administration] - [Commands] へ以下の二行を [Save Firewall] で設定するだけです。
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
iptables -I FORWARD 1 -s 192.168.66.0/24 -j ACCEPT

Firewall 設定
下部二行は # でコメントアウトしています。

この後、外部のインターネットから OpenVPN のパケット(UDP : 1194)が OpenVPN サーバとなっている無線 LAN ルータ(192.168.24.8)へ向かうように [静的 IP マスカレード設定] と [IPv4 パケットフィルタ設定] を行います。

[詳細設定]-[静的 IP マスカレード設定]
[詳細設定]-[静的 IP マスカレード設定]-[エントリ編集]
[詳細設定]-[IPv4 パケットフィルタ設定]-[エントリ編集]
[詳細設定]-[IPv4 パケットフィルタ設定]

この状態で外部のクライアント・マシンからアクセスすると、OpenVPN 接続できましたが家庭内 LAN のサーバへアクセスすることができませんでした。ping も通りません。

OpenVPN のステータス画面では正常に接続されていることになっています。

最初は無線 LAN ルータの DD-WRT のルーティング設定の見直しを盛んに行なってみましたが、アクセスすることができませんでした。

ネット上で「 LAN 内に OpenVPN サーバを設置している」事例を探して、何か参考になる情報を探索してみました。

すると意外なことに家庭内 LAN のルータ HGW(PR-400NE)のルーティング設定に問題があることが判明しました。 OpenVPN の仮想 LAN である 192.168.66.0/24 のパケットを HGW(PR-400NE)でルーティングの設定しなければなりませんでした。意外な盲点でした(汗)。

HGW(PR-400NE)の設定画面の [詳細設定] - [静的ルーティング設定] で OpenVPN のパケット(192.168.66.0/24)を OpenVPN のゲートウェイとなる無線 LAN ルータ(192.168.24.8)へルーティングするように設定しました。詳しくは、設定画面の画像を参考にしてください。

[詳細設定]-[静的ルーティング設定]
[詳細設定]-[静的ルーティング設定]-[エントリ編集]

この状態で再度クライアント・マシンから接続し直すと、ちゃんと家庭内サーバへアクセスすることができるようになりました。