Synology製NASのデータ復旧(サルベージ)

引き続き、Synology DS213jネタです。

SynologyNASに入れているHDDはLinux等にマウントしてデータを取り出すことができるの?

本番導入にあたり、気になるのが本体故障時にもデータを取り出すことができるか。
私の中ではこれは重要です。
「後継機、同等機にそのままディスク突っ込めば大丈夫です!」っていわれても、いやいや、そうじゃない。
その時にそういう機種があるか、経済的に買えるか(笑)などの事情を考えるとやはり一般的な環境でデータを吸い出せる事がとても大切です。
理想は、HDDケースなどでPCに接続したら普通に読み出せることですね。
※ちなみに、Intelの"ラピッドストレージテクノロジ"の場合できます。

まぁ、買った後にできなかったらどうするのって?さすがに買う前にちょっとは調べてます。ただ、Synologyはあまり日本語でも情報がなかったのでいささか不安ではありましたが。(※後日日本語のものも見つけました。記事いちばん下。)
サルベージだと勝手に思っていましたが、英語だと「retrieve」とか「recover」みたいです。このキーワードにたどり着くまでに時間かかったww

参考にしたサイト
 ・How can I recover data from my DiskStation using a PC?
 ・How to retrieve data from RAID Volumes on Linux


どうやら、Linuxでごにょごにょやると、データを取り出すことができるようです。

Ubuntu12.04LTSで試したので、一応メモしておきます。
手順に従って、LiveCDで試しました。





1.NASから取り出したHDDをすべてPCに接続する


SATAポートがいっぱいあるPCを用意しなくても、SATA⇔USB変換ケーブルや、SATA対応HDDケースなどがあればOK。



2.LiveCDでUbuntu12.04を起動


Ubuntuを試すをクリックすればOK。(省略)



3.必要ソフトのインストール


Ubuntuでコンソール(Ctrl+Alt+T)を起動し、以下のソフトをインストール

 ① sudo apt-get update
 ② sudo apt-get install mdadm
 ③ sudo apt-get install lvm2

②のmdadmインストール時に、メールサーバの設定が聞かれますので、「設定なし」を選びます。

salv1.png

salv2.png



4.RAIDボリュームのマウント

コンソールからrootになって、下記コマンドを実施。
$sudo -i
#mdadm -Asf && vgchange -ay
mdadm: /dev/md/Abu:2_0 has been started with 1 drive (out of 2).
Found duplicate PV zO4gGtnsKPwZ7QWLnstGLgELkgLnVfyW: using /dev/md127 not /dev/md126
1 logical volume(s) in volume group "vg1000" now active


こんな感じのメッセージが出てくる。
うまく行かない場合は、HDDを一度接続しなおしたらうまく行った。



5.ディレクトリの確認


ここまでうまく行くと、ファイルマネージャで開くと左側に、RAIDボリュームが表示される。
これを開くと、通常のディレクトリと同じに扱えるのでここからデータを吸い出す事が可能です!

salv3.png



ちなみに、手順ではすべてのディスクを接続しなさいと書いて有りますが、HDD2台でのSHR(SynologyHybridRaid)の場合1台でもマウントできました
※試してないですがRAID1でも同じだと思います。


とりあえず、懸念事項のハード故障時のデータサルベージ、復旧が可能であることがわかって一安心。
まぁ、ここでダメだったとしてもいまさらどうするんだ、って話ですがww



次は、ディスクを大きくした時の動作を確認したいと思います。



続きを読む

NAS購入 -Synology DS213j買っちゃいました-

Synology DS213jを購入!


ついに本格的?NASを買ってしまいました。

今まで、古いCorei7で組んだ自作PCに、IntelのラピッドストレージテクノロジでRAID1を組んでいましたが、
・ 普段いない寝室にPCが置いてある
・ 消費電力が大きくかつ爆音PCの為、常時稼働が困難
というため、データアクセスのためにはいちいち寝室に行ってPCを起動する必要がありました。

なので、RaspberryPiにUSB-HDDを接続してPCのデータをRaspberryPiのHDDにミラーして通常時はそちらを参照しに行くという運用をしていました。
しかし、データが複数分散されるうえにコピーに時間がかかるなどが少し気になっていました。
NASは以前から気になっていたのですが、QnapやNetgeerなどのNASが有名でしたが、私にはちょっと高価で少し躊躇していました。
そんな折、synologyというメーカのNASを見つけて調べているうちに興味が出てきました。
台湾のメーカーらしく、割と後発らしいですが調べるとソフトウェアにいろいろ力を入れているとか、いないとかw

