Remminaでリモートデスクトップ接続ができない

RemminaでRDPアクセスができない!

Remminaというリモートデスクトップクライアントがあります。
RDPやVNC、SSHなど多彩な接続が可能なGUIクライアントで、Windowsのリモートデスクトップ接続に利用可能です。
利用は特に難しくありません。

あるとき、Ubuntuのリモートデスクトップクライアント(Remmina)からWindowsサーバ等へRDPでの接続が出来なくなっている事に気が付きました。
過去に設定済みで、問題なく使えるところまでは確認済みです。
普段は利用しないけど、利用できないままだと困るのでちょっと調べて見ました。


環境
 ・RDPクライアント
  Ubuntu12.04LTS
  Remmina 0.9.99.1

 ・RDPサーバ
  Windows2008 Server




現象
・過去に設定した一覧から、対象サーバを選んで接続ボタンを押すとすぐさま「RDPサーバ x.x.x.x に接続できません」というエラーが表示されて接続できない。
remmina-error.png


・テスト的に、その他のサーバに接続すると問題なく行く。

・その他のクライアントから当該サーバへは問題なくRDPでの接続が可能。

・当該サーバのFirewallなどの設定は問題なく、nmapで当該サーバのポートを調べると

$ nmap サーバIP -p 3389

Starting Nmap 5.21 ( http://nmap.org ) at 2013-08-06 11:24 JST
Nmap scan report for サーバ名 (サーバIP)
Host is up (0.0050s latency).
PORT STATE SERVICE
3389/tcp open ms-term-serv


となっており、問題なくポートも開いており到達可能のように見える。

・Wiresharkでパケットをキャプチャすると、クライアント(Ubuntu)側がセッションを切断しているように見える。


という事で、過去に接続したことのあるサーバで現象起きているのでは?と推測して、ならばその情報を消してやればうまく行くかもと考えました。
接続がうまく行く時は証明書の受け入れ画面が出てきますので、この情報を一旦消してやればいいのでは?という推測で、ネットを調べて見ました。
(※証明書の受け入れを聞かれるかどうかは、Windows側の設定にもよります。)


参考にしたサイト
https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/944040


で、上記サイトを見ていて過去に接続したことのあるリストが
~/.freerdp/known_hosts
なるものの存在を知りました。

早速そのファイルをリネームして再度接続を試す。


mv ~/.freerdp/known_hosts ~/.freerdp/known_hosts.backup 


で、Remminaから接続。
証明書の受け入れの画面が表示され「OK」を選択すると、再度接続できるようになりました!!
解決してよかった。



known_hostsを見てみると、IPアドレスとフィンガープリントと思われる一覧の記載が
ありました。変更のタイミングは不明ですが、再度接続した時のフィンガープリントの値
とは異なっていたのでできなかったのだと思います。

$less ~/.freerdp/known_hosts
サーバIPアドレス (略):9b:99:7c

今回のフィンガープリント
fingerprint.png

下6桁くらいで異なっていることがわかりますね。


ちなみに、参考にしたサイトにはこれはバグで新しいバージョンでは直っているようなことが書いて有りますね。




UbuntuでWindowsサーバの共有フォルダをマウント

UbuntuでWindows共有フォルダに楽々アクセス!

Linuxをデスクトップ用途として利用していると、どうしてもWindowsとファイル共有をする必要が出てきますね。今回は、Windowsサーバのファイル共有を楽に行いたいという事で試行錯誤しました。

悩んでいたのが、解決したのでメモしておきます。ハマった点は一番下。
Windowsの共有名で"$"がついているケースで失敗した。



LinuxでWindowsの共有フォルダをマウントする方法を調べてみるといくつか方法が
あるようです。

マウントいろいろ
 ①コマンドでその都度マウントする
 ②/etc/fstabを利用し、Linux起動時にマウントする
 ③autofsを利用し、必要なときに自動でマウントする

全部試してみましょう。




目標
 ・Ubuntu12.04で、Windowsサーバ(Windows2008)の共有ディレクトリを参照する。
 ・Nautilus(GnomeのGUIファイルマネージャ)からGUIでアクセスできるようにしたい

前提
 ・サーバのディレクトリ名:share
 ・ローカルでのディレクトリ名:server-share
 ・ユーザ:user1
 ・user1のサーバのパスワード:user1-passwd
 ・サーバのIP:192.168.0.100
 ※ユーザIDとパスワードはローカルとサーバで同じにしています。マウントコマンドで出てくるID/Passwordはすべて接続先のサーバのID/Passwordと読み取ってください。

事前準備
cifs-utilsのインストール
  $sudo apt-get install cifs-utils





①コマンドでのマウント
まずは、手動でマウントしてみます。

1.マウントポイントの設定

マウントポイント(ディレクトリ)を作成。仮にserver-shareとする。
※慣習的にマウントポイントは、"/mnt"に作るらしい。が、自分のホームディレクトリにも作成可能。ちなみに、Ubuntuの場合ホームディレクトリ配下にマウントすると、マウントのメッセージが出てきた。

$mkdir /mnt/server-share



2.マウント


あとは"mount"コマンドを利用して、マウントポイントにファイルサーバのディレクトリをマウントする。
イメージ的には、マウントポイントというショートカットに実サーバをリンクする感じ?
(間違えてるかも)
   
root権限が必要なためUbuntuの場合"sudo"をつけてあげる必要がる。パスワードを聞かれるので、サーバのログインパスワードを入力。

入力コマンド
$sudo mount -t cifs //サーバ名/共有フォルダ名 /マウントポイント -o username=USERNAME

$sudo mount -t cifs //192.168.0.100/share /mnt/server-share -o username=user1
Password:

確認してみる
$ ls -l /mnt
drwxr-xr-x 1 root root 4096 7月 31 20:35 server-share/


これで完了!

ただし、結果でわかるとおりこのフォルダの所有権がrootになっており、一般ユーザの書き込みができない。
書き込みが必要な場合、少しおまじないが必要となる。

$sudo mount -t cifs //192.168.0.100/share /mnt/server-share -o username=user1,uid=1000,gid=1000

これは、利用したいユーザ(自分)に権限を割り当てる意味となっているらしい。
これをつけて実行すると

$ ls -l /mnt
drwxr-xr-x 1 user1 user1 4096 7月 31 20:35 test/


となっており、読み書きが可能となる。
uidとgidはそれぞれ、/etc/passwdの該当ユーザの右側の数字を見る。


3.アンマウント


利用が終わったら、アンマウント(取り外し)を行う。

umountコマンドで、引数にはマウント先のフォルダ名を入れる。
root権限で実行します。

$ sudo umount /mnt/server-share





② /etc/fstabでの自動マウント

いつも使いたいディレクトリなどをいちいちマウントするのはめんどくさい!
/etc/fstabを利用することで自動にマウントすることが可能となりますよ。


1.マウントポイントの設定

$mkdir /mnt/server-share



2./etc/fstabの編集

vi等で/etc/fstabの最下行に以下を追加。

//192.168.0.100/share /mnt/server-share cifs username=user1,password=user1-passwd,uid=1000,gid=1000 0 0

ちなみに最後の「0 0」は
前者が:ファイルシステムをdumpするかどうか
後者が:システム起動時にfsckチェックを行うかどうか
という意味らしい。
詳しいパラメータは、「fstab 書式」でgoogle先生に聞いてください(適当)


終了。
再起動して、想定のディレクトリ(ここでは/mnt/server-share)マウントされていることを確認する。

ちなみに、/etc/fstabにパスワードを記載することに抵抗がある場合はその部分を外部ファイルに持つことも可能らしい。「credentials」というキーワードで検索してね♪


※アンマウントは、手動マウントと同じです。






③ autofsでの自動マウント

いつもは使わないんだけど、たまに利用する。でも手動はめんどくさい!
そんな場合は"autofs"がお勧めです。

1.事前準備

autofsのインストール
$sudo apt-get install autofs



2./etc/auto.serverの作成
/etc/auto.XXXのXXX部分は好きな名前でいいのですが今回はserverとしました。

vi等で/etc配下にauto.serverを作成。
中身としては

/mnt/server-share -fstype=cifs,rw,username=user1,password=user1-passwd,uid=1000,gid=1000 192.168.0.100:/share



3./etc/auto.masterの編集

vi等で、/etc/auto.masterの最下行に先ほどのファイルを指定。

(略)
#+auto.master

/- /etc/auto.server --timeout 60

ここの60は、60秒アクセスがない場合自動でアンマウントするという意味です。


4.autofsの再起動

$sudo service autofs restart



5.確認

autofsはフォルダにアクセスした時に初めてマウントするため、ファイルマネージャ(Nautilus)やcdコマンドで当該ディレクトリに
移動してファイルが表示されるか確認する。移動後、mountコマンドで確認してみてもOK。
60秒たったあとmountコマンドで再度確認すると、アンマウントされている。よしよし。
※ちなみに、ディレクトリ開いたままだといつまでもアンマウントされません。



●GUIでのアクセス
上記マウントポイントに対して、Nautilusでブックマークを貼ってあげれば良い。
該当フォルダを開いて、メニューから「ブックマークの追加」をしてあげると左側のツリーに表示される。(Nautilus)
※そのディレクトリに入ってからやらないとダメです。



●マウント状態の確認(共通)
mountコマンドの出力
※以下は、/etc/fstabとautofsを同時に実行したケースです。
(※autofsの方は、server-share2としてマウントしました)
$ mount
(略)
//10.82.12.11/share on /mnt/server-share type cifs (rw)
10.82.12.11:/share on /mnt/server-share2 type cifs (rw)



●メリット・デメリット

・/etc/fstab
 → Linux起動時に共有サーバがDownしているとちょっと問題がある(忘れた)


・autofs
 → アクセス時にいちいちマウントするため、ワンテンポ遅れる
 → 自動でアンマウントしてくれるので便利
 → 手動・fstabと異なり事前にマウントポイントを準備する必要がない!

たしか、テストしている時にBootの時にアクセス出来なくて困った事があったので、autofsにしました。





●Windowsの共有名に関して
上では書きませんでしたが、Windowsで共有フォルダ名が「Share$」のように"$"がついているケースがあります。
今回調べて知ったのですが、どうやらこれには意味があるらしい。

fstabの時はうまく行ったのですが、autofsでこの"$"がついている共有名のフォルダで失敗していました。具体的には、アクセスが出来なくて/var/log/syslogに

CIFS VFS: cifs_mount failed w/return code = -6

が表示されてアクセスできない。
このログがいまいちネットに載っていなかったので、関連しているかは不明ですが結果として、autofsの書式で
/mnt/server-share -fstype=cifs,rw,username=user1,password=user1-passwd,uid=1000,gid=1000 192.168.0.100:/share$
ではなく、$の前にエスケープシーケンスを入れてあげるらしい。
/mnt/server-share -fstype=cifs,rw,username=user1,password=user1-passwd,uid=1000,gid=1000 192.168.0.100:/share\$
※実際はバックスラッシュ
これでうまく行きました。

こちらのサイトを参考にさせていただきました。$の理由などもあり、勉強になりました。



謎だったのが解決してよかった。




テーマ : UNIX/Linux
ジャンル : コンピュータ

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に変更する箇所です(赤字)。
プロフィール

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

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

この人とブロともになる

QRコード
QR