PFでNAT64 - OpenBSD 5.1
NAT64とは、DNS64と組み合わせることにより、IPv6 onlyネットワークからもIPv4のサービスにアクセスできるようにする機能のこと。これをサーバ上で実現する方法としては、
がある。今回はPF (OpenBSD 5.1)を使った。
以下、上記それぞれについて少々。
linuxnat64
linuxnat64はちょっと前までsourceforgeから利用可能だったみたいですが、今はなくなってしまいました。探してみたところ、簡単には見つからないみたいです。私は、知り合いからソースコードを貰いました。少なくとも、Ubuntu 10.04.3 x64では動くみたいです。
Ecdysis (linux)
Ecdysis: open-source nat64から利用可能です。ただ、ネット上や知人からの情報だと、linuxではうまく動かない(tcp seqがずれたり、chksumがおかしかったりpayloadが壊れたり)という噂を聴いたので不安になりました。
実際にインストールしてみたところだと、はじめはping6は通るけど、wgetが時々失敗するという現象に遭遇しました。しばらくすると安定して動き始めたのですが、不具合の原因はいまいちわかっていません。うまく動くこともあるようです。
Ecdysis (pf patch for OpenBSD 4.6)
すでにkernel patch済なisoがEcdysis: open-source nat64の最下にあります。これは導入しやすそうな気がしますが、試していません。
Tayga
これはstatelessなNAT64で、今回の要件にマッチしていないので使いませんでした。stateless NATというのは、変換前のIPアドレスと変換後のIPアドレスが1対1対応するとかなんだかそういう感じだったと思います。
NAT64の設定
OpenBSD 5.1のセットアップ
インストーラisoはOpenBSD: Mirrorsから辿ると落とせます。私は、http://ftp.jaist.ac.jp/pub/OpenBSD/5.1/amd64/のinstall51.isoを使いました。
OpenBSD FAQ: Installation Guideこのへんでも見るといいです。インストーラの指示に従うだけですが、Ubuntuしかインストールしたことない人にとってはちょっと難しいかもしれません。
この辺はもしかすると少しはわかりやすいかもしれない。OpenBSDのインストール方法詳細メモ(1) - 情報科学屋さんを目指す人のメモ(FC2ブログ版)
NICの設定
用意すべきは
です。これらが確保できたら、 /etc/hostname.
# vi /etc/hostname.em0
inet 192.0.43.10 255.255.240.0 inet6 2001:500:88:200::10 64 !route add -net default 192.0.43.1 !route add -inet6 default 2001:500:88:200::1
192.0.43.10はNAT64をするマシンのIPv4アドレス
2001:500:88:200::10はそのIPv6アドレス
192.0.43.1はNAT64マシンがいるセグメントのdefault gateway
2001:500:88:200::1もdefault gateway
意味を考えて、適宜自分の環境にあわせて読み替えてください。
/etc/hostname.
# /etc/netstart
で設定を反映。
pfの設定
デフォルトでは/etc/pf.confが設定ファイルです。
# vi /etc/pf.conf
これに以下のような行を追加してください。
# nat64 pass in quick inet6 to 2001:500:88:200::10 pass in quick inet to 192.0.43.10 pass in inet af-to inet6 from 2001:500:88:200::10 to 2001:500:88:ff64::/96 pass in inet af-to inet6 from 2001:500:88:200::10 pass in inet6 af-to inet from 192.0.43.10 to 0.0.0.0/0 pass in inet6 af-to inet from 192.0.43.10
ただし、これをやると他のインターフェースにも影響を与えるかもしれないので、
set skip on em1
でルール適用除外したり、af-toルールの適用条件に on em0 加えるなどして調整してください。
各行の意味は、
- 64変換すべきではない、自分(NAT64マシン)宛のパケットは自分の方に受理してあとの64変換ルールを適用しない
- 同上
- 2001:500:88:200::10に設定されたインターフェースに2001:500:88:ff64::/96宛のパケットが届いたら、宛先アドレスの下位32ビットからIPv4アドレスを取り出し、そのIPv4アドレス宛てのパケットへと変換する(NAT64の動作)
- ようわからん
- 192.0.43.10に設定されたインターフェースに届いたパケットの送信元IPv4アドレスを2001:500:88:ff64::の下位32ビットに埋め込み、IPv6パケットにに変換する(NAT64の動作)。
- ようわからん。
ちなみに、2001:500:88:ff64::/96はNAT64の変換用プレフィックス
こんな感じで動いています。af-toっていうのが肝心ですね。私にはよくわかっていない部分もあります。
気になる人は、OpenBSD manual pagesでも見てください。
2013/02/24 追記
現在検証したところ, pf.confはもっとシンプルに書けるようです。
# vi /etc/hostname.em0
inet6 2001:0DB8:100::2 64
# vi /etc/hostname.em1
inet 192.0.2.2 255.255.255.240
# vi /etc/pf.conf
pass in quick inet to 192.0.2.2 pass in quick inet6 to 2001:0DB8:100::2 pass in inet6 from any to 2001:0DB8:64::/96 af-to inet from 192.0.2.64/28 to 0.0.0.0/0
この例では, nat64マシンの
- 実IPv4アドレスが192.0.2.2/28
- 実IPv6アドレスが2001:0DB8:100::2/64
- nat64変換先IPv4アドレスプールが192.0.2.64/28
- nat64変換元IPv6プレフィックスが2001:0DB8:64::/96
という条件下でnat64トランスレーションを行なっています。
/etc/pf.confの各行の意味は,
- 実IPv4アドレス宛のパケットには変換ルールを適用せずにnat64マシンが受け取る
- 実IPv6アドレス宛のパケットには変換ルールを適用せずにnat64マシンが受け取る
- 送信元IPv6アドレスが任意で, 送信先IPv6アドレスが2001:0DB8:64::/96 (変換元プレフィックス) のIPv6パケットは, 宛先IPv6アドレスの下位32bitに埋め込まれた本来の(designated)宛先IPv4アドレスを取り出し, 宛先IPv4アドレスを抽出したIPv4アドレスに, 送信元アドレスを192.0.2.16/28 (変換先アドレスプール)のいずれかのアドレスに変換して転送する
と言ったところです。pfのnat64はステートフルなので, inet6 (IPv6) -> inet (IPv4)の変換ルールを書いておけば, NATテーブルを参照することで戻り(inet -> inet6)の変換も行えることから, 特にinet -> inet6の変換ルールを明記する必要性はありません。
あとはルーターには2001:0DB8:64::/96のnext-hopを2001:0DB8:100::2とする経路を書いておけば, nat64が使えるはずです。
追記ここまで
設定が書けたら、
# pfctl -Fa -f /etc/pf.conf
でルール適用。基本的にはこれで完成です。
実際にこのNAT64を使うためには、
- DNS64を建て
- DHCPv6にDNS64の設定を入れ
- ルーターで2001:500:88:ff64::/96プレフィックスのNext hopをNAT64機(2001:500:88:200::10)へ向ける
といったことが必要になるはずですね。他にも必要な作業が抜けているかもしれないですけど、気づいた方はご指摘ください。
ここ最近便利だと思ったもの
Visitors
まぁ、Google Analyticsとかでもアクセス解析はできるんですけど、ローカルでちょちょっと解析したい時に。
Ubuntuなら
sudo aptitude install visitors
でインストールできて、
visitors -A -m 30 access.log -o html > report.html
で生成したファイルをブラウザに放り込むだけ。1時間あたりのアクセスとかがさくっと出せていいです。
ここに書いてありました。
iPhoneのホームボタンが効かなくなったときに...
- 電源ボタンを長押しして、電源を切るスライドを表示させる
- ホームボタンを「いつもの強さで」長押しし続ける
- スライドが消えたら、完了
恐らく、この2の操作でホームボタン押下の強度キャリブレーションを行っているようです。
ここに書いてありました
openx - 広告配信システム
これをサーバーにインストールすると、広告配信ができます。なんかちょっと複雑なので説明するのはめんどくさい。
ここに書いてありました
他にもいろいろ便利だと思ったものはありますが、またの機会に。
ネットワーク性能監視ツールを作ってみるか
昨日から寮内でのInternetブラウジングがちょっと遅いらしい。
原因はまだ分かっていないが、とりあえず定量的にネットワークの各種性能を計測して可視化するツールは必要だろうという。
そこで、何かあるならそういうツールをインストールするか、無ければツールを自分で作ろうと思う。
必要な監視項目は
・turn around time
・bandwidth
・dns lookup time
寮内(同セグ)を含む、いくつかのリモートホストに対して、上記項目を計測し、グラフ化することが要件だろうと思う。
で、たまにチェックして極端に数値が落ちていれば、更に細かい調査をしてパフォーマンス改善をしようと思う。作ったらまた書きます。
もしや、Xymonとかでできるかな?
ハンドガンのアンダーレールに着けられる市販フラッシュライトをやっと見つけた。→Hi-Capa 5.1 Match Custom + Gentos 閃 SG-325 + マルイマウントリングM
結論から申しますと、
東京マルイの「ハイキャパ 5.1 マッチカスタム」には、
マルイの「マウントリングM」と「Gentos 閃 SG-325」が取り付けられる。
輝度や固定の具合は十分で、BF3のフラッシュライトのように
相手の目を眩ませることはできるぐらいという状況です。
今回のカスタムに掛かった金額はおおよそ3000円です。
私の中でエアガン/ガスガンブームがにわかに巻き起こっています。
男なんだから仕方ないでしょう。
で、この前東京マルイの「Hi-Capa 5.1 Match Custom」を購入したわけですが、
いろいろカスタムしたくなるのが常ってもんです。
案の定、私もフラッシュライトを着けてみようと思い立ちました。
Hi-Capa 5.1系はどれもアンダーレールを取り付けることができます。
(買った箱の中にレールとねじと簡易ポンチが入っています)
で、このレールにマルイのNo115 マウントリングMと市販のフラッシュライトを
組み合わせてカスタムしようとしたわけですが、
このフラッシュライト選びで少々試行錯誤があったため、ここに記しておきます。
初め、家にあった適当なLEDライトを着けてみましたが、ライトの外径が合わず無理でした。
購入したマウントリングは内径が標準的な1インチ(2.54cm)になっています。
そこで、割と短く輝度も高くて外径が1インチのフラッシュライトを探しました。
調べていくと、概してホビーガンのアタッチメント志向のフラッシュライト製品は値段が高いこと、
Gentosとか言うドンキホーテで売ってるようなフラッシュライトはコスパがいいことがわかってきました。
(巷にはライトの性能とかを比較しまくっているライトマニアなる者がいるらしいですね。)
で、近所のピカソ(ドンキホーテ系)に行って、いろいろ比較したわけです。
その結果、まず「Gentos Dominator DC-100F」を購入しました。が、外径がでかすぎて1インチマウントリングに
着けることができない...
泣く泣くDominatorは緊急災害時の家のストック用にまわすことにしました。(Dominatorは3000円ぐらいした。)
で、ライトを比較しているホームページ等でもよく出てきていた「Gentos 閃」がDominator同梱のカタログチラシに
乗っていました。どうやらこれはDominatorよりも外径が小さく、1インチ用マウントにも何とか乗せられるという
情報も手に入りました。で、Amazonでポチりました。
結果としては、ほぼ完璧。色が微妙かも知れんけど。
というわけで、写真と使用感を、同じようなことをしようとしている人は
参考にしていただけると幸いです。
ちなみに、Hi-Capa 5.1 Match Customを選んだ理由は、
ほかのマルイ製ガスブローバックと比較して初速、精度等の性能がよかったため、
またカスタム用のパーツが多く出ていてカスタムしやすいためです。
ネット上の情報を掻き集めた結果の判断です。
ただ、Hi-Capaは渋さが足りないのも事実。M1911A1とか欲しいと思ったりしています。
Ubuntuでvncサーバを立てる際にinetdを設定しようとしてハマっていた。解決策。
UbuntuでVNCサーバを建てようと思った。
とりあえず、こうやったらうまくいった。
sudo aptitude install vnc4server openbsd-inetd
/etc/inetd.confに以下の行を追加
vnc stream tcp nowait nobody /usr/bin/Xvnc Xvnc -inetd -query 192.168.1.2 -once -geometry 1024x768 -depth 16 -SecurityTypes None
/etc/serviceに以下の行を追加
sudo service openbsd-inetd restart
で再起動して動くようになるはず。(たぶん)
inetd経由でvncserverを起動する - redstorm - 徒然雑記
とか参考にしていたのだが、代理デーモン系(?)のサービスにはxinetd、inetdがあるみたい。
で、
xinetd
inetutils-inetd
等のパッケージを入れて試したのだが、Ubuntuではうまくいかなかった。
(たぶん僕の環境のUbuntuじゃ無ければうまく行く)
で、openbsd-inetdを入れてみたらうまく行ったというわけ。
鉄騎(XBox無印)のコントローラをWindows 7 x64で使うために、Windowsデバイスドライバを自作してみようと思うからその為に必要な知識などを蓄積していく鉄騎(XBox無印)のコントローラをWindows 7 x64で使うために、Windowsデバイスドライバを自作してみようと思うからその為に必要な知識などを蓄積していく
鉄騎(XBox無印)のコントローラをWindows 7 x64で使うために、Windowsデバイスドライバを自作してみようと思うからその為に必要な知識などを蓄積していく
Windowsドライバ作ろうと思ってなんとなくネット上をうろついて情報収集していたのだが、
一度体系立ててドライバ自作の知識などをまとめた方がいいだろうと思ってまとめてみるのである。
けど、一気にまとめる時間はないので、
最初は箇条書きみたいになるかも。
OS: Windows 7 Professional 64bit
使いたいもの: 鉄騎コントローラ
vtchidというドライバがある。
古い。
Windows XP x86用しかない。
ソースコードは手に入る。
Cygwin環境でコンパイルしてみたが動かなかった。
もしかするとinfファイルの書き方がまずいか?
vtchidはgccツールチェーンのクロスコンパイラ機能を使ってコンパイルする。
Cygwinのgccは、Cygwin依存ライブラリ等をリンクするので、バイナリをWindowsに持ってきても動かない。
→gcc -mno-cygwinというオプションを付けることで、Cygwin依存ライブラリは使わず、Windowsネイティブで動くバイナリを生成できる。
これを使ってコンパイルした。ちなみに、現在のgccはバージョン4.xxで、gcc -> gcc-4というシンボリックリンクになっている。
gcc-4は-mno-cygwinオプションを受け付けず、これを付けた場合は、専用のクロスコンパイラを使え(amd64-mingw32msvc-gccを使えということ?)と言われる。
元々のvtchidのソースを、変更なくコンパイルするために、gccのシンボリックリンクをgcc-3に貼り直した。これでコンパイルで来てたはず。Cygwin環境でなく、Linuxならupdate-alternativeでシンボリックリンクを張り替える。
こうしてコンパイルしたものもまだ動いておらず、現在残されている選択肢は、
1. クロスコンパイラを使ってコンパイルしながら、ターゲットOSで動くようにトラブルシューティングをする
2. WDK(Windows用ドライバ作成ツールチェーン・環境)を使ってコンパイルできるコードに書き直す
である。
1.でトラブルの原因となっていると考えられる点は
・infの書き方違う
・クロスコンパイラの使い方が間違っている。具体的には、Windows7 x64で使えるバイナリが生成できていない
・コード自体がダメ。Windows 7 x64では動かない
のどれか。ドライバインストール時の挙動からして「infの書き方が正しくない」説が濃厚だが、他の原因も併発している気がする。
ということで、最初に必要なのは、どちらにしろinfの書き方を調べなければならない。
とりあえず、infの書き方を調べる。