オフィシャルサイト
製品サイト


必要機能・選定のポイントは以下

保護するべきデータ
写真、ビデオ、音楽データ、動画データなどありますがお金を出せば手に入るデータは最悪あきらめてもよいが、写真・ビデオ(ホームビデオ)のデータはまもる。

必須機能

・ RAID1ないしはそれ相当のRAIDシステムが構築可能
・ RAIDケースが故障した際にもデータの取り出し(サルベージ)が可能であること
・ 将来的にディスクを拡張してサイズを大きくできる事(現在1TのRAID1)
・ 省電力であること
・ 十分静かであること

改めて書くと要件すくなっ!(Buffaloとかでもいいんじゃね?)


選定のポイント

・ メディアサーバの機能を有する事
・ Androidや、iOSからも参照・操作できること
・ AirPlayやDLNAでの外部装置への再生等が可能
・ HDDが最低2台搭載可能
・ 経済事情にあった価格であること

AirPlayやDLNAへの出力とそのコントロールをAndroidやiOSから操作できるという機能に惹かれました。
そのほかにも使う、使わないはともかくとしていろいろな機能があります。(他メーカーとそんなに比較してないwwwww)


現在、自宅でRaspberryPiのHDDに入っている音楽データや動画を再生する際には、Raspbmcで再生する形になっています。
以前の投稿で入手したUSB-DACで外部スピーカーに接続しています。(現在はHDMIでTVのスピーカーから出力していますが。)いずれにしてもリビングで音楽を手軽に聞くには楽なのですが、寝室などで奥さんが子供に音楽を聞かせたいという用途にはすごく不向きでした。

そ・こ・で、AirPlay対応のスピーカーに目を付けました。で、このスピーカーにAirPlay出力が可能であるこの機能に着目したわけです。
これが決め手になりました。(まぁ、この機能は他メーカーも持っているわけですがww)



最終的に次の二つですごく悩みました。
① DS213j
② DS213+
私的に気になった違いは、前面にあるUSBポートと、ホットスワップ対応か否か。(ほかにもありますが詳しくはオフィシャルサイト見て。)
あと、価格www

でホットスワップは特に惹かれたのですが、別に家庭内だしHDD交換の時は止めても問題ないだろうという判断。
前面にあるUSBポートは、ボタン一つでSDカード等をバックアップ取れる機能に最後まで悩みましたが、自分でフォルダ整理したいしという負け惜しみと価格に負けてDS213jにしました。
吉と出るか凶と出るか。

正直、書き込み/読み込み速度徒かはそれほど興味がないので調べませんwww。興味ある人はこの辺でも見ればいいんじゃない?(適当)

というわけで、我が家(にとって)の重要データはSynologyへ全て任せることにしました。
10年、いや、5年くらいは頑張って利用していければと思います。まぁ、壊れなくても新しい機能に惹かれちゃうんでしょうけど。

写真のレビューとかはしませんが、興味がある人は「ASCII.jp DS212j」で検索して出てくる記事の写真とほとんど変わりませんので、そちらを参考にしてはいかがでしょう?(オイw)


しばらく、稼働までの間いくつかテストをしてから、データの移行を行おうと思います。

OpenVPNが繋がらない!

前回前々回でリモートから自宅に接続するためのVPN環境に挑戦してきました。

参考にしている人がいるかは不明ですが、マネしたけどうまくいかないという方、OpenVPNでリモートクライアントからVPN接続できないという方。
もしかしたら参考になるかもしれません。


DD-WRTで設定したOpenVPNはUDPの1194番を利用してVPNセッションの接続を試みます。
「クライアントが、パケットフィルタを実施しているNATルータの配下にいる環境」の場合、ルータで外部→内部向けのUDP/1194を通過するようにフィルタが設定されていないとVPNのセッションを確立できません。これは、大雑把にいうとUDPはセッション確立という概念がないため、パケットフィルタ機能だけでの制御は結構困難なためです。(頑張ればできます)

