覚え書きモード。
Q： できれば FreeBSD ベースで、電源をいきなりブチッと切っても大丈夫な、組み込み向け （？） の BSD はないですか？
A： NanoBSD は如何でしょう？
さて、NanoBSD ですが。
FreeBSD の配布物に含まれている、組み込み向けにカスタムした FreeBSD イメージを作るためのスクリプト群、またはその成果物のことだそうで。
スクリプトは、/usr/src/tools/tools/nanobsd/nanobsd.sh にあります。
仕組みとしては、以下のようになっている模様。
・/ は、リードオンリーでマウント
・/etc と /var は md （メモリディスク） に作成
・不揮発設定は /cfg に保存 （/etc は、起動時に /cfg を一時的にリードオンリーでマウントして自動生成）
・システムパーティションは２つある
・/cfg も１パーティションになっている （当たり前）
システムの更新は、２つあるシステムパーティションのうち、現在非アクティブな方に新しいイメージを書き込み、そこから起動。
上手く動いたら、起動したパーティションをアクティブにマークして終了。
ダメだったら、とりあえず元々起動していたパーティションから起動し直してサービスを続行させておき、イメージの作り直しを行う。
つまり、ダウンタイムは再起動の手間だけとなる上、復旧も容易。
なお、この NanoBSD をベースに使用しているプロジェクトには、以下の物などがある。
・FreeNAS
・BSD Router Project
・pfSense
NanoBSD に関する資料は、以下などを参照。
Introduction to NanoBSD
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/nanobsd/index.html
NanoBSD HowTo
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/nanobsd/howto.html
FreeBSD Doc NanoBSD （上記２つの日本語訳）
http://www.seichan.org/wiki/index.php?FreeBSD-Doc-NanoBSD
documentation:technical_docs:nanobsd （BSD Router Project の NanoBSD 情報ページ）
http://bsdrp.net/documentation/technical_docs/nanobsd
2010/11/04
IPv6 Address とプライバシー
もう、遥かに前から言われていたことですが、IPv6 では、自動設定 (Auto Configuration) で付けられたアドレスにはプライバシー上の問題がありました。
その理由は、128bits ある IPv6 Address の下 64bits は EUI-64 Address の 7bits 目を反転して作成するのですが、EUI-64 Address は、MAC Address を 24bits づつに分けた間に 0xFFFE を挿入して作るため。
つまり、Address の下 64bits を監視していれば、上位 64bits が変わろうとも （どのネットワークの下にぶら下がろうとも）、個人を特定してトレースできてしまうということ。
そんなわけで、MAC Address がわからず、作り直し可能な Address を自動生成したいね、ということに。
そのための規格が、既に存在します。
プライバシー拡張、って奴です。
"Privacy Extensions for Stateless Address Autoconfiguration in IPv6" (RFC 4941: Obsolete 3041)
なんで Stateless かって、Stateful の場合は DHCPv6 でしょうから、Local Scope の Address （下 64bits の 7bits 目が 0 の Address） を振ればいいじゃない、と言う話ですね。
DHCPv6-PD の場合は、Stateless 扱いになるんじゃないかしら。
さて、このプライバシー拡張。
Windows は、標準で対応し、有効になっているらしいです。（XP 以降）
しかし、FreeBSD とか Mac OS X では、対応はしているけれど、デフォルト無効なのよね。
そんなわけで、有効にする方法をば。
FreeBSDの場合）
これらのために、以下の sysctl 値が定義されています。
net.inet6.ip6.use_tempaddr (default: 0)
プライバシー用一時アドレスを使用するか （1 で有効）
net.inet6.ip6.prefer_tempaddr (default: 0)
プライバシー用一時アドレスを送信元アドレスとするか （1 で有効）
net.inet6.ip6.temppltime (default: 86400)
プライバシー用一時アドレスの推奨有効時間 （秒単位で指定。デフォルト１日）
net.inet6.ip6.tempvltime (default: 604800)
プライバシー用一時アドレスの最大有効時間 （秒単位で指定。デフォルト１週間）
システムが起動してから設定するなら、
# sysctl net.inet6.ip6.use_tempaddr=1
# sysctl net.inet6.ip6.prefer_tempaddr=1
とでもしてください。
ただ、再起動すると消えてしまうので、常に有効にしたい場合は /etc/sysctl.conf に記述を追加してください。
net.inet6.ip6.use_tempaddr=1
net.inet6.ip6.prefer_tempaddr=1
Mac OS X の場合）
FreeBSD と、二点を除いて変わりません。
違う点は、net.inet6.ip6.prefer_tempaddr 変数がないところと sysctl の指定方法です。
Mac OS X では、net.inet6.ip6.use_tempaddr を 1 にすれば、発信元にプライバシー用一時アドレスを使うようになります。
システムが起動してからは、以下のように設定します。
sysctl -w net.inet6.ip6.use_tempaddr=1
-w オプションが必要になります。
FreeBSD では、このオプションは単に無視されるだけなので、付けてやっても動作は変わりません。
FreeBSD 同様、再起動すると設定が消えてしまうので、常に有効にするなら /etc/sysctl.conf に記述を追加してください。
その理由は、128bits ある IPv6 Address の下 64bits は EUI-64 Address の 7bits 目を反転して作成するのですが、EUI-64 Address は、MAC Address を 24bits づつに分けた間に 0xFFFE を挿入して作るため。
つまり、Address の下 64bits を監視していれば、上位 64bits が変わろうとも （どのネットワークの下にぶら下がろうとも）、個人を特定してトレースできてしまうということ。
そんなわけで、MAC Address がわからず、作り直し可能な Address を自動生成したいね、ということに。
そのための規格が、既に存在します。
プライバシー拡張、って奴です。
"Privacy Extensions for Stateless Address Autoconfiguration in IPv6" (RFC 4941: Obsolete 3041)
なんで Stateless かって、Stateful の場合は DHCPv6 でしょうから、Local Scope の Address （下 64bits の 7bits 目が 0 の Address） を振ればいいじゃない、と言う話ですね。
DHCPv6-PD の場合は、Stateless 扱いになるんじゃないかしら。
さて、このプライバシー拡張。
Windows は、標準で対応し、有効になっているらしいです。（XP 以降）
しかし、FreeBSD とか Mac OS X では、対応はしているけれど、デフォルト無効なのよね。
そんなわけで、有効にする方法をば。
FreeBSDの場合）
これらのために、以下の sysctl 値が定義されています。
net.inet6.ip6.use_tempaddr (default: 0)
プライバシー用一時アドレスを使用するか （1 で有効）
net.inet6.ip6.prefer_tempaddr (default: 0)
プライバシー用一時アドレスを送信元アドレスとするか （1 で有効）
net.inet6.ip6.temppltime (default: 86400)
プライバシー用一時アドレスの推奨有効時間 （秒単位で指定。デフォルト１日）
net.inet6.ip6.tempvltime (default: 604800)
プライバシー用一時アドレスの最大有効時間 （秒単位で指定。デフォルト１週間）
システムが起動してから設定するなら、
# sysctl net.inet6.ip6.use_tempaddr=1
# sysctl net.inet6.ip6.prefer_tempaddr=1
とでもしてください。
ただ、再起動すると消えてしまうので、常に有効にしたい場合は /etc/sysctl.conf に記述を追加してください。
net.inet6.ip6.use_tempaddr=1
net.inet6.ip6.prefer_tempaddr=1
Mac OS X の場合）
FreeBSD と、二点を除いて変わりません。
違う点は、net.inet6.ip6.prefer_tempaddr 変数がないところと sysctl の指定方法です。
Mac OS X では、net.inet6.ip6.use_tempaddr を 1 にすれば、発信元にプライバシー用一時アドレスを使うようになります。
システムが起動してからは、以下のように設定します。
sysctl -w net.inet6.ip6.use_tempaddr=1
-w オプションが必要になります。
FreeBSD では、このオプションは単に無視されるだけなので、付けてやっても動作は変わりません。
FreeBSD 同様、再起動すると設定が消えてしまうので、常に有効にするなら /etc/sysctl.conf に記述を追加してください。
2010/08/05
PPTP 覚え書き
今現在、VPN を張るのに OpenVPN を使用しているのだけれども。
当たり前のことながら市販機器では使用できないので、別のものを考える。
VPN 接続に使われる方式は、主に２つ。
・PPTP / MPPE (RC4)
・L2TP / IPSec
他にも GRE + IPSec で LAN 間接続とかいろいろあるけれど。
さて、使用する予定のクライアントは、Windows PC と iPhone とブロードバンドルータ。
そうすると、事実上 PPTP / MPPE (RC4) しかなくなってしまうという。。。
本当は、L2TP / IPSec でやりたいところなのだけれど、これに対応しているブロードバンドルータがない （正確には、ないわけではないが、３万弱以上のお値段が張る） し、FreeBSD で IPv4 で IPSec を使用する場合、kernel 再構築が必要になってしまい、freebsd-update が使えなくなってしまうと言う面倒くささがあるので、妥協してみる。
PPTP Server には MPD を使用してみようかと思っている。
さて。
PPTP 接続の MTU, MRU, MSS はどうなるのかな、と言うのが、今回のお題。
MTU (Maximum Transmission Unit) : 最大送信ユニット
MRU (Maximum Receive Unit) : 最大受信ユニット
MSS (Maximum Segment Size) : 最大セグメントサイズ (TCP Only)
またややこしいことに、うちのネット接続は、Flet's 網なんだよね。
Flet's の MTU 推奨値は 1,454 bytes です。
これは、Flet's 網の仕様によるものだそうで。
Flet's 網を利用する場合のパケット：
LAN:
IP Header (20 bytes) + Protocol Header + Data = (max) 1,500 bytes
MTU = 1,500
Router -> NTT:
PPPoE Header (6 bytes) + PPP Header (2 bytes) + LAN Packet = (max) 1,500 bytes
MTU = 1,500 - (6 + 2) = 1,492
NTT -> ISP (BAS):
IP Header (20 bytes) + UDP Header (8 bytes) + L2TP Header (16 bytes) + PPP Header (2 bytes) + LAN Packet = (max) 1,500 bytes
MTU = 1,500 - (20 + 8 + 16 + 2) = 1,454
そんなわけで、MTU = 1,454 になるわけです。
MRU も MTU と同じで問題ないでしょう。
MSS は、MTU - 40 (IP Header 20 bytes + TCP Header 20 bytes) になります。
で、この上で PPTP をかましたらどうなるか、ということ。
PPTP のパケットは、こんな構造になっています。
PPTP Packet:
IP Header (20 bytes) + (PPTP) GRE Header (16 bytes) + PPP Header (2 bytes) + LAN Packet = (max) 1,500 bytes
ところがどっこい、これがさらにカプセル化されるわけですよ。
つまり、一番悲惨な状態は、こうなっています。
PPTP Packet on NTT -> ISP (BAS):
IP Header + UDP Header + L2TP Header + PPP Header （以上 Flet's 網でのカプセル化）
+ IP Header + GRE Header + PPP Header + LAN Packet = (max) 1,500 bytes
つまり、MTU は、1,500 - (20 + 8 + 16 + 2) - (20 + 16 + 2) = 1,454 - 38 = 1,416 となります。
MSS は 1,416 - 40 = 1,376 ですね。
当たり前のことながら市販機器では使用できないので、別のものを考える。
VPN 接続に使われる方式は、主に２つ。
・PPTP / MPPE (RC4)
・L2TP / IPSec
他にも GRE + IPSec で LAN 間接続とかいろいろあるけれど。
さて、使用する予定のクライアントは、Windows PC と iPhone とブロードバンドルータ。
そうすると、事実上 PPTP / MPPE (RC4) しかなくなってしまうという。。。
本当は、L2TP / IPSec でやりたいところなのだけれど、これに対応しているブロードバンドルータがない （正確には、ないわけではないが、３万弱以上のお値段が張る） し、FreeBSD で IPv4 で IPSec を使用する場合、kernel 再構築が必要になってしまい、freebsd-update が使えなくなってしまうと言う面倒くささがあるので、妥協してみる。
PPTP Server には MPD を使用してみようかと思っている。
さて。
PPTP 接続の MTU, MRU, MSS はどうなるのかな、と言うのが、今回のお題。
MTU (Maximum Transmission Unit) : 最大送信ユニット
MRU (Maximum Receive Unit) : 最大受信ユニット
MSS (Maximum Segment Size) : 最大セグメントサイズ (TCP Only)
またややこしいことに、うちのネット接続は、Flet's 網なんだよね。
Flet's の MTU 推奨値は 1,454 bytes です。
これは、Flet's 網の仕様によるものだそうで。
Flet's 網を利用する場合のパケット：
LAN:
IP Header (20 bytes) + Protocol Header + Data = (max) 1,500 bytes
MTU = 1,500
Router -> NTT:
PPPoE Header (6 bytes) + PPP Header (2 bytes) + LAN Packet = (max) 1,500 bytes
MTU = 1,500 - (6 + 2) = 1,492
NTT -> ISP (BAS):
IP Header (20 bytes) + UDP Header (8 bytes) + L2TP Header (16 bytes) + PPP Header (2 bytes) + LAN Packet = (max) 1,500 bytes
MTU = 1,500 - (20 + 8 + 16 + 2) = 1,454
そんなわけで、MTU = 1,454 になるわけです。
MRU も MTU と同じで問題ないでしょう。
MSS は、MTU - 40 (IP Header 20 bytes + TCP Header 20 bytes) になります。
で、この上で PPTP をかましたらどうなるか、ということ。
PPTP のパケットは、こんな構造になっています。
PPTP Packet:
IP Header (20 bytes) + (PPTP) GRE Header (16 bytes) + PPP Header (2 bytes) + LAN Packet = (max) 1,500 bytes
ところがどっこい、これがさらにカプセル化されるわけですよ。
つまり、一番悲惨な状態は、こうなっています。
PPTP Packet on NTT -> ISP (BAS):
IP Header + UDP Header + L2TP Header + PPP Header （以上 Flet's 網でのカプセル化）
+ IP Header + GRE Header + PPP Header + LAN Packet = (max) 1,500 bytes
つまり、MTU は、1,500 - (20 + 8 + 16 + 2) - (20 + 16 + 2) = 1,454 - 38 = 1,416 となります。
MSS は 1,416 - 40 = 1,376 ですね。
2010/06/26
Postfix でバーチャルユーザを混在させる方法 （補足３）
直前のエントリの補足です。
実ドメイン運用して、fallback_transport = virtual したとします。
この設定をして、virtual ユーザにメールが送れないよー、となっちゃった方々へ。
まぁ、普通にやっただけだと、
550 User unknown in local recipient table
って言われちゃいますよねー。
＃ メールサーバにログインして、mail コマンドで送ったら大丈夫だったけれど
＃ 他の環境から送ったら、このエラーで送れなかったのです。。。
Postfix は、知らないローカル受信者宛のメールを自動で拒否してしまうのでした。
つまり、fallback_transport を指定している場合、これで処理されるユーザを教えてあげなければなりません。
その問題と解決策が、マニュアル文書に書いてあります。
Postfix で知らないローカルユーザを拒否する
http://www.postfix-jp.info/trans-2.3/jhtml/LOCAL_RECIPIENT_README.html
---
main.cf の local_recipient_maps 設定を変更する必要がある場合
問題: 非 UNIX アカウントにメールを配送するために Postfix local(8) 配送エージェントの mailbox_transport または fallback_transport 機能を使っています。
解決策: 非 UNIX ユーザをリストアップしたデータベースを追加する必要が あります:
/etc/postfix/main.cf
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps,
<the database with non-UNIX accounts>
テーブルの作り方に関する記述は、以下の "ローカル受信者テーブルのフォーマット" の セクションを参照してください。
---
というわけで、local_recipient_maps の設定が必要なわけです。
ここにデータベースを追加するわけですが、実ドメインのバーチャルメールボックスユーザは、virtual_mailbox_maps に指定したデータベースに書いていたわけです。
なので、このデータベースを指定すれば OK です。
main.cf:
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps, $virtual_mailbox_maps
この設定で、無事、バーチャルユーザが弾かれることなく、メールが届くようになります。
付属ドキュメントは、ちゃんと読みましょう・・・ ＞ σ(__;
■ バーチャルユーザ混在、まとめ （ただし、実ドメインとしての運用の場合のみ）
実ユーザとバーチャルユーザを混在させる場合、以下のような設定を行う。
実ドメインとして運用する場合、ローカルにユーザが存在しない場合、fallback_transport を使用し、virtual に fallback するように設定する。
ただし、550 User unknown in local recipient table のエラーで弾かれないように、local_recipient_maps にてバーチャルユーザデータベースを指定する。
あとは、virtual mailboxと同じように設定すればよい。
main.cf:
mydestination = example.net, ...
fallback_transport = virtual:
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps, $virtual_mailbox_maps
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
vmailbox:
vusr@example.net example.net/vusr/
実ドメイン運用して、fallback_transport = virtual したとします。
この設定をして、virtual ユーザにメールが送れないよー、となっちゃった方々へ。
まぁ、普通にやっただけだと、
550 User unknown in local recipient table
って言われちゃいますよねー。
＃ メールサーバにログインして、mail コマンドで送ったら大丈夫だったけれど
＃ 他の環境から送ったら、このエラーで送れなかったのです。。。
Postfix は、知らないローカル受信者宛のメールを自動で拒否してしまうのでした。
つまり、fallback_transport を指定している場合、これで処理されるユーザを教えてあげなければなりません。
その問題と解決策が、マニュアル文書に書いてあります。
Postfix で知らないローカルユーザを拒否する
http://www.postfix-jp.info/trans-2.3/jhtml/LOCAL_RECIPIENT_README.html
---
main.cf の local_recipient_maps 設定を変更する必要がある場合
問題: 非 UNIX アカウントにメールを配送するために Postfix local(8) 配送エージェントの mailbox_transport または fallback_transport 機能を使っています。
解決策: 非 UNIX ユーザをリストアップしたデータベースを追加する必要が あります:
/etc/postfix/main.cf
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps,
<the database with non-UNIX accounts>
テーブルの作り方に関する記述は、以下の "ローカル受信者テーブルのフォーマット" の セクションを参照してください。
---
というわけで、local_recipient_maps の設定が必要なわけです。
ここにデータベースを追加するわけですが、実ドメインのバーチャルメールボックスユーザは、virtual_mailbox_maps に指定したデータベースに書いていたわけです。
なので、このデータベースを指定すれば OK です。
main.cf:
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps, $virtual_mailbox_maps
この設定で、無事、バーチャルユーザが弾かれることなく、メールが届くようになります。
付属ドキュメントは、ちゃんと読みましょう・・・ ＞ σ(__;
■ バーチャルユーザ混在、まとめ （ただし、実ドメインとしての運用の場合のみ）
実ユーザとバーチャルユーザを混在させる場合、以下のような設定を行う。
実ドメインとして運用する場合、ローカルにユーザが存在しない場合、fallback_transport を使用し、virtual に fallback するように設定する。
ただし、550 User unknown in local recipient table のエラーで弾かれないように、local_recipient_maps にてバーチャルユーザデータベースを指定する。
あとは、virtual mailboxと同じように設定すればよい。
main.cf:
mydestination = example.net, ...
fallback_transport = virtual:
local_recipient_maps = proxy:unix:passwd.byname, $alias_maps, $virtual_mailbox_maps
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
vmailbox:
vusr@example.net example.net/vusr/
2010/06/24
Postfix でバーチャルユーザを混在させる方法 （補足２）
直前のエントリの補足です。
結局、実ドメインとして運用するようにしてみました。
たぶん、この方が楽だと思うので。
実ドメインとして運用すると、当該ドメイン宛のメールの配送には、local(8) エージェントが使われます。
local(8) は、aliases データベースと UNIX パスワードデータベースを検索し、ローカルにユーザが存在する場合は、そのままローカル配送します。
肝になるのは、ローカルにユーザが存在しない場合です。
この場合、local(8) が頑張って探してもユーザが見つからなかった場合、fallback_transport_maps の指定、なければ、fallback_transport の指定に従って配送してくれます。
このパラメータを設定することにします。
今回は、バーチャルメールボックスユーザとするため、virtual(8) で配送してもらいます。
そのため、fallback_transport パラメータを設定しました。
main.cf:
fallback_transport = virtual:
これで、あとは、
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
この辺の指定に従って、配送してくれます。
バーチャルメールボックスドメインとして運用する場合は、たぶん、これと逆のことをやればいいはずです。
つまり、何よりも早く配送方法を指定できるように、transport_maps パラメータを設定し、ローカルユーザ宛の配送方法を決定すればいいでしょう。
main.cf:
transport_maps = hash:/usr/local/etc/postfix/transport
transport:
luser@example.net local:$myhostname
・・・
と言った形になります。
virtual(8) で配送させると、aliases データベースも検索してくれないし、.forward 等の処理もできないんだよなぁ。。。
利用したかったら、力業しかないのかなぁ。。。
結局、実ドメインとして運用するようにしてみました。
たぶん、この方が楽だと思うので。
実ドメインとして運用すると、当該ドメイン宛のメールの配送には、local(8) エージェントが使われます。
local(8) は、aliases データベースと UNIX パスワードデータベースを検索し、ローカルにユーザが存在する場合は、そのままローカル配送します。
肝になるのは、ローカルにユーザが存在しない場合です。
この場合、local(8) が頑張って探してもユーザが見つからなかった場合、fallback_transport_maps の指定、なければ、fallback_transport の指定に従って配送してくれます。
このパラメータを設定することにします。
今回は、バーチャルメールボックスユーザとするため、virtual(8) で配送してもらいます。
そのため、fallback_transport パラメータを設定しました。
main.cf:
fallback_transport = virtual:
これで、あとは、
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
この辺の指定に従って、配送してくれます。
バーチャルメールボックスドメインとして運用する場合は、たぶん、これと逆のことをやればいいはずです。
つまり、何よりも早く配送方法を指定できるように、transport_maps パラメータを設定し、ローカルユーザ宛の配送方法を決定すればいいでしょう。
main.cf:
transport_maps = hash:/usr/local/etc/postfix/transport
transport:
luser@example.net local:$myhostname
・・・
と言った形になります。
virtual(8) で配送させると、aliases データベースも検索してくれないし、.forward 等の処理もできないんだよなぁ。。。
利用したかったら、力業しかないのかなぁ。。。
Postfix でバーチャルユーザを混在させる方法 （補足）
直前のエントリの補足です。
■ ドメインを実ドメインとして運用する場合
転送用に指定するバーチャルメールボックスドメインは、名前解決できなければなりません。
ですので、DNS に登録するなど、工夫が必要となるでしょう。
■ ドメインをバーチャルメールボックスドメインとして運用する場合
main.cf にて指定している myorigin パラメータが、mydestination パラメータに指定されていることが要求されます。
しかしながら、myorigin = $mydomain として、virtual_mailbox_domains = $mydomain, ... としてしまった場合、ローカルユーザに配送するには、virtual_alias_maps で指定したファイルにて、以下のように指定します。
virtual:
luser@example.net luser@localhost
このように、強制的にローカルを指定して配送させます。
しかしながら。。。
この方法でローカルユーザにマップすると、ローカルのユーザに届くメールのヘッダには、
Delivered-To: luser@localhost.example.net
X-Original-To: luser@localhost.example.net
と記録されてしまって、とても哀しいことに。。。
対策を模索中です。
*_transport_maps の指定で、どうにかできそうな予感。。。
■ ドメインを実ドメインとして運用する場合
転送用に指定するバーチャルメールボックスドメインは、名前解決できなければなりません。
ですので、DNS に登録するなど、工夫が必要となるでしょう。
■ ドメインをバーチャルメールボックスドメインとして運用する場合
main.cf にて指定している myorigin パラメータが、mydestination パラメータに指定されていることが要求されます。
しかしながら、myorigin = $mydomain として、virtual_mailbox_domains = $mydomain, ... としてしまった場合、ローカルユーザに配送するには、virtual_alias_maps で指定したファイルにて、以下のように指定します。
virtual:
luser@example.net luser@localhost
このように、強制的にローカルを指定して配送させます。
しかしながら。。。
この方法でローカルユーザにマップすると、ローカルのユーザに届くメールのヘッダには、
Delivered-To: luser@localhost.example.net
X-Original-To: luser@localhost.example.net
と記録されてしまって、とても哀しいことに。。。
対策を模索中です。
*_transport_maps の指定で、どうにかできそうな予感。。。
2010/06/23
Postfix でバーチャルユーザを混在させる方法
タイトルだけだと、よくわからないかもしれませんね。。。
Postfix であるドメインを運用するときに、
一部のユーザは、システムにアカウントを持つ実ユーザ (UNIX アカウント持ちユーザ)
他のユーザは、システムアカウントを持たないユーザ (バーチャルユーザ)
とする方法です。
方法は、二つほどあるようです。
■ 実ドメインとして運用する場合
運用ドメインを、実ドメイン （基本的にローカルにユーザを作成してそこに配送させるドメイン） として運用する場合の方法です。
具体的な作戦は、以下の通りです。
・運用ドメインは、実ドメインとして設定
・バーチャルメールボックス用のドメインを用意
・バーチャルユーザとしたいメールアドレスは、バーチャルメールボックスドメインへ転送するように設定
main.cf にて、運用ドメインを、mydestination パラメータに設定します。
main.cf:
mydestination = example.net, ...
そして、バーチャルユーザ用に、バーチャル用ドメインをバーチャルメールボックスドメインとして設定します。
main.cf:
virtual_mailbox_domains = example.net.vmbox, ...
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
そして、バーチャルユーザは、バーチャルメールボックスドメインへ転送するように設定します。
virtual:
vusr@example.net vusr@example.net.vmbox
最後に、バーチャルメールボックス用の配送先を設定します。
vmailbox:
vusr@example.net.vmbox example.net.vmbox/vusr/
■ バーチャルメールボックスドメインとして運用する場合
運用ドメインを、バーチャルメールボックスドメイン （ローカルにはユーザを作らずバーチャルメールボックスに配送するドメイン） として運用する場合の方法です。
具体的な作戦は、以下の通りです。
・運用ドメインは、バーチャルメールボックスドメインとして設定
・ローカルユーザとしたいメールアドレスは、ローカルユーザに転送するように設定
main.cf にて、運用ドメインを、virtual_mailbox_domains パラメータに設定します。
main.cf:
virtual_mailbox_domains = example.net, ...
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
そして、ローカルユーザは、ローカルユーザに転送するように設定します。
virtual:
lusr@example.net lusr
Postfix のマニュアル的には、バーチャルメールボックスドメインとして運用して、ローカルユーザへ転送する方法を推奨しているようです。
Postfix であるドメインを運用するときに、
一部のユーザは、システムにアカウントを持つ実ユーザ (UNIX アカウント持ちユーザ)
他のユーザは、システムアカウントを持たないユーザ (バーチャルユーザ)
とする方法です。
方法は、二つほどあるようです。
■ 実ドメインとして運用する場合
運用ドメインを、実ドメイン （基本的にローカルにユーザを作成してそこに配送させるドメイン） として運用する場合の方法です。
具体的な作戦は、以下の通りです。
・運用ドメインは、実ドメインとして設定
・バーチャルメールボックス用のドメインを用意
・バーチャルユーザとしたいメールアドレスは、バーチャルメールボックスドメインへ転送するように設定
main.cf にて、運用ドメインを、mydestination パラメータに設定します。
main.cf:
mydestination = example.net, ...
そして、バーチャルユーザ用に、バーチャル用ドメインをバーチャルメールボックスドメインとして設定します。
main.cf:
virtual_mailbox_domains = example.net.vmbox, ...
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
そして、バーチャルユーザは、バーチャルメールボックスドメインへ転送するように設定します。
virtual:
vusr@example.net vusr@example.net.vmbox
最後に、バーチャルメールボックス用の配送先を設定します。
vmailbox:
vusr@example.net.vmbox example.net.vmbox/vusr/
■ バーチャルメールボックスドメインとして運用する場合
運用ドメインを、バーチャルメールボックスドメイン （ローカルにはユーザを作らずバーチャルメールボックスに配送するドメイン） として運用する場合の方法です。
具体的な作戦は、以下の通りです。
・運用ドメインは、バーチャルメールボックスドメインとして設定
・ローカルユーザとしたいメールアドレスは、ローカルユーザに転送するように設定
main.cf にて、運用ドメインを、virtual_mailbox_domains パラメータに設定します。
main.cf:
virtual_mailbox_domains = example.net, ...
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmailbox
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
そして、ローカルユーザは、ローカルユーザに転送するように設定します。
virtual:
lusr@example.net lusr
Postfix のマニュアル的には、バーチャルメールボックスドメインとして運用して、ローカルユーザへ転送する方法を推奨しているようです。
2010/05/09
BIND の設定あれこれ
一年近く放置していた File Server たち。
FreeBSD 7.2-RELEASE-p3 から、FreeBSD 8.0-RELEASE-p2 まで、一気に上げたのでした。
ちなみに、Gateway Server は、7.2-RELEASE-p2 だったりしたのでした （汗
さて。
昔から頭を悩ませてきた BIND の問題。
少し解決したので、そのことを。
■ 起動時に、
named[749]: the working directory is not writable
と叫ぶ。
□ 気にするこっちゃない！
named.conf で指定する directory のことですけれど。
普通は、/etc/namedb あたりが指定されていますよね。
このディレクトリの owner が root:wheel にされていて、bind が書けないから叫んでいるこの警告。
"programmer inflected useless warnings" （プログラマの屈折した役に立たない警告） だそうで、「書けなかったからって、それが何か？」 と言うスタンスでいいそうです。
＃ つまり、この警告は無視してよい
何回、手で owner を書き換えても root に戻されちゃうのは、BIND の起動時に、/etc/mtree/BIND.chroot.dist の指定で設定されるからです。
この機能を抑制するには、/etc/rc.conf に named_chroot_autoupdate="NO" を指定します。
んが。
セキュリティ上の理由でこの設定が採用されているので、こんなことはしない方がよいでしょう。
ましてや、/etc/mtree/BIND/chroot.dist を書き換えるなんて、以ての外です。
どーしても！ この警告を消したい方は、以下の対策をします。
１．working directory として、/etc/namedb/letskeepthisdirwritable を指定
２．/etc/namedb/letskeepthisdirwritable の owner を bind:bind にし、permission は 0755 に
３．named.conf の中のファイル指定を、全部相対パスに変更
ex) named.root -> ../named.root, master/empty.db -> ../master/empty.db
これで、この警告を消し去ることができます。
まぁ、面倒くさいので、この警告は無視した方がよいでしょうね。。。
■ Dynamic DNS を利用していると、
named[749]: dumping master file: master/tmp-hb9UYKWNAy: open: permission denied
などと叫ぶ。
□ Dynamic DNS の使い方が間違っている
間違っても、master/ ディレクトリの owner を変えたり、permission を変えたりしないように。
master/ ディレクトリの owner, permission は、やっぱり起動時に /etc/mtree/BIND.chroot.dist の指定で設定し直されます。
これも、やはりセキュリティ上の理由からです。
master server の設定は、外部から変更されないべきであるため、この設定となっています。
Dynamic DNS を使うときは、dynamic/ ディレクトリを使います。
つまり、こんな指定になります。
zone "example.org" {
type master;
allow-update {
key "exampleorgkey";
};
file "../dynamic/example.org";
};
■ Dynamic DNS を利用していると、
named[29217]: zone 'hogehoge' allows updates by IP address, which is insecure
などと叫ぶ。
□ なるべく TSIG (Transaction Signature) を使いましょうね
Dynamic DNS の update が可能な端末を IP Address だけで指定していると、こう言われます。
より secure に、TSIG を使って認証しなさい、と言う警告です。
TSIG が使えない環境の場合は、諦めるしかありませんねぇ。。。
クライアントが対応していないだけなら、DHCP server に DDNS 更新を依頼するといいかもしれません。
FreeBSD 7.2-RELEASE-p3 から、FreeBSD 8.0-RELEASE-p2 まで、一気に上げたのでした。
ちなみに、Gateway Server は、7.2-RELEASE-p2 だったりしたのでした （汗
さて。
昔から頭を悩ませてきた BIND の問題。
少し解決したので、そのことを。
■ 起動時に、
named[749]: the working directory is not writable
と叫ぶ。
□ 気にするこっちゃない！
named.conf で指定する directory のことですけれど。
普通は、/etc/namedb あたりが指定されていますよね。
このディレクトリの owner が root:wheel にされていて、bind が書けないから叫んでいるこの警告。
"programmer inflected useless warnings" （プログラマの屈折した役に立たない警告） だそうで、「書けなかったからって、それが何か？」 と言うスタンスでいいそうです。
＃ つまり、この警告は無視してよい
何回、手で owner を書き換えても root に戻されちゃうのは、BIND の起動時に、/etc/mtree/BIND.chroot.dist の指定で設定されるからです。
この機能を抑制するには、/etc/rc.conf に named_chroot_autoupdate="NO" を指定します。
んが。
セキュリティ上の理由でこの設定が採用されているので、こんなことはしない方がよいでしょう。
ましてや、/etc/mtree/BIND/chroot.dist を書き換えるなんて、以ての外です。
どーしても！ この警告を消したい方は、以下の対策をします。
１．working directory として、/etc/namedb/letskeepthisdirwritable を指定
２．/etc/namedb/letskeepthisdirwritable の owner を bind:bind にし、permission は 0755 に
３．named.conf の中のファイル指定を、全部相対パスに変更
ex) named.root -> ../named.root, master/empty.db -> ../master/empty.db
これで、この警告を消し去ることができます。
まぁ、面倒くさいので、この警告は無視した方がよいでしょうね。。。
■ Dynamic DNS を利用していると、
named[749]: dumping master file: master/tmp-hb9UYKWNAy: open: permission denied
などと叫ぶ。
□ Dynamic DNS の使い方が間違っている
間違っても、master/ ディレクトリの owner を変えたり、permission を変えたりしないように。
master/ ディレクトリの owner, permission は、やっぱり起動時に /etc/mtree/BIND.chroot.dist の指定で設定し直されます。
これも、やはりセキュリティ上の理由からです。
master server の設定は、外部から変更されないべきであるため、この設定となっています。
Dynamic DNS を使うときは、dynamic/ ディレクトリを使います。
つまり、こんな指定になります。
zone "example.org" {
type master;
allow-update {
key "exampleorgkey";
};
file "../dynamic/example.org";
};
■ Dynamic DNS を利用していると、
named[29217]: zone 'hogehoge' allows updates by IP address, which is insecure
などと叫ぶ。
□ なるべく TSIG (Transaction Signature) を使いましょうね
Dynamic DNS の update が可能な端末を IP Address だけで指定していると、こう言われます。
より secure に、TSIG を使って認証しなさい、と言う警告です。
TSIG が使えない環境の場合は、諦めるしかありませんねぇ。。。
クライアントが対応していないだけなら、DHCP server に DDNS 更新を依頼するといいかもしれません。
2010/02/10
WireShark on Mac OS X Snow Leopard
半年ほどサボっていました （＾＾；
ネタはあったんですけれども。
その間に、Mac mini を購入して、Mac ユーザになっていました。
さて、WireShark を入れたときにはまったので、記録。
WireShark のページや解説には、一通りの手順は載っています。
WireShark.app を適当なところ （たいていは、Applications フォルダ） に D&D します。
そして、Utilities フォルダの内容を、パスの通った場所にコピーします。
/user/local/bin とか、~/bin とか、/opt/wireshark/bin とか。
検索すると、みなさん /usr/local/bin に入れているみたいですが、Sun Microsystems の提唱に従って、/opt/wireshark/bin に入れてみました。
最後に、ChmodBPF フォルダを StartupItems にコピーしなきゃいけないんですが、ここで一つ躓きが。
再起動すると、「ChmodBPF のセキュリティ設定が不適切なため、起動しませんでした」 と表示されました。
どうやら、Leopard までならば、「セキュリティ設定を修正する」 という項目があるんですが、Snow Leopard には OK という項目があるのみ。
どうやって修正しましょうか、と悩みました。
他の項目などを見てみると、どうやら、owner を root:wheel にしないといけないようです。
chown してから再起動すると、問題なく起動しました。
Mac OS X の /Library/StartupItems/ の中身は、owner が root:wheel じゃないとだめらしい。
ということで。
ネタはあったんですけれども。
その間に、Mac mini を購入して、Mac ユーザになっていました。
さて、WireShark を入れたときにはまったので、記録。
WireShark のページや解説には、一通りの手順は載っています。
WireShark.app を適当なところ （たいていは、Applications フォルダ） に D&D します。
そして、Utilities フォルダの内容を、パスの通った場所にコピーします。
/user/local/bin とか、~/bin とか、/opt/wireshark/bin とか。
検索すると、みなさん /usr/local/bin に入れているみたいですが、Sun Microsystems の提唱に従って、/opt/wireshark/bin に入れてみました。
最後に、ChmodBPF フォルダを StartupItems にコピーしなきゃいけないんですが、ここで一つ躓きが。
再起動すると、「ChmodBPF のセキュリティ設定が不適切なため、起動しませんでした」 と表示されました。
どうやら、Leopard までならば、「セキュリティ設定を修正する」 という項目があるんですが、Snow Leopard には OK という項目があるのみ。
どうやって修正しましょうか、と悩みました。
他の項目などを見てみると、どうやら、owner を root:wheel にしないといけないようです。
chown してから再起動すると、問題なく起動しました。
Mac OS X の /Library/StartupItems/ の中身は、owner が root:wheel じゃないとだめらしい。
ということで。
2009/09/19
VPN してみよう （その１）
VPN をしてみようと思ったのです。
実家と自宅を VPN で結ぼうと。
実家にいるときに、自宅のファイルサーバのデータが欲しくなったりするんですよ。
自宅のメインマシンのデータとか。
ついでに、モバイル使用のノートからも VPN したいわけです。
FreeBSD で VPN というと、vtun がメジャーだったりします。
が、EuroBSDCon 2008 で、カナダのトロント大学で、OpenVPN で 3 万人に VPN を提供した、と言う発表があったようです。
ざっと探した限りでは、vtun か、OpenVPN か、地道に SSH か、と言う選択肢しか見つかりませんでした。
今回の目的は、自宅のネットワークと実家のネットワークを結び、ついでにモバイルからも接続できるようにする、です。
この目的にずばり答えてくれる選択肢を検討すると、
ネットワーク同士を結ぶ、と言う時点で SSH が消え、
ノートは Windows Vista と言う時点で vtun が消え、
結局 OpenVPN しかありませんでした。
＃ ネットワーク同士は vtun で結んで、ノートからは SSH しろ、とか言わないよーに （苦笑）
そんなわけで、導入です。
グローバルIP アドレス持ってる Gateway Server に OpenVPN をインストール。
インストールするのは、security/openvpn です。
security/openvpn-devel-2.1_r19 もあるのですが、まだ Release Candidate なので、採用を見送りました。
が、クライアントになるノートの方には、2.1RC を入れます。
理由は、2.1RC じゃないと、Windows Vista に対応していないからです。
2.1RC Client からも 2.0 Server には接続できるので、これで良し。
Windows 版は、プラムシステムズ （株） が日本語化しているので、以下の場所から落とします。
http://www.openvpn.jp/
なお、OpenVPN に関する日本語情報は、二箇所にあります。
http://freescitech.net/2/ OpenVPN の日本語情報
http://freescitech.net/2/wiki/ 上記の新しい Wiki
http://www.openvpn.jp/ プラムシステムズ （株）
ほぼ同じ情報が上がってます。
Server も Client も、インストールはお気軽です。
Server は portinstall openvpn するだけ。
Client は、zip 落としてきて、インストーラ実行するだけです。
さて、設定。
まず、サーバを仕込みます。
手順通りに作業します。（Server で作業）
最初は、Server/Client key pair に署名する認証局 (CA) を作ります。
手順書を見ると、/usr/local/share/doc/openvpn/easy-rsa/vars を編集しろ、と。
ここで、鍵を生成するようです。
ディレクトリが全然嬉しくない。。。
/usr/local/etc/openvpn/easy-rsa にしろよ。。。
さて、vars ファイルでは、設定しなければならない項目があります。
鍵に埋め込む Organization 情報です。
export KEY_COUNTRY=JP
export KEY_PROVINCE=TOKYO
export KEY_CITY=ADACHI-KU
export KEY_ORG="OpenVPN-NET"
export KEY_EMAIL="admin@example.com"
実家と自宅を VPN で結ぼうと。
実家にいるときに、自宅のファイルサーバのデータが欲しくなったりするんですよ。
自宅のメインマシンのデータとか。
ついでに、モバイル使用のノートからも VPN したいわけです。
FreeBSD で VPN というと、vtun がメジャーだったりします。
が、EuroBSDCon 2008 で、カナダのトロント大学で、OpenVPN で 3 万人に VPN を提供した、と言う発表があったようです。
ざっと探した限りでは、vtun か、OpenVPN か、地道に SSH か、と言う選択肢しか見つかりませんでした。
今回の目的は、自宅のネットワークと実家のネットワークを結び、ついでにモバイルからも接続できるようにする、です。
この目的にずばり答えてくれる選択肢を検討すると、
ネットワーク同士を結ぶ、と言う時点で SSH が消え、
ノートは Windows Vista と言う時点で vtun が消え、
結局 OpenVPN しかありませんでした。
＃ ネットワーク同士は vtun で結んで、ノートからは SSH しろ、とか言わないよーに （苦笑）
そんなわけで、導入です。
グローバルIP アドレス持ってる Gateway Server に OpenVPN をインストール。
インストールするのは、security/openvpn です。
security/openvpn-devel-2.1_r19 もあるのですが、まだ Release Candidate なので、採用を見送りました。
が、クライアントになるノートの方には、2.1RC を入れます。
理由は、2.1RC じゃないと、Windows Vista に対応していないからです。
2.1RC Client からも 2.0 Server には接続できるので、これで良し。
Windows 版は、プラムシステムズ （株） が日本語化しているので、以下の場所から落とします。
http://www.openvpn.jp/
なお、OpenVPN に関する日本語情報は、二箇所にあります。
http://freescitech.net/2/ OpenVPN の日本語情報
http://freescitech.net/2/wiki/ 上記の新しい Wiki
http://www.openvpn.jp/ プラムシステムズ （株）
ほぼ同じ情報が上がってます。
Server も Client も、インストールはお気軽です。
Server は portinstall openvpn するだけ。
Client は、zip 落としてきて、インストーラ実行するだけです。
さて、設定。
まず、サーバを仕込みます。
手順通りに作業します。（Server で作業）
最初は、Server/Client key pair に署名する認証局 (CA) を作ります。
手順書を見ると、/usr/local/share/doc/openvpn/easy-rsa/vars を編集しろ、と。
ここで、鍵を生成するようです。
ディレクトリが全然嬉しくない。。。
/usr/local/etc/openvpn/easy-rsa にしろよ。。。
さて、vars ファイルでは、設定しなければならない項目があります。
鍵に埋め込む Organization 情報です。
export KEY_COUNTRY=JP
export KEY_PROVINCE=TOKYO
export KEY_CITY=ADACHI-KU
export KEY_ORG="OpenVPN-NET"
export KEY_EMAIL="admin@example.com"
とかにしておきます。（実際には、ちゃんと入れてます）
書き換えたら、実行です。
手順書には、
. ./vars
./clean-all
./build-ca
ってやれ、って書いてあります。
・・・sh (Born Shell) ですね？
Linux が例に取られてるから bash だろうけど。
あたしゃ tcsh 使ってるのよー。
ついでに、clean-all にも build-ca にも実行ビットが立っていないので、仕方なく以下のように。
sh
. ./vars
sh ./clean-all
sh ./build-ca
. ./vars やると、clean-all やれ、って言われます。
./clean-all やっても何も言われないけど、./build-ca やるとガリガリ動いたあと、質問がいくつかなされます。
まぁ、属性設定項目を聞いてくるだけなんですが。
ほとんど ./vars で設定した内容がデフォルトで入っているので、そのまま Enter 押せばいいです。
が、一つだけ、設定しないといけない項目があります。
Common Name (eg, your name or your server's hostname) []:OpenVPN-CA
これだけは、適当に設定して下さい。
次に、Server の key pair を作ります。
sh ./build-key-server server
ここでも、Common Name は自分で設定しないといけません。
また、CA とも、あとから作成する Client とも、被ってはいけません。
まぁ、適当に server とかしておきます。
そして、次の二つの質問に yes と答えます。
Sign the certificate? [y/n] y
1 out of 1 certificate requests certified, commit? [y/n] y
これで Server の key pair 作成は完了です。
次に Client key pair を作成します。
今回は、2 つ （実家ネットワーク用とモバイルノート用） 作成します。
sh ./build-key jikka
sh ./build-key mobile
Common Name はユニークな物を付けて下さい。
まんま jikka, mobile と付けたことにします。
そして、Server と同じように、二つの質問に Yes と答えます。
これで鍵が出来ました。
鍵は全部、/usr/local/share/doc/openvpn/easy-rsa/ に出来てます。
公開鍵はともかく、秘密鍵が含まれますから、鍵は安全な方法でクライアントに持っていって下さい。
Client key は Client で作成して、CSR を提出して貰い、CA で署名して返す、と言う方法もあるのですが、めんどくさいのでしません。
というか、実家で鍵生成して、自宅に送って署名して持ってくる、って言うのがめんどくさいので。
次に、Diffie-Hellman パラメータを生成します。
sh ./build-dh
できたら、Server と Client に、それぞれコピーします。
Server には、
ca.crt
dh1024.pem
server.crt
server.key
を
実家には、
ca.crt
jikka.crt
jikka.key
を
ノートには、
ca.crt
mobile.crt
mobile.key
を
それぞれコピーします。
Server は、/usr/local/etc/openvpn/keys に置きました。
実家は同じ場所に。
ノートは、D:\Win32Apps\OpenVPN\keys に置きました。
これで、鍵の準備が整いました。
次に設定ファイルの編集です。
まずは Server から。
/usr/local/share/doc/openvpn/sample-config-files にサンプルがあるので、ここからコピーして編集します。
使うのは server.conf です。
まず Local IP Address の指定 （いっぱい IP Address が Alias してあるので）
local aaa.bbb.ccc.ddd
ポートは、デフォルトの 1194 のままです。
プロトコルも、デフォルトの udp にします。
＃ TCP も実装されているが、TCP-over-TCP 問題などがあり、UDP の方がよいとのこと
いろいろググったら、みんな Bridge モードで使ってるらしかったのだけれど、今回はネットワーク同士を繋ぐ必要があるので、ルーティングモードで使います。
なので、device は tun のままです。
そして、鍵の位置を指定します。
ca keys/ca.crt
cert keys/server.crt
key keys/server.key # This file should be kept secret
皆さんフルパスで書いているんですが、OpenVPN は、起動時にワークディレクトリの指定が出来るので、そこからの相対パスにしました。
Diffie-Hellman パラメータの位置も指定します。
dh keys/dh1024.pem
VPN の IP Address の設定は、デフォルトのままにしました。
server 10.8.0.0 255.255.255.0
この 10.8.0.0/24 というのは、Server 側 LAN の IP Address とも、Client の IP Address とも被らない設定にしないといけません。
192.168.0.0/16 あたりは、公衆サービスなどで使われている可能性があるので、要注意です。
マニュアルによれば、10.0.0.0/8 の真ん中あたりから取ってくれば、大丈夫じゃないかなぁ？ だそうです。
さて、今回はネットワーク同士を繋いで、シームレスに使えることを目的としているので、お互いのネットワークを広告して、ルーティングさせなきゃいけません。
なので、広告のために、次の設定をします。
push "route 自宅ネットワーク ネットマスク"
push "route 実家ネットワーク ネットマスク"
これで、広告されるそうです。
実家に繋がったら、ルーティングしないといけません。
実家から接続されたときに反応しないといけないので、client-config-dir を設定します。
client-config-dir ccd
ccd と言うディレクトリは、Server 実行時に存在しないといけません。
なので、/usr/local/etc/openvpn/ccd を作ります。
そして、ルーティングの設定を入れます。
route 実家ネットワーク ネットマスク
このほかに、実家から接続されたときの設定を ccd ディレクトリに作成します。
Client 名のファイルを作成し、ルート設定を入れます。
/usr/local/etc/openvpn/jikka:
iroute 実家ネットワーク ネットマスク
お互いにルーティングしないといけないので、冗長なようでも両方指定しろ、と書いてあります。
さて、server.conf の続き。
いるかどうか分からなかったのだけれど、一応 DNS と WINS を広告します。
push "dhcp-option DNS DNS-Server-IP-Address"
push "dhcp-option WINS WINS-Server-IP-Address"
そして、VPN の中で、他のクライアントマシンとも通信できるようにしたいので、以下の設定を入れます。
client-to-client
これを入れておかないと、各 Client は、Server しか見られません。
まぁ、これが必要なのは、モバイルノートから実家が見たい、とかの場合だけでしょうけれど。
あと、Server は FreeBSD なので、セキュリティのために以下の設定を有効にします。
user nobody
group nobody
こんなところで、Srver の設定は完了です。
Firewall に穴を開けて、Server を起動します。
とその前に、rc.conf に設定を。。。
#-- OpenVPN Settings --
openvpn_enable="YES"
openvpn_configfile="/usr/local/etc/openvpn/server.conf"
openvpn_dir="/usr/local/etc/openvpn"
これで、/usr/local/etc/rc.d/openvpn start すれば、動き出します。
Sat Sep 19 16:07:15 2009 OpenVPN 2.0.6 i386-portbld-freebsd7.2 [SSL] [LZO] built on Sep 19 2009
Sat Sep 19 16:07:15 2009 Diffie-Hellman initialized with 1024 bit key
Sat Sep 19 16:07:15 2009 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sat Sep 19 16:07:15 2009 TUN/TAP device /dev/tun0 opened
Sat Sep 19 16:07:15 2009 /sbin/ifconfig tun0 10.8.0.1 10.8.0.2 mtu 1500 netmask 255.255.255.255 up
Sat Sep 19 16:07:15 2009 /sbin/route add -net 10.8.0.0 10.8.0.2 255.255.255.0
add net 10.8.0.0: gateway 10.8.0.2
Sat Sep 19 16:07:15 2009 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Sat Sep 19 16:07:15 2009 GID set to nobody
Sat Sep 19 16:07:15 2009 UID set to nobody
Sat Sep 19 16:07:15 2009 UDPv4 link local (bound): 202.229.46.99:1194
Sat Sep 19 16:07:15 2009 UDPv4 link remote: [undef]
Sat Sep 19 16:07:15 2009 MULTI: multi_init called, r=256 v=256
Sat Sep 19 16:07:15 2009 IFCONFIG POOL: base=10.8.0.4 size=62
Sat Sep 19 16:07:15 2009 IFCONFIG POOL LIST
Sat Sep 19 16:07:15 2009 Initialization Sequence Completed
とかログが出れば成功です。
さて、次は Client です。
実家にはまだ帰っていないので、実家の設定は試せません （だから、その１なの）
というわけで、モバイルノートの設定をします。
sample-config-files の client.conf を下地にします。
というか、Windows 版なので、client.ovpn ファイルですね。
設定をいじるのは、remote 指定です。
ここで、OpenVPN Server を指定します。
remote Server-IP-Address 1194
1194 は、ポート番号です。
鍵の位置も指定しなきゃなりません。
ca d:\\win32apps\openvpn\\keys\\ca.crt
cert d:\\win32apps\openvpn\\keys\\mobile.crt
key d:\\win32apps\openvpn\\keys\\mobile.key
実行時ディレクトリを指定する方法が分からなかったので、フルパス指定です。。。orz
\ は、エスケープして書かないといけないそうです。
あとは、他の設定項目が Server と合っているかを確かめましょう。
ポート設定 (1194)、プロトコル (udp)、comp-lzo あたりを入念に。
これで設定は終わりです。
さっそく、繋いでみましょう。
Server の時と似たようなログが表示されれば、接続完了です。
Windows Vista だと、route 追加に失敗して、パラメータが間違っています、とか言うエラーが出ます。
結局、route.exe にお願いして、ルート設定しているようです。
心配なら netstat -r すること。
さて、最初、Samba に接続できなくて焦りました。
当たり前です。
Samba の設定を直さなきゃいけません。
今回の設定では、10.8.0.0/24 のネットワークから参照があるので、これを待ち受けないといけません。
hosts allow = 自宅ネットワーク 127.0.0.0/8 10.8.0.0/24
とかします。
これで、繋がるようになりました。
・・・\\Server-LAN-IP-Address\共有名 とかしないと繋がらないのはなんでだろう。
DNS 引けてるのに、\\サーバ名\共有名 じゃ、繋がらないんだよね。
まぁ、IP Address 指定すれば使えるからいいけど。
これは、先送りだなぁ。
さて、実家のネットワークと繋ぐことは出来るでしょうか。
楽しみ。
登録:
投稿 (Atom)