そこで、セッション確立という概念があるTCPを利用することでこれを回避できるケースがあります。
一般的に、ユーザがインターネットに使うネットワーク環境では内部から外部向けのTCPセッションの戻りは許可する設定になっていることが多いです。これをうまく使います。
※インターネットでWebが見られる環境なら、ほぼ大丈夫なはず。(管理者の設定にもよるため確実とは言えませんが)
逆にWebすらも制限されているようなネットワークでは結構絶望的な気がします(笑)
・外部から内部向けでTCPのAckフラグが設定されているパケットも拒否するフィルタ
 (いわゆる、内部から外部向けのTCPセッション確立を認めないフィルタ)



--多少細かい説明--
UDPはホスト間(この場合クライアントとOpenVPNサーバ)で事前のセッションの確立を行いません。
一般的なFirewall(家庭用ブロードバンドルータでも対応しているものはある)であれば、ステートフルインスペクション機能によりUDPの戻りもFirewallが動的に許可しますが、対応していないNATルータでパケットフィルタによって制御しているようなネットワーク環境にいる場合は制限が出てきます。
UDPの戻りパケットを明示的に許可してあげないといけないですが、たくさんあるUDPポートを開けてることは少ないので場合によってはネットワーク管理者に依頼して変更してもらう必要があります。



というわけで、OpenVPNサーバとのセッション確立にTCP/1194を利用することにより回避する方法です。


■■ テスト環境 ■■
・OpenVPNサーバ機器:Buffalo WHR-HP-G54 
・OpenVPNソフトウェア:DD-WRT(v2-sp vpn) with OpenVPN
・OpenVPNクライアント:Ubuntu12.04


■■ 前提 ■■
・DD-WRTへOpenVPNで接続できる環境ができていること。
できてない場合はこちらを参考にしてみてください。





1.DD-WRT側のOpenVPNサーバ設定


・Webブラウザで、ルータの管理画面にアクセスします。
・[ネットワーク > PPTPサーバ/クライアント]の順にメニューをたどる。
・OpenVPNデーモンの中の、「OpenVPN Config」の設定を変更します。

push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 192.168.66.1"
server 192.168.66.0 255.255.255.0

dev tun0
proto tcp ←udpをtcpに変更する。

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




2.DD-WRT側のフィルタ設定


DD-WRTのWeb画面で「管理->コマンド実行」の順にたどり、実行コマンドに以下を張り付け
※ここも自分の環境と合わせてください。


iptables -I INPUT 1 -p tcp --dport 1194 -j ACCEPT
iptables -I FORWARD 1 --source 192.168.66.0/24 -j ACCEPT
# These next two lines may or may not be necessary.
# I (dereks) did not need them, but bmatthewshea did.
# Thus, we include them so that this works for more people:
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT



3.クライアントPC側の設定

OpenVPNクライアント側の"client.conf"を設定してあげます。
私は、"~.openvpn"配下に配置しているので、これを編集します。編集箇所は、

remote 192.168.100.253 1194

client
remote-cert-tls server
dev tun0
proto tcp

resolv-retry infinite
nobind
persist-key
persist-tun
float
;comp-lzo

#If the pushed routes appear not to be added on windows hosts, add the following:
route-delay 30

ca /etc/openvpn/ca.crt
cert /etc/openvpn/client1.crt
key /etc/openvpn/client1.key




4.サーバの確認(DD-WRT(OpenVPN))

サーバでのサービスポートを確認します。
ルータにSSHでログイン等を行なって、以下のコマンドを実行。
Port1194がTCPで待ち受けていることを確認する。

root@DD-WRT:~# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:5001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:1194 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN
tcp 0 0 192.168.100.1:22 192.168.100.131:53031 ESTABLISHED
tcp 0 0 192.168.123.253:1194 157.82.12.10:7474 ESTABLISHED
udp 0 0 0.0.0.0:53 0.0.0.0:*
udp 0 0 0.0.0.0:67 0.0.0.0:*
raw 0 0 0.0.0.0:255 0.0.0.0:* 255
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ] DGRAM 3745920




5.接続確認

クライアントで接続してみます。ターミナルから実行。

$ sudo openvpn client.conf 
Thu May 23 09:54:15 2013 OpenVPN 2.2.1 i486-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Mar 23 2012
Thu May 23 09:54:15 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu May 23 09:54:15 2013 Control Channel MTU parms [ L:1543 D:140 EF:40 EB:0 ET:0 EL:0 ]
Thu May 23 09:54:15 2013 Socket Buffers: R=[87380->131072] S=[16384->131072]
Thu May 23 09:54:15 2013 Data Channel MTU parms [ L:1543 D:1450 EF:43 EB:4 ET:0 EL:0 ]
Thu May 23 09:54:15 2013 Local Options hash (VER=V4): 'db02a8f8'
Thu May 23 09:54:15 2013 Expected Remote Options hash (VER=V4): '7e068940'
Thu May 23 09:54:15 2013 Attempting to establish TCP connection with [AF_INET]x.x.x.x:1194 [nonblock]
Thu May 23 09:54:16 2013 TCP connection established with [AF_INET]x.x.x.x:1194
Thu May 23 09:54:16 2013 TCPv4_CLIENT link local: [undef]
(中略)
Thu May 23 09:54:19 2013 Initialization Sequence Completed

TCPでのトンネルが確立しました。


念の為、クライアントでインタフェースを確認。
$ sudo ifconfig
(略)
tun0 Link encap:不明なネット ハードウェアアドレス 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inetアドレス:192.168.66.6 P-t-P:192.168.66.5 マスク:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 メトリック:1
RXパケット:0 エラー:0 損失:0 オーバラン:0 フレーム:0
TXパケット:0 エラー:0 損失:0 オーバラン:0 キャリア:0
衝突(Collisions):0 TXキュー長:100
RXバイト:0 (0.0 B) TXバイト:0 (0.0 B)

となっており、ちゃんとトンネルI/Fが表示される。
引き続き、クライアントのルーティングの確認を行う。
$ netstat -rn
カーネルIP経路テーブル
受信先サイト ゲートウェイ ネットマスク フラグ MSS Window irtt インタフェース
0.0.0.0 10.82.12.254 0.0.0.0 UG 0 0 0 wlan1
10.82.12.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan1
192.168.66.1 192.168.66.5 255.255.255.255 UGH 0 0 0 tun0
192.168.66.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 192.168.66.5 255.255.255.0 UG 0 0 0 tun0

接続先のネットワークの転送先がtun0に向いていることを確認する。

以上で完了。



これで、UDPのフィルタが開いていない環境からのOpenVPN接続の確率が可能となります。
うまく行かないかたは、ぜひTCPを試してください。
ちなみに、TCPにすると多少遅くなるとのことなので可能であればDefaultのUDPを推奨します。

※ 実環境でのログから記事のためにちょっとアドレスを変えたりしていますので、細かい間違いは無視してください。必要な箇所は、各項目でTCPに変更する箇所です(赤字)。

Windows7でIPv6のPingでハマったお話

IPv6のPingでハマった。ゾーンIDとは何ぞや?

※2014/7/7 誤記訂正

IPv6リンクローカル環境で単純なPing疎通確認を行おうとしてハマったのでメモしておく。

先に結論だけ言うと
Pingコマンドで指定するゾーンIDは相手のゾーンIDじゃないよ!



●テスト環境
 使用環境 : Windows7、IPv6
 実施コマンド : リンクローカルアドレスを利用したPing(icmp)

●前提のお話
 WindowsでIPv6のアドレスを調べるためには、コマンドプロンプトで"ipconfig"コマンドを実施する。
 IPv6がEnableになっていれば、例えば

  「 リンクローカル IPv6 アドレス. . . . : fe80::4c79:a7b6:c81:aaaa%10 」(適当なアドレスです)

 のようなIPv6のアドレスが表示される。
 ちなみにリンクローカルアドレスが何ぞやに関しては調べて。
 簡単に言うとIPv4プライベートIPみたいなもので、これだけではセグメントは越えられない。


 Windows7では、IPv4,IPv6いずれのicmpも今まで通りの"ping"コマンドで可能。


で、このPingでハマった・・・。



●テスト
 PC1(Ping送信元)、PC2(Ping送信先)という2台で通信を試みた。

 構成概要↓
Pingテスト構成


 それぞれのPCのipconfigの結果(IPv6アドレス部分のみ)
 ローカールエリア接続は有線NICで、ワイヤレスネットワーク接続は無線NICです。

 PC1
  イーサネット アダプター ローカル エリア接続:
    リンクローカル IPv6 アドレス. . . . : fe80::6930:3aee:55ef:aaaa%10
 
  Wireless LAN adapter ワイヤレス ネットワーク接続:
    リンクローカル IPv6 アドレス. . . . : fe80::6930:3aee:55ef:bbbb%11


 PC2
  イーサネット アダプター ローカル エリア接続:
    リンクローカル IPv6 アドレス. . . . : fe80::6930:3aee:55ef:cccc%10 




で、PC1で有線接続状態からPC2のIPv6アドレスにPingを実施。
ping fe80::6930:3aee:55ef:cccc%10
   → OK (Ping応答が返ってくる)

つぎに、PC1を無線接続に変更して同様にPC2のIPv6アドレスにPing実施。
ping fe80::6930:3aee:55ef:cccc%10
   → NG (Ping応答が返ってこない。具体的には「宛先ホストに到達できません」となり失敗。)

結果としてこれは認識が間違えていた。

結論言うと、Pingで指定するゾーンIDは相手のアドレスコピペしちゃだめだよ!





ipconfigで表示される

"fe80::6930:3aee:55ef:aaaa%10"

の"fe80::6930:3aee:55ef:aaaa"部位はもちろん当該NICに割りあたっているIPv6アドレスを表わすが
その後ろの"%10"が何を意味するか。
これはゾーンID(zone_ID)というものらしい。


ローカル使用 IPv6 アドレスのゾーン ID

 ゾーンIDを利用することにより、リンクやサイトを見分けるということが目的らしい。
 ローカル使用アドレス(リンクローカル、サイトローカル:廃止)に関連付けられたゾーンは

   Address%zone_ID

 で表されるとのことらしい。

 ここが重要で、つまりグローバルアドレスの場合はこれはつかない(はず。試せてません。)
 このゾーンIDはそれぞれの端末が一意に持ち、同じリンクに接続されているからと言ってすべての端末が
 同じになるわけではないらしい。PC1のゾーンIDが1だとしても、PC2のゾーンIDが1とは限らない。



で、何がいけないかというとこのゾーンIDは自分(送信元ホスト)が認識するゾーンID(インタフェース)だということ。
正確に言うと、Pingで指定するゾーンIDは自分の出力インタフェース(ゾーンID)を指定するということ!


簡単なpingコマンドは、”ping 宛先IP”というコマンドになるが、上でやったpingコマンドは宛先ホストのゾーンIDを指定していた。
ping fe80::6930:3aee:55ef:cccc%10

この%10は、たまたま自分の有線インタフェースで表示されるゾーン"10"と一致していたため有線では応答がありゾーンIDが"11"となっていた無線インタフェースでは応答されなかった。おそらく、送信I/Fが異なっていたからそもそも出力されていなかったはず。


次のようにするとうまくいった。
 
 有線接続状態
  ping fe80::6930:3aee:55ef:cccc%10
    → OK

 無線接続状態
   ping fe80::6930:3aee:55ef:cccc%11
    → OK


偶然にも有線の時のゾーンIDが一致していたので混乱した。



●まとめ?

リンクローカルアドレスは「fe80」で始まるため、これがPCに複数あるとどのI/Fから送信していいのか判断できない。そのためにゾーンIDを指定する必要がある。(と解釈した。間違ってたらごめんなさい)

ちなみに、リンクしているI/Fが一つの時はゾーンIDを指定しなくてもうまくいった。
このことは、複数のI/Fをリンクさせて複数のリンクローカルアドレス(fe80)を持たせた状態でのPingは失敗したことからも上の推測は正しいと思う。


なお、Linux(Ubuntu)、MacOSXでのIPv6Pingコマンドは以下のようになります。
 
 ping6 -i インタフェース名 宛先アドレス
  (例: ping6 -i eth0 fe80::6930:3aee:55ef:cccc)

このインタフェース名がWindowsでいうゾーンIDに相当する。こっちのほうがいかにも送信I/Fを指定しているようで感覚的にわかりやすい気がする。

Windwosの場合、ipconfigでゾーンIDが表示され、PingでゾーンIDを指定するのが混乱させる。
(こんなことでハマるのは、自分だけか・・・)



間違いあったらご指摘ください。

DD-WRTで遊んでみる その2 -省電力OpenVPNサーバに仕立てる-

引き続きDD-WRTで遊んでみます。
今回は「DD-WRT with OpenVPNをNATの中で利用する(=OpenVPNサーバをNATの中で利用する)」です。


前回、DD-WRTにOpenVPNサーバを設定することによってVPNによるセキュアなリモートアクセスルータのような利用方法ができるようになりました。これで外部から自宅にアクセスできる環境が出来上がりました。

が・・・、うちではちょっと悩ましいです。というのは、今回改造したルータの無線機能は802.11g対応で54M(理論値)しか出ません。現役で動いているBuffaloのルータは802.11nに対応しており300M(理論値)まで対応しています。なので、単純にリプレースすると速度が低下する・・・。
じゃあ、現役ルータはDD-WRT化すればいいじゃん!と思ったら対応していない。むぅ・・・
安い中古買うか?とも真剣に悩んだが、802.11acのドラフト対応製品も市場に出てきてるタイミングにどうなの・・?

というわけで、DD-WRTをリモートアクセスルータとするのではなく単純な省電力OpenVPNサーバにしてみます。
そして、これをBaffaloのルータのLANを側に配置します。
つまりこういう構成ですね。

ddwrt-vpnsv-testfig.png



DD-WRT(+OpenVPN)でリモートサーバとする場合、クライアントの通信はグローバル側にVPNを貼り、その通信をLAN側のプライベートインタフェースに転送するような前回の構成がノーマル?(笑)な使い方だと思います。


今回は、LAN側に設置するのでブロードバンドルータで言うと、WAN側I/Fに自宅のプライベートIPが割当たる構成になります。通常構成だとこの下に更に別のプライベートアドレスを作る構成になると思いますが、細かい説明は省きますが、複雑、既存への影響、無線PCとの通信などでのデメリットもあると思い今回はボツ。
ddwrt-vpn2.png


またOpenVPNにはL2VPNのようなブリッジングモードも構成可能らしいのですが、ブロードキャスト等もすべて通過してしまうので今回はやめました。この場合は、リモート端末が自宅LANと同じスイッチにつながるイメージになります。


今回のポイントとしては
 ・OpenVPNサーバをNAT(マスカレード)配下に配置
 ・外部からOpenVPNサーバにアクセスした後に、自宅LANに接続
  つまりルータの入ったI/Fから暗号化解除されて再び出てくる感じ
という形になると思います。通信を図にするとこんな感じ。
ddwrt-vpn-routefig.png

さて、前置きが長くなりましたが概念がわかれば、やることは簡単です。

■■ 環境 ■■
・OpenVPNサーバ機器:Buffalo WHR-HP-G54 
・OpenVPNソフトウェア:DD-WRT(v2-sp vpn) with OpenVPN
・OpenVPNクライアント:Ubuntu12.04

■■ 前提 ■■
前回の作業までが完了しており、DD-WRTへOpenVPNで接続できる環境ができていること。
できてない場合は前回も参考にしてください。
 





※ルータの設定は、LAN側にPCを接続し行なっています。


1.DD-WRTの設定1

・Webブラウザで、ルータの管理画面にアクセスします。
・[基本]タブを開きます。
・インターネット接続のIPアドレスを自宅のプライベートIPを割り当てます。
 今回は前回LAN側に利用していたセグメントをWAN側インタフェースに設定します。
 LAN側に前回のままだと192.168.1.1が設定されていると思うので、念のため違うアドレスにします。
 下の例では、WAN側を192.168.1.253、LAN側を192.168.100.1にしました。
OpenVPN-ifconfig.png


2.DD-WRTの設定2

・Webブラウザで、ルータの管理画面にアクセスします。
・[ネットワーク > PPTPサーバ/クライアント]の順にメニューをたどる。
・OpenVPNデーモンの中の、「OpenVPN Config」の設定を変更します。

前回の設定が終わって入れば

push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 192.168.66.1"
server 192.168.66.0 255.255.255.0
(略)

となっているはずです。

この内一番最初の行が
push "route 192.168.1.0 255.255.255.0"

となっている事を確認してください。
この行の意味は、OpneVPNクライアントが接続してきた際に、ルータが転送できるネットワークの情報をクライアントに教える内容になります。今回は、これがいわゆるWANインタフェースのプライベートIPセグメントの情報を渡してあげれば良いのです。
もしWAN側(自宅LAN)が192.168.100.0/24なら)この行を
push "route 192.168.100.0 255.255.255.0"
としてあげます。


3.NATルータの設定

このプライベート側に設置したOpenVPNサーバに直接インターネットからアクセスすることは当然できません。
これを解決してあげるためには、NATルータでポートフォワードをしてあげる必要があります。
各自NATルータの設定を行なってください。

やることは、NATルータのWAN側(グローバルIP:10.10.10.1)の特定のポートアドレスUDP:1194を、OpenVPNサーバ(プライベートIP:192.168.1.253)に転送してあげる設定になります。


※ポートフォワーディング機能はメーカによって記載が異なります。それぞれ調べて設定して下さい。

例)Buffalo:「ポート変換」または「アドレス変換」
  Corega:バーチャル・サーバ(ポート開放)
  NEC:ポートマッピング機能


4.OpenVPNクライアントの設定

OpenVPNクライアント側の"client.conf"を設定してあげます。
私は、~.openvpn配下に配置しているので、これを編集します。編集箇所は、
;remote 192.168.100.253 1194
remote 10.10.10.100 1194

の箇所です。既存設定をコメントアウトしました。
設定するアドレスは、NATルータのWAN側にプロバイダから割り当てられているグローバルIPアドレスになります。

POINT
通常のご家庭では、プロバイダからDHCPでアドレスを取得しているケースが多いと思います。このケースだと、グローバルIPアドレスが変わる可能性がありますので、ダイナミックDNS(DDNS)などを活用するべきだと思います。
残念ながら、私のNATルータはDDNSに未対応だったためやむなくIPで設定しました。


5.接続確認

OpneVPNクライアントから、接続を試みます。
$ sudo openvpn ./client.conf
 (略)
Thu May 16 11:31:10 2013 TUN/TAP device tun0 opened
Thu May 16 11:31:10 2013 TUN/TAP TX queue length set to 100
Thu May 16 11:31:10 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu May 16 11:31:10 2013 /sbin/ifconfig tun0 192.168.66.6 pointopoint 192.168.66.5 mtu 1500
Thu May 16 11:31:10 2013 /sbin/route add -net 192.168.123.0 netmask 255.255.255.0 gw 192.168.66.5
Thu May 16 11:31:10 2013 /sbin/route add -net 192.168.66.1 netmask 255.255.255.255 gw 192.168.66.5
Thu May 16 11:31:10 2013 Initialization Sequence Completed

と表示されれば、接続成功です。


クライアントにて確認を行ってみます。

まずは経路情報の確認。
下記赤字の経路があればOKです。
特に、自宅内LAN(192.168.1.0)向けのルーティングがtun0に向いているのが重要です。
$ netstat -rn
カーネルIP経路テーブル
受信先サイト ゲートウェイ ネットマスク フラグ MSS Window irtt インタフェース
0.0.0.0 10.10.10.254 0.0.0.0 UG 0 0 0 wlan1
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan1
192.168.66.1 192.168.66.5 255.255.255.255 UGH 0 0 0 tun0
192.168.66.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 192.168.66.5 255.255.255.0 UG 0 0 0 tun0


自宅PCにTracerouteで経路を確認してみます。
ちゃんと、VPNトンネルを経由して、自宅PCに到達していることがわかります。
$ traceroute 192.168.123.202
traceroute to 192.168.123.202 (192.168.123.202), 30 hops max, 60 byte packets
1 192.168.66.1 (192.168.66.1) 29.329 ms 78.011 ms 79.079 ms
2 192.168.1.202 (192.168.123.202) 79.087 ms 80.042 ms 80.053 ms


これで完了です。
実際の環境で試してみてください。



※アドレス等実際テストした環境と少し変えているので、記載ミスがあるかもしれません。その場合ご指摘ください。
※テスト構成で行なっていますので、実際のグローバルIPアドレスであるべき箇所もプライベート(10.x.x.x)を使っています。
プロフィール

Author:Opecha-DaDa
ニッチな技術メモ的なブログになりつつありますが、だからこそあなたのお役に立てる内容があれば幸いです。

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QR