このドキュメントのほとんどについては、あらかじめこの FAQ の カーネルの設定とセットアップ と ifconfig(8) および netstat(1) man ページを通読して、ある程度理解してもらっていると話がずっとはやい。
あなたがネットワーク管理者で、ルーティングプロトコルの設定をしていたり、OpenBSD をルータとして使うつもりだったり、IP ネットワーキングをつっこんでやるつもりなら、本気で Understanding IP addressing を読んでほしい。これはすばらしいドキュメントなのだ。Understanding IP addressing には、IP ネットワークで作業をするときの基盤となる、根本的な知識がつまっております!
Webサーバやftp サーバ、メールサーバなんかのアプリケーションで作業をするなら、RFCを読むととっても役に立つかもしれない。もちろん、全部なんか読めやしない。だから、興味ある話だけをつまみ喰いするとか、あるいは自分が作業環境でつかうものだけ目を通しておくといい。調べて、どういう動作が意図されているのかを知っておくこと。RFC はインターネットのプロトコルをたくさん(何千も)定義していて、それがどう機能するべきかも記述している。
まず手始めに、自分のネットワークインターフェースがなんだかつきとめよう。OpenBSD では、インターフェースはカードの種類に応じて名前がついている。ネットワーク接続の種類に応じてではない。ネットワークカードは、起動時に初期化されているのがわかるし、ブート後でも dmesg(8) コマンドを使うとそれが見られる。さらに ifconfig(8) コマンドを使うと、ネットワークカードのことがわかる。たとえばここに、ne2000 ネットワークカードについて dmesg からの出力がある。デバイス名は neとなっている。
ne3 at pcmcia1 function 0 "Linksys, EtherFast 10/100 PC Card (PCMPC100), " port 0x340/16 irq 9 ne3: address 00:e0:98:04:95:ba
デバイス名がわからなければ、以下によくあるカードとそのデバイス名を挙げておこう:
またもや、ifconfig(8) ユーティリティを使えばどのデバイスが認識されたかチェックできる。たとえば以下の出力例では、ne2000 デバイスが示されている。
$ ifconfig -a lo0: flags=8009<UP,LOOPBACK,MULTICAST> inet 127.0.0.1 netmask 0xff000000 lo1: flags=8008<LOOPBACK,MULTICAST> ne3: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> media: Ethernet manual inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255 sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> sl1: flags=c010<POINTOPOINT,LINK2,MULTICAST> ppp0: flags=8010<POINTOPOINT,MULTICAST> ppp1: flags=8010<POINTOPOINT,MULTICAST> tun0: flags=10<POINTOPOINT> tun1: flags=10<POINTOPOINT> enc0: flags=0<> bridge0: flags=0<> bridge1: flags=0<>
ここでわかるように、 ifconfig(8) はこの時点でぼくたちに必要な情報よりずっといっぱい情報を返してくれる。でもインターフェースはこれで見ることができる。上の例では、インターフェースカードはもう設定済みだ。これは "inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255" にすでに数値が入っていることからもわかるし、 UP と RUNNING フラグがオンになっていることからもわかる。さらに、ほかにもいろいろインターフェースが表示されている。ここで出てきてもかまわないインターフェース一覧を以下に挙げよう:
もしインターフェースの設定がすんでいないなら、まず手始めに、/etc/hostname.${IF} ファイルをつくることだ。 ${IF} にはきみのインターフェースの名前が入る。上の例の情報の場合だと、この名前は /etc/hostname.ne3 だ。このファイル形式は以下の通り:
[アドレスファミリー] [きみのip] [ネットマスク] [メディアオプション]
だから上の例だと、まともなファイルはこんな感じだ:
$ cat /etc/hostname.ne3 inet 10.0.0.38 255.255.255.0 NONE
このファイルの形式について詳しくは hostname.if(5) man ページを参照のこと。
次のステップは、ゲートウェイの設定だ。これは簡単で、ゲートウェイの IP を /etc/mygate ファイルに書けばすむ。これで起動時に、ゲートウェイが設定される。次に、ネームサーバ(DNS) と /etc/hosts ファイルを設定しよう。DNS の設定には、/etc/resolv.conf というファイルをつくる。このファイルの形式について詳しくは resolv.conf(5) man ページを見て欲しい。でもふつうに使うには以下の例のようにすればすむ。ここでの例では、DNS は 125.2.3.4 と 125.2.3.5 だ。さらにきみは、 "yourdomain.com"というドメインに所属している。
$ cat /etc/resolv.conf search yourdomain.com nameserver 125.2.3.4 nameserver 125.2.3.5 lookup file bind
このファイルを書いたら、再起動するか、あるいは /etc/netstart スクリプトを実行しよう。これには root になって、次のようにタイプすればいい:
$ sh /etc/netstart writing to routing socket: File exists add net 127: gateway 127.0.0.1: File exists writing to routing socket: File exists add net 224.0.0.0: gateway 127.0.0.1: File exists
いくつかエラーが出たのがわかるだろう。でもこれはループバックインターフェースがらみのものだ。だから無視してだいじょうぶ。これで、きみのシステムは見事に動いていることになる。もう一度、インターフェースがまともに設定されているかを ifconfig(8) で確かめよう。さらにルーティングの経路を netstat(1) か route(8) で調べることもできる。両方のコマンドでルーティングテーブルを見てみた例を以下に示す:
$ netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Mtu Interface default 10.0.0.1 UGS 0 86 - ne3 127/8 127.0.0.1 UGRS 0 0 - lo0 127.0.0.1 127.0.0.1 UH 0 0 - lo0 10.0.0/24 link#1 UC 0 0 - ne3 10.0.0.1 aa:0:4:0:81:d UHL 1 0 - ne3 10.0.0.38 127.0.0.1 UGHS 0 0 - lo0 224/4 127.0.0.1 URS 0 0 - lo0 Encap: Source Port Destination Port Proto SA(Address/SPI/Proto) $ route show Routing tables Internet: Destination Gateway Flags default 10.0.0.1 UG 127.0.0.0 LOCALHOST UG localhost LOCALHOST UH 10.0.0.0 link#1 U 10.0.0.1 aa:0:4:0:81:d UH 10.0.0.38 LOCALHOST UGH BASE-ADDRESS.MCA LOCALHOST U
OpenBSD マシンをゲートウェイ(またの名をルータ)として設定するための基本情報を以下に挙げよう。もし OpenBSD をインターネットの上のルータとして使うなら、この次に出てくる IP フィルタの設定も読んで、悪意あるトラフィックをブロックできるようにしておくようお奨めする。さらにネットワークのプロバイダや地域登録機関からの IPv4 アドレスが足りなくなってきているので、ネットワークアドレス変換(Network Address Translation, NAT) のところも読んで、IP アドレス空間を節約しよう。
GENERIC カーネルはすでに、IP フォワーディングの機能が組み込んであるけれど、これを有効にしてやる必要がある。これには sysctl(8) ユーティリティを使おう。これを永続的に変えるには、 /etc/sysctl.conf ファイルを編集して IP フォワーディングを有効にしよう。このためには、設定ファイルに以下の一行を追加する。
net.inet.ip.forwarding=1
再起動せずにこれを反映させるには、sysctl(8) ユーティリティを直接使えばいい。このコマンドだけだと、再起動すると消えてしまうし、あとこのコマンドはroot でないと実行できない。
# sysctl -w net.inet.ip.forwarding=1 net.inet.ip.forwarding: 0 -> 1
さあ両側のほかのホストのルーティング経路を変更しよう。OpenBSD をルータとして使うなら、可能性はいろいろある。たとえば routed(8), gated, mrtd, zebraみたいなソフトが使える。 OpenBSD は ports コレクションで、 gated も mrtdもサポートしている。 OpenBSD は各種の T1, HSSI, ATM, FDDI, Ethernet, シリアル (PPP/SLIP) インターフェースをサポートしている。
OpenBSD は、インターフェースのエイリアスを設定するのに単純な仕組みを使っている、/etc/ifaliases ファイルを書き換えればいいのだ。このファイルは起動時に /etc/rc スクリプトに読み込まれる。このファイルは rc 起動ヒエラルキー の一部だ。たとえばユーザがdc0というインターフェースを持っていて、192.168.0.0 ネットワーク上にいるとしよう。その他重要な情報として:
/etc/ifaliasesファイルはこんな形式だ:
[interface] [ip address] [netmask]
エイリアスについてちょっと述べておく。OpenBSD では、インターフェース名しか使わない。最初のエイリアスと二番目のエイリアスには何のちがいもない。ほかの OS とはちがって、 OpenBSD は dc0:0, dc0:1 といった参照はしない。もし特定のエイリアスになった IP アドレスを ifconfig で参照していたり、エイリアスを追加したりするときには、コマンドラインで単に"ifconfig int"とするのではなく、必ず "ifconfig int alias" とやるように。エイリアスの削除は、 "ifconfig int delete"だ。
エイリアスと同じ IP サブネット内にいる複数の IP アドレスを使っているものとしよう。各エイリアス用のネットマスク設定は 255.255.255.255 になる。 インターフェースに割り当てた最初の IP のネットマスクに従う必要はない。この例の /etc/ifaliases では、二つのエイリアスが dc0 デバイスにわりつけられていて、ちなみにそのデバイスは、192.168.0.2 でネットマスクが 255.255.255.0という設定になっている。
$ cat /etc/ifaliases dc0 192.168.0.3 255.255.255.255 dc0 192.168.0.4 255.255.255.255
ここで全ビットが 1 のネットマスクを使っているのは、同じネットワークについて二重のルーティングテーブル記述がつくられないようにするためだ。
NOTE:
OpenBSD 2.7 以降では、エイリアスの設定を /etc/hostname.* ファイルでやることもできる。上と同じ設定をするには、/etc/hostname.dc0 ファイルをつくろう。以下のような感じだ:
inet 192.168.0.2 255.255.255.0 media 100baseTX inet alias 192.168.0.3 255.255.255.255 NONE inet alias 192.168.0.4 255.255.255.255 NONE
このファイルができたら、それを反映させるには再起動するしかない。でも、ifconfig(8) ユーティリティを使えばエイリアスを手動で起動できる。最初のエイリアスを起動するには、次のコマンドを使う:
# ifconfig dc0 inet alias 192.168.0.3 netmask 255.255.255.255
これらのエイリアスを見てみるには、以下のコマンドを使うこと:
$ ifconfig -A dc0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> media: Ethernet manual inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 inet 192.168.0.3 netmask 0xffffffff broadcast 192.168.0.3
IP フィルタパッケージは、二つのタスクをこなすように作られている。パケットレベルでのフォワーディング許可を扱うこと (ipf(8)) と、外部アドレスに対してホストやサブネットをマッピングすること(ipnat(8))だ。この二つのサービスの設定ファイルは、それぞれ /etc/ipf.rulesと /etc/ipnat.rulesになる。
これらを起動時に有効にするには、/etc/rc.conf を編集してやろう。さらに /etc/sysctl.conf ファイルの中で、net.inet.ip.forwarding=1 となっている必要がある(あるいはカーネルで IPFORWARDING or GATEWAY オプションを有効にしておくこと)。さらにカーネルのコンパイル時に、 IPFILTER と IPFILTER_LOG もオンにしてある必要がある(GENERIC カーネルは、これらのオプションをオンにしてある)。
カーネルに IP フィルタがコンパイルしてあるのに、/etc/rc.conf ファイルで有効にしていない場合には、簡単に有効にしてやれる。
# ipf -Fa -f /etc/ipf.rules -E # ipnat -CF -f /etc/ipnat.rules
ipf の -E フラグはIP フィルタを「有効に」する。-Fa は、そこにあるルールをすべて無効にする。-f /etc/ipf.rules は、 /etc/ipf.rulesからルールを読み込む。
ipf のロード後に /etc/ipf.rules をいじったら、それを反映させるのは実に簡単!
# ipf -Fa -f /etc/ipf.rules
ipnatでも話は同じで……
# ipnat -CF -f /etc/ipnat.rules
さらにデバッグように ipmon も有効にしておいたほうがいいだろう。
# ipmon -Ds
このドキュメントでは、基本的な ipf と ipnat 設定を説明する。この両者については、/usr/share/ipf/ にいろいろすてきな例があるので、自分のほしいものにいちばん近いものをそこから選んで、それを自分のニーズにあわせて修正するのがお奨めだ。もっと詳しい IP フィルタ情報については、IP フィルタの メーリングリストアーカイブ と IP フィルタ web サイト、そしてIP Filter HOWTO を見よう。
ipf を起動時に有効にするには、/etc/rc.conf を編集して IPFILTER=YESにしておくこと。 IP フィルタ (ipf) をコントロールしているのは /etc/ipf.rules で、これは起動時に読み込まれる。もっと詳しい説明は ipf(5) を見て欲しい。以下の例では、 fxp0 はインターネットにつながった外部インターフェース。きみのマシンの使っている Ethernet アダプタに応じて、これは変わってくるはずだ。以下のルールは、web サーバなんかに見られる形で、インターネットへの常時接続を前提にしたものだ。
IP フィルタのルールは、上から下へ順番に処理されていく。だから各パケットが、目的地に到達するまでに、それらのルールに一つ一つよっていく様子を思い描いてみるといいだろう。
たとえば、以下のデフォルトのルールセットは、あらゆるパケットが自由に出入りできる設定になっている:
pass out from any to any pass in from any to any
さてかりに、データベースは localhost だけが接続するものだから、ポート 3306 (mysql) には外からのパケットは何も入ってきてほしくないとしよう。ルールセットはこんな具合になる:
pass out from any to any pass in from any to any block in on fxp0 from any to any port = 3306
これが何を言っているかというと、 "目的地が 3306 になっているパケットが入ってきたら、それがどこからどこへいくものだろうと、ブロックすること"ということだ。基本的に、fxp0 上のポート3306を目指すパケットは、最初の "pass in" ルールには通るんだけれど、でも "block in port = 3306" ルールの部分ではねられる。もし、入ってくるときのルールの順番を変えるとどうなるだろう(順番がだいじなんだ、忘れないでね):
pass out from any to any block in on fxp0 from any to any port = 3306 pass in from any to any
ポート 3306 あてのパケットは通ってしまう。セットの中の最後のルールで、すべてのパケットは通っていい、ということになっているからだ。パケットフィルタのルールを書くときには、これを絶対に忘れちゃいけない: いちばん最後にマッチしたルールが勝つ。
もちろんルールにはなにごとも例外がつきものだ。quick オプションを使うと、パケットがどこかのルールにマッチした段階でそれをはねる。たとえばいまの、失敗した例をみてやろう。ここの "block in" ルールのところに quick と追加してやろう:
pass out from any to any block in quick on fxp0 from any to any port = 3306 pass in from any to any
このホストのポート 3306 あてのパケットは "block in quick" ルールにぶちあたって、その場ではねられる。ほかのポートあてのパケットはすべて、マッチするルールが見つからないまま、さいごまできて "pass in" ルールにマッチするので、すべて通過が認められる。
デフォルトでは否認(Default Deny)
いちばん安全なパケットフィルタ方針は、デフォルトでは否認(default deny)方針だ。はっきり明示的に認められていないトラフィックははねられる。この方針は、各保護サービスをいちいち否認してまわるよりずっと安全だし、ルールセットも少なくてすむし、うっかり設定をまちがえたサービスが、むきだしになる事故を避けることもできる。
では、またもや実際の例でルールセットを見てやって、一行ずつ説明していこう。これは webserver で、デフォルトで否認(default deny)方針をとっていて、管理用にssh 接続と、http (port 80) と https (port 443)への接続だけを認めることにしている:
############################# # begin ruleset ############################# pass in quick on fxp0 from any to any port = 22 pass in quick on fxp0 from any to any port = 80 pass in quick on fxp0 from any to any port = 443 block in quick on fxp0 from any to any pass out on fxp0 from any to any ############################## # end ruleset ##############################
これで、ポート 22(ssh), 80(http), 443(https) へは、どこからの接続でも受け付けることになる。それ意外の接続をやってみても、全部はねるし、外向けの接続はすべて認める。なかなかきびしいルールセットだ。でも、ssh には 1.1.1.0 アドレスブロックの内部ホストだけからしか接続できないようにして、http と httpsには外からの接続をすべて認める場合には?
############################# # begin ruleset ############################# pass in quick on fxp0 from 1.1.1.0/24 to any port = 22 pass in quick on fxp0 from any to any port = 80 pass in quick on fxp0 from any to any port = 443 block in quick on fxp0 from any to any pass out on fxp0 from any to any ############################## # end ruleset ##############################
なかなか結構。でも、もしweb サーバをリモートで管理するマシンを一つだけ (1.1.1.1) にしたかったら? その場合は、以下の部分を変えてやろう:
pass in quick on fxp0 from 1.1.1.0/24 to any port = 22
ここを次のように変える:
pass in quick on fxp0 from 1.1.1.1/32 to any port = 22
IP フィルタは、ネットマスクを書くときに CIDR でもドット区分10進表記でも認めている。だから上のやつは、こんなふうに書くこともできる:
pass in quick on fxp0 from 1.1.1.1/255.255.255.255 to any port = 22
でもわざわざそんなことをしないでも、ねえ?
ルールの見本
だれでも使える、よくできたルールを見本に挙げておこう(fxp0 が外部のインターネットとつながったインターフェースだとする)。まず、単純なアドレス spoofing に対する保護を。
block in quick on fxp0 from 127.0.0.0/8 to any block in quick on fxp0 from 192.168.0.0/16 to any block in quick on fxp0 from 172.16.0.0/12 to any block in quick on fxp0 from 10.0.0.0/8 to any block out quick on fxp0 from any to 127.0.0.1/8 block out quick on fxp0 from any to 192.168.0.0/16 block out quick on fxp0 from any to 172.16.0.0/12 block out quick on fxp0 from any to 10.0.0.0/8
さらに、ループバックのインターフェースをほかのルールと分離しておくほうがいいのだ。
pass out quick on lo0 pass in quick on lo0
なかなかいい具合のルールセットになってきたね。いまの二つをあわせると、こんな感じになっている:
########################### # begin ruleset ########################### # loopback rules pass out quick on lo0 pass in quick on lo0 # don't allow anyone to spoof non-routeable addresses block in quick on fxp0 from 127.0.0.0/8 to any block in quick on fxp0 from 192.168.0.0/16 to any block in quick on fxp0 from 172.16.0.0/12 to any block in quick on fxp0 from 10.0.0.0/8 to any block out quick on fxp0 from any to 127.0.0.1/8 block out quick on fxp0 from any to 192.168.0.0/16 block out quick on fxp0 from any to 172.16.0.0/12 block out quick on fxp0 from any to 10.0.0.0/8 # only allow our administration machine to connect via ssh pass in quick on fxp0 from 1.1.1.1/32 to any port = 22 # allow others to use http and https pass in quick on fxp0 from any to any port = 80 pass in quick on fxp0 from any to any port = 443 # finally lock the rest down with a default deny block in quick on fxp0 from any to any # and let out-going traffic out pass out on fxp0 from any to any ############################# # end ruleset #############################
パケットのログ取り
さて、これでもなかなかいいけれど、もっとよくしてみよう。このファイアーウォールがブロックした、ポート 22(ssh) に対する接続要求を全部ログにとっておきたいと思ったら? まかせなさーい。IP フィルタは、log というキーワードでこれを処理してくれる:
pass in quick on fxp0 from 1.1.1.1/32 to any port = 22 block in log quick on fxp0 from any to any port = 22
このルールでは、リモートの管理用マシンはポート 22 に接続させてもらえるけれど、それ以外でポート 22につなごうとする試みはすべてはねられて、ログにとられる。
プロトコルベースのパケットフィルタリング
IP フィルタは、/etc/protocols にある番号と名前にもとづくあらゆる IP プロトコルをフィルタできる。わかりやすくするために、ここではtcp, udp, icmp だけを考える。これはいちばんよく使われるプロトコルだ、すべての基本的なインターネットアプリケーションは、これらプロトコルが使えてきちんと機能すること前提にしている。
ipf がプロトコルに基づいてフィルタリングをするには、proto というキーワードを使わなくてはならない。さっきの ssh を例にしたルールで考えると、ssh は tcp 上で動くので、tcp パケットだけしか接続を認めてはいけない。proto キーワードを使って tcp だけを通すようにすることで、こんなふうなルールができる:
pass in quick on fxp0 proto tcp from 1.1.1.1/32 to any port = 22
でも、bind みたいに、tcp と udp 両方の上で動いているサービスの場合はどうすればいい? そうだね、tcp/udp の場合には、IP フィルタはこの二つのプロトコルをまとめさせてくれる。注:これは tcp/udp だけでしか使えない。bind の例を使うと、デフォルトでは否認(default deny) 環境で tcp と udp 接続を認めるルールはこんな感じだ:
pass in quick on fxp0 proto tcp/udp from any to any port = 53
パケットフィルタリング
プロトコルにもとづいてフィルタリングするだけでなくて、IP フィルタは断片化した IP パケットを管理することもできる(断片化したパケットを使うのは、パケットフィルタ破りのよくある手口だ)。断片化 ip パケットを扱うときのキーワードは、可能性として二つある。ふつうの断片化パケット用の frag、そして比較するにはヘッダが小さすぎるパケット用に short だ。断片化パケットはふつうにしていても、リンクの状態によっては生じるものなので、きちんと比較するにはヘッダが小さすぎるパケットだけをフィルタリングするのがいちばんいい。これには次のようなルールが使える:
block in quick proto tcp all with short
IP オプションはどうだろう? IP フィルタは、そういうパケットも処理できる。パケットは、IP オプションがセットしてあればはねてしまってもいいし、セットしてある IP オプションに応じて仕分けしてもいい。たとえば、以下のルールは ip オプションのついたパケットをすべてはねて、ログに記録する。
block in log quick on fxp0 all with ipopts
でもこれだと、traceroute(8) なんかが使えなくなったりする場合がある。だから、どのオプションは認めないかをきちんと指定しておくこともできる。たとえばよいルールの例としては、source routing オプションつきのパケットはすべてブロックする、というものがある。これを実現するルールはこんな具合:
block in quick on fxp0 all with opt lsrr block in quick on fxp0 all with opt ssrr
TCP フラグ、確立した接続と状態の保持
さてこれで、本気でフィルタリングを始められる。IP フィルタの最大の強みは、パケットを TCP フラグでフィルタリングして、確立した接続と接続状態を維持することなのだ。TCP フラグに基づくパケットフィルタリングをしたいユーザは、みんなそれぞれのフラグが何をするのか理解しておくことをお奨めする。たとえば FIN, URG, PSH フラグのたったパケットをすべてブロックしたい場合(たとえば、nmap OS フィンガープリンティングの試みなど)、こんなルールを使えばいい:
block in quick on fxp0 proto tcp from any to any flags FUP
(このアドバイスについてはKyle Hargraves に感謝)
IP フィルタの次なるクールな技は、状態の維持能力だ。状態維持というのは"話しかけられるまで口を開かない"というたとえがよく使われる。言い換えると、いったん接続が確立したら、パケットはもうルールセットをいちいち見なくていい、ということ。これはとても強力な機能で、ルールを書くのもずっと簡単で高セキュリティのものができる。
たとえば、さっきのルールセット(そろそろ混乱してきた?)に状態を適用してみようか。おさらいしておくと、管理用アクセスは、クラスC からポート 22(ssh) にだけ認めて、ポート 80(http) と 443(https) に入ってくる webトラフィックはすべて認める、と。でも、もしこのweb サーバから ssh で外につなぐ必要が出てきたら?lynx を使ってFAQのなにかを読みたい場合は? それは不可能だ。だって、指定されたポート以外のところから入ってくる接続はすべてブロックしちゃったもの。これはいちばん安全な方法ではあるけれど、えらく不便でもある。"pass out" ルールにkeep state キーワードを追加しておけば、自動魔術的にこちらから開始した接続の応答として入ってくる接続(たとえば web ブラウジングなど)は認められることになる。その状態を維持するのにどんなプロトコルを使うかは指定しなくていい、という点はお忘れなく。
############################# # begin ruleset ############################# pass in quick on fxp0 from 1.1.1.0/24 to any port = 22 pass in quick on fxp0 from any to any port = 80 pass in quick on fxp0 from any to any port = 443 block in quick on fxp0 from any to any pass out on fxp0 proto tcp from any to any keep state ############################## # end ruleset ##############################
このちょっとした変更で、ルールセットの柔軟性とセキュリティは劇的に高まる。というのも IP フィルタがとても柔軟だからだ。たとえば上のルールセットでは、ポート 80 と 443 にはすべての tcp 接続を認めている。こいつをもっとしぼることもできる。tcp 接続が確立するには、内部ハンドシェークさえ起こればいい。いったんそれが起こったら、そのポートへのトラフィックはブロックして、あとの接続の面倒は"keep state" ルールに任せておけばいい。最初のハンドシェークが完成するには、SYN と SYNACK フラグの立ったパケットだけを通せばすむ。SYN と SYNACK のセットされたパケットだけを認めることで、FIN スキャニングなど、各種のポートスキャンから身を守ることができる。ルールはいまやこんなふうな感じ:
############################# # begin ruleset ############################# pass in quick on fxp0 from 1.1.1.0/24 to any port = 22 pass in quick on fxp0 from any to any port = 80 flags S/SA pass in quick on fxp0 from any to any port = 443 flags S/SA block in quick on fxp0 from any to any pass out on fxp0 proto tcp from any to any keep state ############################## # end ruleset ##############################
さておしまいに、これまでのルールを全部まとめて、ルールセットにしよう。このルールセットはデフォルトでは否認(default deny)方針で、管理用雪像は内部ネットワークから(ssh経由で)のみ認め、入ってくるトラフィックはポート 80(http) と 443(https)だけに認める。さらにspoofされた、ルーティング不能な ip アドレスはブロックして、検査するには断片化しすぎているパケットはすべてはねる。公開 web サーバとしては、なかなか念の入った設定になっている。このときの /etc/ipf.rules はこんな感じのはずだ:
########################### # begin ruleset ########################### # loopback rules pass out quick on lo0 pass in quick on lo0 # drop itsy bitsy frags block in quick proto tcp all with short # drop source routed packets block in quick on fxp0 all with opt lsrr block in quick on fxp0 all with opt ssrr # don't allow anyone to spoof non-routeable addresses block in quick on fxp0 from 127.0.0.0/8 to any block in quick on fxp0 from 192.168.0.0/16 to any block in quick on fxp0 from 172.16.0.0/12 to any block in quick on fxp0 from 10.0.0.0/8 to any block out quick on fxp0 from any to 127.0.0.1/8 block out quick on fxp0 from any to 192.168.0.0/16 block out quick on fxp0 from any to 172.16.0.0/12 block out quick on fxp0 from any to 10.0.0.0/8 # only allow our machines to connect via ssh pass in quick on fxp0 from 1.1.1.0/24 to any port = 22 # allow others to use http and https pass in quick on fxp0 from any to any port = 80 flags S/SA pass in quick on fxp0 from any to any port = 443 flags S/SA # finally lock the rest down with a default deny block in quick on fxp0 from any to any # and let out-going traffic out and maintain state on established connections pass out on fxp0 proto tcp from any to any keep state ############################# # end ruleset #############################
もし問題にでくわしたら、トラブルシューティングを上手にやるには、個別ルールごとのログとりをオンにしておくといいかもしれない。つまり:
pass in log quick on fxp0 from 1.1.1.0/24 to any port = 22
設定ファイルを変更してパケットのログをとるようにしたら、その変更が有効になるようにipf -Fa -f /etc/ipf.rules をお忘れなく!
ipmon は、ip ログの内容を /var/log/ipflogに書き出す。
ipf についてもっと詳しく知りたければ、IPF how-to がすばらしい情報源だし、IP Filterホームページにもすばらしいドキュメントがある。
初期の作業は Wayne Fergerstrom <wayne@methadonia.net>による。
この部分では、OpenBSD マシンで Network Address Translation ("NAT")をインストールして設定しようとしている人たちのためになる情報を提供する。
ユーザは、すでに OpenBSD マシンをたちあげていて、それにはネットワークカードが二枚ささっているものとする(一つはインターネットにつながっていて一つはローカルネットワーク)。IP Network Address Translation は、ネットワークカード(NIC) 1 枚のマシンでも機能する。でもパケットが同じインターフェースから出たり入ったりするので、 Ethernet の衝突がおこって、速度はずいぶんと低下するはずだ。
RFC 1631 にもとづく ipnat は、内部ネットワークを単一のルーティング可能な("本物の") インターネットアドレスにマッピングできるようにする。これは、内部ネットワークの全マシンに、公式にアドレスが割り当てられていないときにとても便利だ。プライベート/内部ネットワークを設定すると、予約済みのアドレスブロック (RFC 1918で指定されたもの) も利用できる。たとえばこんなふうに:
10.0.0.0/8 (10.0.0.0 - 10.255.255.255)
172.16.0.0/12 (172.16.0.0 - 172.31.255.255)
192.168.0.0/16 (192.168.0.0 - 192.168.255.255)
この文書で使われている表記方法は、ごくふつうのものだ。ドキュメンテーションのために、いくつか用語や、このドキュメントでつかわれている表記方法について説明しておく。
"NAT"
これは "ネットワークアドレス変換(Network Address Translation)"の機能を説明したもの。NAT のプロセスはあとで説明してある。
"ipnat"
これは "IP Network Address Translation" の略。これだけで使うと、NAT とまったく同じ意味。でもこのドキュメントでは "ipnat" はコマンドラインだけでの利用のみをさすものとする。
"IPF"
これは "IP フィルタ" の略。IP フィルタは、可搬性の高いパケットフィルタソフトで、OpenBSD にも含まれている。IP フィルタは、ipnat を起動するまえに有効にしておくこと。これは簡単で、/etc/rc.conf を編集して ipf=NO を ipf=YES に変えればいい。これだけだと、起動シーケンスの間しか変更が有効にならないので、起動が完了しても ipf を有効にしておくには、'ipf -E' としておくことが必要だ。もちろんこれについてはあとで説明してある。
この文書では、コンピュータは以下のように設定されているものとする。人によってはこれとちがう設定になっているだろうけれど、この文書の目的は概要をつかんでもらって、自分の設定にこれを応用できるようになってもらうことだ。
オペレーティングシステム: OpenBSD v2.7 i386
NICs:NetGear 10/100MB dc0
Connected to the EXTERNAL LAN (or WAN)
IP Address: 24.5.0.5
Netmask: 255.255.255.0
NetGear 10/100MB dc1
Connected to the INTERNAL LAN
IP Address: 192.168.1.1
Netmask: 255.255.255.0外部接続のインターネットへのルーディング可能な IP (ISP が提供、ここではケーブルモデムのプロバイダ)
IP Address: 24.5.0.5
Netmask: 255.255.255.0
Gateway: 24.5.0.1
Local Area Network
この例では、LAN 上のマシンは 192.168.1.xxx というアドレスをもらっている(xxx はそれぞれのマシン固有の番号)。内部 LAN にはいろんな OS のマシンが混在している。Windows 98, Windows NT, OpenBSD, Linux など。それぞれのマシンはハブにつながっていて、ハブは内部利用に割り当ててある。この文書とその中の例では、LAN 上のクライアントは 192.168.1.40 という IP アドレスを持つものとする。
設定のダイヤグラム
+-----+ +---------+ +----------+ | Hub |--------- dc1 | NAT | dc0 ----| Internet | +-----+ +---------+ +----------+ | | | +-- Client A +---- その他クライアント +-------------------------+ | LEGEND | +-------------------------+ | NIC dc0 - 24.5.0.5 | | NIC dc1 - 192.168.1.1 | | Client A - 192.168.1.40 | +-------------------------+
NAT入門
インターネット上のビジネスやユーザが増えるにつれて、各人が IP アドレスを必要とするようになる。公共 IP アドレスは、どんどんとりにくくなってきた。多くの人たちの解決方法は、ネットワークアドレス変換(Network
Address Translation、略して "NAT") だ。NAT はとても単純だけれど、とても強力で、マシンごとに IP アドレスを買ったり借りたりしなくても、LAN をインターネットにつなげるようになる。もし Linux ユーザであれば、IP マスカレードというのをきいたことがあるだろう。これはNAT と同じものだ。
NAT がたちあがってきちんと走っていると、内部 LAN のユーザが、別の IP (ISP からもらった IP)を使ってインターネットにアクセスできるようになる。LAN 上の各マシンは、ISP からもらった IP アドレスを使うように設定されたマシンの IP を(透過的に)使う。
NAT の働きというのはびっくりするほど簡単だ。LAN 上のクライアントがインターネット上のマシンに接続したいときには、接続要求の入った TCP パケットを送る。この TCP パケットヘッダには、クライアントの IP アドレス (ここでは 192.168.1.40) と、要求したホストの IP アドレス (ここでは 123.45.67.89) が入ってる。NAT を実行しているマシンはこの TCP パケットをインターセプトして、クライアントの IP アドレスを 192.168.1.40 からインターネット接続されたマシンの IP アドレスに変える(ここでは 24.5.0.5)。これによって、相手のホストは実質的にだまされて、実際の接続はこの NAT マシンからのものであって実際のクライアントのマシンからきているのではないと思うわけだ。ホストはそこで NAT マシンに向かって、ふつうの接続要求に対するのと同じ応答を返す。NAT マシンはそれを受け取ると、目的地の IP アドレスをすぐに自分のものからクライアントマシンのものに戻して、パケットをクライアントに送る。クライアントは何がおこったのかぜんぜんわかっていない。spoof されたインターネット接続は、まったく透過的に起こる。
以下の例を見ると、NAT のはたらきがもうちょっとはっきりするだろう:
Client ----------------- dc1 [ NAT ] dc0 ---------- Internet Host 192.168.1.40 --- 192.168.1.1 [ NAT ] 24.5.0.5 --- 123.45.67.89 OUTGOING TCP Packet OUTGOING TCP Packet From: 192.168.1.40 >>=== NAT ===>> From: 24.5.0.5 To: 123.45.67.89 To: 123.45.67.89 INCOMING TCP Packet INCOMING TCP Packet From: 123.45.67.89 From: 123.45.67.89 To: 192.168.1.40 <<=== NAT ===<< To: 24.5.0.5
新しいアパートにケーブルモデムがついたとき、ぼくはもう一つ小さな問題に直面することになった。ケーブルモデムはぼくの部屋にあるのに、ほかの部屋にいるルームメートたちにどうやってインターネット接続を提供したらいいだろう。やりかたはいくつかある。追加の IP アドレスをもらう、proxy サーバをたてる、NATを使う。(ケーブルモデムを例にしているからといってバカにしちゃいけない。NAT はすごく強力で、何百、何千ものマシンがつながったLAN でもじゅうぶんにマスカレードできる!)
NAT を使いたいと思った理由はいっぱいあって、最大のものはお金の節約だった。うちにはルームメートが二人いて、それぞれコンピュータをもっている。そしてぼくはコンピュータ 3 台持っている。ぼくの ISP は世帯あたり IP 3 つしか認めてくれない。つまり、すべてのマシンにインターネットアクセスを許せるほどの IP がなかったわけだ。
NAT を使えば、各マシンはユニークな(内部) IP アドレスを持ちながら、ぼくの ISP がくれた一つの IP アドレスを共有できる。コストも下がる。
NAT を OpenBSD マシンで有効にするには、 IPF と NAT を立ち上げよう。これは、以下に挙げたファイルを編集すればすぐにできる (ファイルの中身が、その下に挙がったものみたいになるようにするのだ):
/etc/rc.conf (起動時にサービス開始のために使うファイル)
ipfilter=YES
ipnat=YES
/etc/sysctl.conf
net.inet.ip.forwarding=1
この変更をやったら、マシンは NAT設定の準備万端だ。
The first step is to configure the IPF rules file (/etc/ipf.rules). For the purposes of this document we will allow traffic to pass through this firewall option without any interference. The file should look like this:
pass in from any to any pass out from any to any
Again for more information you can read FAQ 6.2
The NAT configuration file (/etc/ipnat.rules) has a very simple syntax. For the configuration set forth above, the file should contain the following entry:
map dc0 192.168.1.0/24 -> 24.5.0.5/32 portmap tcp/udp 10000:60000 map dc0 192.168.1.0/24 -> 24.5.0.5/32
上の各行を説明していこう。
"map"
これは、ipnat に喰わせるコマンドだ。ipnat に、これが LAN と Internetの間で IP を変換するためのエントリがこれだよ、と教えているのだ。"dc0"
これはインターネットに接続されたネットワークインターフェース。"192.168.1.0/24"
IP アドレスとネットマスク (ネットマスクは CIDR 形式)。両者を組み合わせると、これは "192.168.1.1 から 192.168.1.254までの任意の IP" をマッピングしなさい、と指定しているわけだ。CIDR 記法が嫌いならば、"/255.255.255.0"ではなく"/24" と書いてもいい。"24.5.0.5/32"
この IP アドレスとネットマスクは、LAN IP アドレスがマッピングされる IP アドレスを示す。 /32 は、IP アドレス一つだけ、ということだ。 /24 を指定すれば256 個の IP アドレスが使える (あるいは /27 でもなんでも、好きなビット数をどうぞ)!! これは、NAT の背後に何千台ものクライアントマシンが控えている場合には便利だ(もちろん、その外部からの /24 の IP アドレスが全部あなたの OpenBSD マシンにつながっていないと無意味だけれど!)"portmap tcp/udp 10000:60000"
これは tcp/udp パケットをすべて 10000 から 60000までのポートにマップする。
二行目は、ほとんど同じだけれど、最後のところだけがちがう。この部分は ipnat に、それ以外のすべて(tcp/udp は含まれない。もう一行目でマッチがすんでいるから)を、それが要求するポートになんでもつないであげろ (ICMP その他のプロトコルで使われる)と指定してるのだ。これがファイルに書き込まれたら、あとは IPF デーモンを走らせるだけだ。
実行
NAT の実行も実に簡単なプロセスだ。設定さえ終われば、NAT を有効にする方法は二種類。最初の方法(そして可能ならばセットアップの段階を試験するのに最適な方法)は OpenBSD マシンを再起動することだ。これは"reboot"
コマンドを使おう。
コマンドラインから ipnat を実行するには、以下のコマンドを使おう:
# ipf -Fa -f /etc/ipf.rules -E # ipnat -CF -f /etc/ipnat.rules
一行目は、IPF を有効にするためのもの。NAT は IPF におんぶされて動くので、NAT をロードする前に IPF が初期化されて動いている必要がある。コマンドラインのオプション "-Fa" は、いま動いているエントリをすべてクリアする。"-f /etc/ipf.rules" というのは、ルールファイルの場所を示す。"-E" は、IPF デーモンを有効にするものだ。
二番目のコマンドラインは NAT を有効にするものだ。"-CF" は、NAT テーブルにその時点で入っているエントリを全部クリアしてしまう。"-f /etc/ipnat.rules" は NAT に、NAT ルールファイルの場所を教える。これで NAT はもう動いている。チョロイもんでしょうが。
注:NAT 設定をリロードする場合には(たとえばファイルを編集したけれど再起動したくない場合など)、いまの二行目を実行しなおせばいい。設定はクリアされて、リロードされる。
NAT の状況や、設定がきちんと反映されているかを確認するには、"-l" オプションを使う。このオプションは、設定すべてと、ipnat が動いているいまのセッションを表示してくれる。
# ipnat -l map dc0 192.168.1.0/24 -> 24.5.0.5/32 portmap tcp/udp 10000:60000 map dc0 192.168.1.0/24 -> 24.5.0.5/32 List of active sessions: MAP 192.168.1.40 2473 <- -> 24.5.0.5 13463 [129.128.5.191 80]
最初の二行の目的は、さっき /etc/ipnat.rules に入れた設定の状況をみることだ。それにつづく数行は、現在の NAT 制御の接続一覧を示す。
"MAP 192.168.1.40 2473"
NAT を使っている LAN 上のマシンの IP アドレスを示す。接続用のポート番号がその後に表示されている。"<- ->"
NAT がトラフィックを双方向処理していることを示す。"24.5.0.5 13463"
接続が、IP アドレス 24.5.0.5 を使ってポート 13463経由でインターネットにつながっていることを示す。"129.128.5.191 80"
IP アドレスとそれが接続されているポートが最後に挙がっている。
NAT にもいくつか限界はある。一つは、FTP がらみのもの。ユーザがリモート FTP サーバにつないで、情報やファイルを要求すると、 FTP サーバはクライアントと接続して情報を転送する。これは、ランダムな空きポートで行われる。これは、LAN 内部から FTP サーバにアクセスしようとしているユーザには困ったことになる。FTP サーバが情報を送る時には、外部 NIC のランダムなポートに送ってくる。NAT マシンはこれを受けるけれど、知らないパケットだからマッピングがないし、そのポートにマッピングがなければ、単にそのパケットを捨てて配送しないことになる。
これを解決するには、FTP クライアントを "passive mode" にすることだ。これだと上に書いたような形ではなく、サーバにつなぎたいのだ、とサーバに指定することになる。そうすれば外向きに接続しても NAT はきちんと接続を処理してくれる。
(訳注:鈴木保是さん<suzu@itaccess.co.jp>が説明してくれました。TNX!
「ftp サーバと ftp クライアントは、二つのモード:アクティブとパッシブを大体はサポートしています。クライアントがアクティブモードでサーバに接続した場合、サーバはアクティブモードで動作します。この時はサーバからのデータ転送ポートをサーバが設定してきます。予めクライアント側がOKのポートか否かを考慮しません。一方、クライアントからパッシブモードでサーバに接続した場合、サーバはパッシブモードで動作し、クライアントが設定したきたポートをそのまま使ってデータを転送してきます。」
この状況を解決するもう一つの方法としてはIP フィルタがある。これはつまり、NAT コードに組み込まれた ftp proxy だ。これを有効にするには、他の NAT マッピングの前にこんな一行を追加しよう。
map dc0 192.168.1.0/24 -> 24.5.0.5/32 proxy port ftp ftp/tcp
これがあると、カーネルは FTP 接続を見張っていてくれて、ftp クライアントからくる "PORT" コマンドを探して、IP アドレスとポートを自分の外部 IP アドレスと置き換える。それからそのポートを開いて、データを ftp クライアントの要求したポートに送る。すぐにわかるように、これはちょっとリソースをたくさん使う。でも、NAT/IP フィルタのマシンが限界近くにきているのでなければ、特に問題はないはずだ。
ときどき、特定のプロトコルやポートに出入りするトラフィックをリダイレクトする必要が出てくる。このよい例としては、LAN 内部に web サーバを走らせているサーバがある場合だ。有効なインターネット IP に入ってくる接続は、NAT マシン自体で web サーバが稼働しているのでない限り、接続ができないことになる。これを解決するために、ルールファイルで NAT 'rdr' directive を使って、指定の接続をどこにリダイレクト(またはルーティング)するかを指定してやろう。
たとえば、LAN 上の 192.168.1.80 に web サーバがいるとしよう。NAT ルールファイルは、これを扱うのに新しい directive が要る。ipnat.confに、こんな感じの行を加えてやろう:
rdr dc0 24.5.0.5/32 port 80 -> 192.168.1.80 port 80
それぞれの部分の説明をしていこう:
"rdr"
これは、ipnat に与えるコマンドだ。ipnat に、このエントリは接続をリダイレクトするためのエントリだ、と告げている。"dc0"
これはインターネットに接続されたネットワークインターフェース。"24.5.0.5/32"
これは、この IP アドレスに入ってくる接続 (上と同じで dc0 だけ)"port 80"
これがリダイレクトされるべきポート (80) だ。別に "80" という数字でなくてもいい。"port www" を使っても、port 80 のリダイレクションは指定できる。もし数字でなくて名前を使いたいなら、サービス名とポート番号との対応が、/etc/servicesファイルに記述してある必要がある。"192.168.1.80"
パケットがリダイレクトされる先のIP アドレスとネットマスク。ネットマスクは常に "/32" (だから指定しなくても可)なので、特定のマシンだけにリダイレクトされる。
この行を追加したら、NAT ルールをリロードしよう。すぐにリダイレクションが始まる。
NAT とアプリケーションベースの proxy とのちがいは、proxy ソフトはインターネットと LAN 接続のマシンとの仲立ちをするということだ。これは結構なんだけれど、でもマシン上で動くアプリケーションが、すべて proxy のことを知らなきゃいけない(つまり proxy 対応になってる必要がある)。アプリケーション全部にこれができるわけではない(特にゲームは全滅)。さらに、この世にある各種インターネットサービスすべてに対応した proxy サーバアプリケーションはそもそもないのだ。 NAT は内部ネットワークを透過的にマッピングしてくれて、インターネットに接続できるようにしてくれる。proxy を使うことで唯一セキュリティ上のメリットがあるのは、proxy のセキュリティ対応ができていたらコンテンツに応じたフィルタがかけられる、ということだ。たとえば Windows マシンがマクロウィルスに感染するのを防いだり、クライアントソフトのバッファオーバーフローを防止したりできる。でもこういうフィルタをメンテナンスするのは、とても手間のかかる仕事の場合が多い。
OpenBSD ファイル:
NAT インターネットリンク:
OpenBSD 付属の DHCP クライアント dhclient(8) を使うには、/etc/hostname.xl0 を編集しよう(これはきみの主 ethernet インターフェースが xl0 だと想定している。実際のきみのマシンでは ep0 や fxp0 かなんかかもしれないよ!) この hostname ファイルにはひとこと 'dhcp'と書けばいいだけ。
# echo dhcp >/etc/hostname.xl0
これで OpenBSD は、起動時に自動的に DHCP クライアントをたちあげる。OpenBSD は IP アドレスとデフォルトのゲートウェイと DNS サーバを DHCP サーバから入手する。
もしコマンドラインから dhcp クライアントを起動したければ、 /etc/dhclient.conf が存在することを確認してから、次のようにしてみよう:
# dhclient fxp0
ここで fxp0 は、dhcp を受け取りたいインターフェースだ。
dhclient の起動のしかたによらず、/etc/dhclient.conf を編集して、 DNS を dhcp サーバの考える DNS で置き換えないようにするには、まずこの設定ファイルの中の 'requre' のコメントをはずす(これはデフォルト設定の例として書いてあるんだけれど、これのコメントをはずさないと、dhclientのデフォルトがオーバーライドされない)
request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, lpr-servers, ntp-servers;
そしてその後で、domain-name-servers を取り除くこと。もちろん、hostname とかその他の設定を除いてもいい。
OpenBSD を DHCP サーバ dhcpd(8) としいて使うには、/etc/rc.conf を編集しよう。dhcpd_flags=NOという部分を、dhcpd_flags="-q" となるようにしよう。dhcpd が聴いていてほしいインターフェースを /etc/dhcpd.interfacesに記述すること。
# echo xl1 xl2 xl3 >/etc/dhcpd.interfaces
それから /etc/dhcpd.conf を編集する。オプションの意味はまあ読んで字のごとし。
option domain-name "xyz.mil"; option domain-name-servers 192.168.1.3, 192.168.1.5; subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.1; range 192.168.1.32 192.168.1.127; }
これで dhcp クライアントに、DNS 要求に追加すべきドメインは xyz.mil だと伝わる(つまりもしユーザが 'telnet joe' とタイプしたら、それは joe.xyz.milに送られる)。さらにクライアントは、192.168.1.3 と 192.168.1.5 という DNS を指示される。OpenBSD マシンの ethernet インターフェースと同じネットワーク上にあるホスト(これは192.168.1.0/24 の範囲内にある)は、192.168.1.32 から 192.168.1.127 までの IP アドレスが割り当てられる。デフォルトのゲートウェイは 192.168.1.1となる。
コマンドラインから dhcpd を起動するには、/etc/dhcpd.confを編集し終えてから次のようにしよう:
# touch /var/db/dhcpd.leases # dhcpd -q fxp0
最初の一行は、dhcpd が配った IP を記録しておくためのデータベースファイルを創ってやるためのもの。これを忘れるとエラーが出る。
2 行目で fxp0 は、dhcp のサービスを提供したいインターフェースだ。 -q フラグは dhcpd をだまらせておく。さもないと、とてもうるさいのだ。
Windows マシンに DHCP サービスを提供するなら、dhcpd がクライアントに 'WINS' サーバアドレスも送るようにしたいだろう。これを実現するには、/etc/dhcpd.confに次のように書き足すだけでいい:
option netbios-name-servers 192.168.92.55;
(ここで 192.168.92.55 は Windows か Samba サーバの IP だ)。 DHCP クライアントのほしがりそうなオプションについてもっと知りたければ、dhcp-options(5) を参照のこと。
PPP (Point-to-Protocol) は、モデム経由で ISP に接続するのによく使われる。OpenBSD でこれをやる方法は二種類ある。
まずはユーザランドの PPP デーモンから見ていこう。最初に isp について簡単な情報が必要になる。便利な必要情報の一覧を以下に挙げる。
以上の中には、なくてもなんとかなるものもあるけれど、ppp を設定するにはどれもあったほうが便利だ。ユーザランド PPP デーモンは /etc/ppp/ppp.conf が設定ファイルだ。いろんな状況別の便利な見本ファイルが /etc/ppp においてあるので、このディレクトリをざっと見ておこう。
あと、もし GENERIC カーネル以外のカーネルを使っているときには、設定ファイルに以下の一行があることを確認すること:
pseudo-device tun 2
ユーザランド PPP デーモンの最初のセットアップは、 /etc/ppp/ppp.conf ファイルの編集から始まる。このファイルはデフォルトでは存在しないけれど、/etc/ppp/ppp.conf.sample というファイルがあるので、これをチョイチョイと編集して、自分なりの ppp.conf ファイルをつくろう。ここではまず、いちばん簡単で、おそらくはいちばん使われる設定からはじめる。単純に、ISP に接続して、デフォルトのルートとネームサーバを設定するだけのファイルだ。このファイルを使えば、必要になる情報は、ISP のアクセスポイントの電話番号と自分のユーザ名にパスワードだけだ。
default: set log Phase Chat LCP IPCP CCP tun command set device /dev/cua01 set speed 115200 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK ATE1Q0 OK\\dATDT\\T TIMEOUT 40 CONNECT"
注意 - OpenBSD 2.6 は、デバイス設定のまちがった /etc/ppp/ppp.conf.example ファイルを入れて出荷されちゃったのだ。デバイスは "set device /dev/cuaa0" だったんだけれど、正しくは /dev/cua00 だ。これはシリアルデバイス 1 (COM1) に対応する。きみのデバイスは COM1 以外につながっているかもしれないけれど、要はデバイス名の書き方がまちがってたってことだ。
default: タグ以下の部分は、毎回実行される。ここで重要な情報を全部書いておく。"set log" では、ログを取る水準を設定している。これは変えられる。ログ取りの水準について詳しくは ppp(8) を参照。デバイスの設定は "set device" の部分。これはモデムがつながったデバイスだ。この例では、モデムは com2 につながっている。com 1 なら /dev/cua00 になるわけ。"set speed" では、ダイヤルアップ接続の速度を設定する。"set dial" では、ダイヤルアップのパラメータを設定する。これでタイムアウト時間なんかを変えられる。でも、これはなるべくいまのままにしておくほうがいい。
さあ、ISP 固有の情報に移ろう。これには、 default: 以下に別のタグをつける。このタグはどういう名前にしてもいいのだけれど、いちばん簡単なのは ISP の名前をつけることだろう。ここでは、ISP をさすタグとして myisp: を使っている。接続に必要なものすべてを組み込んだ簡単な設定を以下に挙げる。
myisp: set phone 1234567 set login "ABORT NO\\sCARRIER TIMEOUT 5 ogin:--ogin: ppp word: ppp" set timeout 120 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR enable dns
これで、この ISP 固有の情報はおおむね設定した。最初のオプション "set phone" は、ISP のアクセスポイントの電話番号。"set login" はログインのオプションを設定する。ここではタイムアウトを 5 にしてある。つまり、キャリアがなければ、ログインを 5 秒後にうち切る、ということ。さもなければ、 "login:" が送られてくるのを待って、それからユーザ名とパスワードを送る。この例では、ユーザ名 = ppp で、パスワード = ppp だ。この値は変更するように。"set timeout" は、ログインプロセス全体のタイムアウトを 120 秒にセットしてある。"set ifaddr" というラインはちょっとトリッキーだ。もっと詳しい説明を以下にしよう。
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
上の行では、"set ifaddr [myaddr[/nn] [hisaddr[/nn] [netmask [triggeraddr]]]]" という形式で設定してある。つまり最初に指定された IP が、われわれの IP としてほしいものだ。もしスタティックな IP アドレスを持っているなら、それをここに記述する。この例では /0 をお使っている。これは、この ip アドレスのどのビットも一致する必要はないということで、これ全体が置換されるかもしれない。指定した二番目の IP は、相手の IP として期待されるものだ。これを知っているなら、ここに記述すること。またもやこの行では、何が指定されるかわからないので、向こうから教わるのを待つことになる。3 つめのオプションはネットマスクだ。255.255.255.0 に設定してある。もしtriggeraddr が指定されていたら、これは最初の IPCP ネゴシエーション中に myaddr のかわりに使われる。これはピアが``0.0.0.0''を要求するまで IP を割り当てないという初期の PPP の実装
次のオプション "add default HISADDR" というのは、デフォルトのルートをかれらの IP に設定している。これは 'sticky' なのだ。つまり、向こうの IP が変わったら、こっちのルートも自動的に更新されるのだ。"enable dns" という部分は、ISP にこちらのネームサーバアドレスを認証するように指示している。ローカルの DNS を使っているときにはこれは指定しないこと! さもないと、ppp は /etc/resolv.conf にあるネームサーバのどれかを使って、ローカルのやつを使えなくしてしまうから。
さて ppp.conf ファイルの編集が終わったから、われらが ISP につないでみようではないか。ここでは、ppp でよく使われる引数をくわしく説明しよう。
/usr/sbin/ppp をオプションなしで使うと対話モードに入る。すると、モデムと直接やりとりができるので、ppp.conf ファイルのデバッグにとても便利だ。
ときどき、接続中や切断中にコマンドを実行したいことがある。それ専用に作っておけるファイルが2つある。/etc/ppp/ppp.linkup と /etc/ppp/ppp.linkdownだ。サンプル設定が以下にある:
もっと詳しい情報は http://www.freebsd.org/handbook/userppp.html or http://www.freebsd.org/faq/userppp.htmlを参照。
You would normally use this to allow for routing or connection problems. Of course, for it to be most effective, both sides of the connection need to use similar values.
To tweak this, use sysctl and increase the values of:
net.inet.tcp.keepinittime net.inet.tcp.keepidle net.inet.tcp.keepintvl
Using sysctl -a, you can see the current values of these (and many other) parameters. To change one, use sysctl -w, as in sysctl -w net.inet.tcp.keepidle=28800.
Normally, you don't want to do this. This allows someone to send traffic to the broadcast address(es) of your connected network(s) if you are using your OpenBSD box as a router.
There are some instances, in closed networks, where this may be useful, particularly when using older implementations of the NetBIOS protocol. This is another sysctl. sysctl -w net.inet.ip.directed-broadcast=1 turns this on. Read about smurf attacks if you want to know why it is off by default.
There is a sysctl for this also. From sysctl(8):
Set the list of reserved TCP ports that should not be allocated by the kernel dynamically. This can be used to keep daemons from stealing a specific port that another program needs to function. List elements may be separated by commas and/or whitespace. sysctl -w net.inet.tcp.baddynamic=749,750,751,760,761,871 It is also possible to add or remove ports from the current list. sysctl -w net.inet.tcp.baddynamic=+748 sysctl -w net.inet.tcp.baddynamic=-871
訳注:個人的に興味ないとこなのであとまわし! はやめに欲しい人は連絡をおよこし。考慮してあげるかも。
NFS, or Network File System, is used to share a filesystem over the network. A few choice man pages to read before trying to setup a NFS server are:
This section will go through the steps for a simple setup of NFS. This example details a server on a LAN, with clients accessing NFS on the LAN. It does not talk about securing NFS. We presume you have already setup packet filtering or other firewalling protection, to prevent outside access. If you are allowing outside access to your NFS server, and you have any kind of sensitive data stored on it, we strongly recommend that you employ IPSec. Otherwise, people can potentially see your NFS traffic. Someone could also pretend to be the IP address which you are allowing into your NFS server. There are several attacks that can result. When properly configured, IPSec protects against these types of attacks.
Another important security note. Don't just add a filesystem to /etc/exports without some kind of list of allowed host(s). Without a list of hosts which can mount a particular directory, anyone on who can reach your host will be able to mount your NFS exports.
The setup consists of a server with the ip 10.0.0.1. This server will be serving NFS only to clients within that network. The first step to setting up NFS is to setup your /etc/exports file. This file lists which filesystems you wish to have accessable via NFS and defines who is able to access them. There are many options that you can use in your /etc/exports file, and it is best that you read the exports(5) man page. For this example we have an /etc/exports that looks like this:
# # NFS exports Database # See exports(5) for more information. Be very careful, misconfiguration # of this file can result in your filesystems being readable by the world. /work -alldirs -ro -network 10.0.0 -mask 255.255.255.0
This means that the local filesystem /work will be made available via NFS. -alldirs specifies that clients will be able to mount at any point under the /work mount point. -ro specifies that it will only be allowed to be mounted read-only. The last two arguments specify that only clients within the 10.0.0.0 network using a netmask of 255.255.255.0 will be authorized to mount this filesystem. This is important for some servers that are accessible by different networks.
Once your /etc/exports file is setup, you can go ahead and setup your NFS server. You should first make sure that options NFSSERVER & NFSCLIENT are in your kernel configuration. (GENERIC kernel has these options included.) Next, you should set nfs_server=YES in /etc/rc.conf. This will bring up both nfsd(8) and mountd(8) when you reboot. Now, you can go ahead and start the daemons yourself. These daemons need to be started as root, and you need to make sure that portmap(8) is running on your system. Here is an example of starting nfsd(8) which serves on both TCP and UDP using 4 daemons. You should set an appropriate number of NFS server daemons to handle the maximum number of concurrent client requests that you want to service.
# /sbin/nfsd -tun 4
Not only do you have to start the nfsd(8) server, but you need to start mountd(8). This is the daemon that actually services the mount requests on NFS. To start mountd(8), simply type:
# /sbin/mountd
If you make changes to /etc/exports while NFS is already running, you need to make mountd aware of this! Just HUP it:
# kill -HUP `cat /var/run/mountd.pid`
From here, you can check to make sure that all these daemons are up and registered with RPC. To do this, use rpcinfo(8).
$ rpcinfo -p 10.0.0.1 program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 633 mountd 100005 3 udp 633 mountd 100005 1 tcp 916 mountd 100005 3 tcp 916 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs
During normal usage, there are a few other utilities that allow you to see what is happening with NFS. One is showmount(8) , which allows you to view what is currently mounted and who is mounting it. There is also nfsstat(8) which shows much more verbose statistics. To use showmount(8), try /usr/bin/showmount -a host. For example:
$ /usr/bin/showmount -a 10.0.0.1 All mount points on 10.0.0.1: 10.0.0.37:/work
NFS filesystems should be mounted via mount(8), or more specifically, mount_nfs(8). To mount a filesystem /work on host 10.0.0.1 to local filesystem /mnt, do this (note that you don't need to use an IP address, mount will resolve host names):
# mount -t nfs 10.0.0.1:/work /mnt
To have your system mount upon boot, add something like this to your /etc/fstab:
10.0.0.1:/work /mnt nfs rw 0 0
It is important that you use 0 0 at the end of this line so that your computer does not try to fsck the NFS filesystem on boot!!!! The other standard security options, such as noexec, nodev, and nosuid, should also be used where applicable. Such as:
10.0.0.1:/work /mnt nfs rw,nodev,nosuid 0 0
This way, no devices or setuid programs on the NFS server can subvert security measures on the NFS client. If you are not mounting programs which you expect to run on the NFS client, add noexec to this list.
Domain Name Service (ドメイン名サービス)は、IP ネットワークドメインが、問い合わせに対してホスト名・IPアドレスの参照解決をしてくれる、ネットワーク機能だ。OpenBSD をインストールすると、デフォルトでは DNS クライアントになっていて、DNS サーバにはなっていない。つまりきみの OpenBSD インストールは、あるマシンのアドレスについて、ドメイン名サーバに対して DNS 問い合わせを実行することはできるけれど、ちゃんと設定をするまでは、ほかのマシンから DNS 問い合わせがきても答えられない、ということだ。
ぼくの OpenBSD マシンは現在、ISP 経由でインターネットにつながっているので、nslookup(8) ユーティリティを使って DNS 問い合わせを実行してみよう:
$ nslookup www.openbsd.org Server: ns4.us.prserv.net Address: 165.87.201.244 Non-authoritative answer: Name: www.openbsd.org Address: 129.128.5.191
165.87.201.244 は返事をよこしたネームサーバだ。というのもこれは、ISP がアカウントをくれたときに使うよう指定したネームサーバだからで、/etc/resolv.conf に記述されたサーバでもあるのだ。でも、この返事は authoritative ではなかった。authoritative な回答を得るために、openbsd.org ドメインの authoritative なDNS サーバをつきとめて、そいつにwww.openbsd.orgのアドレスを要求してみよう:
# openbsd.orgのネームサーバを、ISPのネームサーバに # 手伝ってもらってつきとめよう $ nslookup -type=NS openbsd.org Server: ns4.us.prserv.net Address: 165.87.201.244 Non-authoritative answer: openbsd.org nameserver = cvs.openbsd.org openbsd.org nameserver = gandalf.sigmasoft.com openbsd.org nameserver = cs.colorado.edu openbsd.org nameserver = ns.appli.se openbsd.org nameserver = zeus.theos.com Authoritative answers can be found from: cvs.openbsd.org internet address = 199.185.137.3 gandalf.sigmasoft.com internet address = 198.144.202.98 cs.colorado.edu internet address = 128.138.243.151 ns.appli.se internet address = 194.198.196.230 zeus.theos.com internet address = 199.185.137.1 # いまの問い合わせで得られた情報を、authoritative # resolutionで使おう: authoritative なzeus.theos.comにクエリーをかける $ nslookup www.openbsd.org zeus.theos.com Server: zeus.theos.com Address: 199.185.137.1 Name: www.openbsd.org Address: 129.128.5.191
zeus.theos.com は、当然予想されるように OpenBSD で動いていて、openbsd.org ドメインのDNS サーバになるように設定がされている。
特に便利なのがdig(1) コマンド。ドメインの問い合わせをして、BIND 設定ファイルで必要とされる形式で情報を戻してくれるからだ。ちゃんと動いているはずのネームサーバを dig(1) で調べて、自分の設定が正しいかどうか比べてみるといい。
もし自分のマシンに DNS サーバとして機能してほしいかどうかわからなければ、DNS の設定はしないほうがいい。OpenBSD インストールは、デフォルトでは DNS 機能は有効にしない(ただし必要ファイルはすべてインストールされている)。ワークステーションなら、単にローカルマシンの IP アドレスを記述した /etc/hosts ファイルと、イントラネットやインターネット上でどの DNS サーバが機能すうるかを示す/etc/resolv.conf さえあれば十分。
一方で、マシンを DNS として設定する必要があるケースも存在する:
もう一つ考えておくべきなのは実行速度。ドメイン名参照の解決は、何度もやりとりのあるプロセスで、ネームサーバは他のネームサーバに対して何度も遠くのドメインのアドレスについて問い合わせを行う。だからインターネットにモデム接続していて、リモートアドレスについて自分の DNS に問い合わせを行っている場合(すると DNS は何度もリモートのネームサーバにモデム経由で問い合わせを行うことになる)、ISP のネームサーバ(たぶんリモートのネームサーバに対する接続はこっちのほうが高速だろう)を使うよりもちょっと時間がかかることになる。
BIND は、DNS のふるまいの仕様の名前だ。DNS コンポーネントは、一体として BIND を実装するように存在している。
BIND 仕様には、まったくちがったものが二種類ある:
インストールしたままの状態だと OpenBSD namedがサポートしているのは BIND 4.xだ。
こういう別実装の DNS を使う人は、重要なネットワークサービスを提供するのに、基本インストールに含まれたセキュリティ監査済み named ほどのチェックを経ていないソフトを使うことになる。これはよくよく考えてみる必要がある。DNS が乗っ取られたら、そのネームサーバを使っているレゾルバは、にせものサイトに案内される可能性がある。
デフォルトのネットワークセットアップが、OpenBSD インストール時にきちんとインストールされたなら、必要なものはもう全部インストールずみだ。あとは name デーモン ("named")を設定すればいいだけ。
OpenBSD DNS の設定には、name デーモン namedをコントロールするファイルを編集・作成すればいい。このファイル群はデフォルトでは、/var/namedディレクトリとそのサブディレクトリに入っている。いちばん大事なのが、 /var/named/named.boot というファイルで、これはnamed の初期化ファイルだ。ほかにも、/etcの中にいくつかふむべき設定のステップがある。
このドキュメントでは、nemo.yewtopia.com を、とっても小さなドメインyewtopia.com の DNS にするように name デーモンを設定しよう。nemo.yewtopia.com のアドレスは 192.168.1.9で、このサブネットにはほかにマシンが2台のっかっている。crater.yewtopia.com が 192.168.1.1 で、earhart.yewtopia.com が 192.168.1.2だ。
; tell what subdir has the lookup database files directory /namedb ; type domain source host/file backup file cache root.cache primary 0.0.127.IN-ADDR.ARPA localhost.rev ; example primary server config: primary yewtopia.com yewtopia primary 1.168.192.IN-ADDR.ARPA yewtopia.rev
これで初期化プロセスに、yewtopia.com用の設定ファイルがどのサブディレクトリに何というファイルに入っているかが伝わるわけだ。
; Reverse lookup for localhost interface @ IN SOA nemo.yewtopia.com. your_id.nemo.yewtopia.com. ( 14 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS nemo.yewtopia.com. 1 IN PTR localhost.yewtopia.com.
; yewtopia.com domain database yewtopia.com. IN SOA nemo.yewtopia.com. your_id.nemo.yewtopia.com. ( 14 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS nemo.yewtopia.com. ; Addresses localhost.yewtopia.com. IN A 127.0.0.1 crater.yewtopia.com. IN A 192.168.1.1 earhart.yewtopia.com. IN A 192.168.1.2 nemo.yewtopia.com. IN A 192.168.1.9
; yewtopia domain reverse lookup database 1.168.192.in-addr.arpa. IN SOA nemo.yewtopia.com. your_id.nemo.yewtopia.com. ( 14 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600 ) ; Minimum 1.168.192.in-addr.arpa. IN NS nemo.yewtopia.com. ; Addresses 1.1.168.192.in-addr.arpa. IN PTR crater.yewtopia.com. 2.1.168.192.in-addr.arpa. IN PTR earhart.yewtopia.com. 9.1.168.192.in-addr.arpa. IN PTR nemo.yewtopia.com.
/etc/resolv.conf が、いまはローカルマシンのドメインを指しているかどうか確認しよう(ISP の DNS を指定したりしないように)。そうしないと、せっかく設定した named にドメイン名解決要求がいかないよ!
domain yewtopia.com lookup file bind
もしこれまでいろんなマシンのアドレスを /etc/hosts ファイルに記述してきた人は、/etc/hosts を縮めてデフォルトに戻したほうがいいかもしれない:
# Host addresses 127.0.0.1 localhost localhost.localdomain 192.168.1.9 nemo nemo.yewtopia.com
そうしないと、/etc/hosts ファイルの中のアドレスが(すでに古くなっていた場合)でも優先されて、named がバイパスされてしまう。 最低でも、デフォルトの localhost エントリくらいはあることを確認しておくように! さもないとネットワークがまともに動かない。もう一つ、nemo は独自の hosts ファイルに登場しなくてはならない。さもないと起動時 /etc/netstart が route(8) を呼び出して、nemo(これは /etc/mynameに名前が登場)を追加しようとするときにエラーメッセージを見ることになる(ただし実害はないけれど)。
$ dig @nemo.yewtopia yewtopia any any ; <<>> DiG 2.2 <<>> @nemo.yewtopia yewtopia any any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59904 ;; flags: qr rd ra; Ques: 1, Ans: 2, Auth: 0, Addit: 1 ;; QUESTIONS: ;; yewtopia, type = ANY, class = ANY ;; ANSWERS: yewtopia. 3600 SOA nemo.yewtopia. your_id.nemo.yewtopia. ( 14 ; serial 3600 ; refresh (1 hour) 900 ; retry (15 mins) 3600000 ; expire (41 days 16 hours) 3600 ) ; minimum (1 hour) yewtopia. 3600 NS nemo.yewtopia. ;; ADDITIONAL RECORDS: nemo.yewtopia. 3600 A 192.168.1.9 ;; Total query time: 4 msec ;; FROM: nemo to SERVER: nemo.yewtopia. 192.168.1.9 ;; WHEN: Tue May 2 23:47:19 2000 ;; MSG SIZE sent: 25 rcvd: 102
name デーモン named は、システムの起動時に /etc/rc から起動される。そのためには、/etc/rc.confにある
named_flags=NO # for normal use: ""
という行を、以下のように変更する。
named_flags="" # for normal use: ""
さらに /etc/rc.confの以下の行を調べて見よう。
named_user=named # Named should not run as root unless neccesary named_chroot=/var/named # Where to chroot named if not empty
このデフォルトは、ほとんどの設定でそのまま使えるはずだ。
named を手動でたちあげるには ndc(8) コマンドを使う。たとえば以下のとおり:
# ndc start or # ndc restart
name デーモンを止めるのにいちばんいいやり方は、ndc(8) コマンドを使うことだ。たとえば:
# ndc stop
こいつがうまくいかなければ、named のプロセス id を調べて、kill(1) コマンドでそのプロセスを終了させよう。実行中のnamed の PID は /var/named/named.pidファイルの最初の行を見てもわかる。
# cat /var/named/named.pid 4608 named -t /var/named -u named # kill -KILL 4608
name デーモンの実行中のインスタンスを再起動させて、変更した設定ファイルを読み込ませるには、 "hangup" 信号を送ってやろう:
# kill -HUP 4608
あるいはndc(8) コマンドを使ってもいい。たとえば:
# ndc restart
例:
garden:/home/jeremy$ host -l openssh.com openssh.com. NS zeus.theos.com. openssh.com. NS cvs.openbsd.org. openssh.com. NS gandalf.sigmasoft.com. openssh.com. NS cs.colorado.edu. openssh.com. NS ns.appli.se. openssh.com. A 199.185.137.4 cvs.openssh.com. A 199.185.137.4 localhost.openssh.com. A 127.0.0.1
この情報は、DNS のデバッグには便利だけれど、この出力がおおっぴらになってほしくない場合もあるだろう。もし逆引き用にクラスなしの in-addr(rfc2317) を使っていたら、host -l であなたのシステムがホスティングしているドメインが全部わかってしまう!
これをなおすのは簡単で、自分のゾーンファイルで「allow-transfer」を使えばよろしい。
Bind8 を使っているなら、個別ゾーンファイルで、どのゾーンの転送を許したいホストを指定してやる必要がある:
zone "foo.com" in { type master; file "directory/zonefile"; allow-transfer { 127.0.0.1; 10.0.0.6; 10.0.255.12; }; };
さらにすべてのドメインからの転送をブロックするには、 /var/named.conf を編集して、設定ファイルの「options」部分に「allow-transfer」パラメータを追加しておくこともできる。
options { allow-transfer { 127.0.0.1; }; };
Bind8 のやり方は、Bind9 でも使える。
もし Bind 4 (OpenBSDのデフォルト) を使っているなら /var/named/named.boot を編集して 'xfrnets' オプションを使うといい。
xfrnets 209.142.221.5 12.7.96.7 ; type domain source host/file backup file cache . root.cache primary 0.0.127.IN-ADDR.ARPA localhost.rev
Bind 4 は、クラス丸ごとからの転送を認めるので、それほど厳密じゃない。典型的には、転送をやらなきゃいけないホストは、DNS のスレーブとデバッグをやるホストだけだ (127.0.0.1 は、ふつうは転送を認めてもかまわないホストだよ!) AXFR 問い合わせをブロックすると、さらにプライバシーのレベルが追加されるけれど、でもこれをやると、DNS のデバッグをするには不便なこともある。 (このアドバイスについてはNicholas Tang に感謝)
書き漏らしたことなんか山ほどある。たとえば、イントラネットのドメインのうち、ドメインヒエラルキーのてっぺんから見えないドメインへの問い合わせが、社内のサーバにリレーされるようにするにはどうしたらいいか、とか。DNS について詳しくはおすすめのドキュメント を参照してね。
NOTE: これは ADSL プロバイダ すべてに適用できる話ではないけれど、ここでの設定を参考にすればかなりの情報が得られる。ここでの設定は、オーストリアの ADSL プロバイダ Inode ではうまく機能する。(訳注:日本だと PPPoE がほとんどらしいけど、どのくらいあてはまるんだろう?)
まず手始めに、pptp をインストールすること。OpenBSD のリリース後になって、pptp の port が ports ツリーに追加された。これは OpenBSD 2.8 ports ツリーで何の問題もなく動く。そのport は /ports/net/pptp にある。port について詳しくは FAQ 8.6 を参照。
カーネル内の gre(4) サポートと pptp がぶつかるので、カーネルをコンパイルしなおして、gre(4) のサポートをはずさないとダメだ。
GRE(4) サポートを取り除くパッチ
Index: sys/conf/GENERIC =================================================================== RCS file: /cvs/src/sys/conf/GENERIC,v retrieving revision 1.66 diff -u -r1.66 GENERIC --- sys/conf/GENERIC 2000/10/13 04:21:14 1.66 +++ sys/conf/GENERIC 2000/12/26 19:55:31 @@ -97,6 +97,6 @@ pseudo-device ksyms 1 # kernel symbols device pseudo-device bridge 2 # network bridging support #pseudo-device vlan 2 # IEEE 802.1Q VLAN -pseudo-device gre 1 # GRE encapsulation interface +#pseudo-device gre 1 # GRE encapsulation interface option BOOT_CONFIG # add support for boot -c
カーネルの再コンパイルには、cvs 経由で OpenBSD 2.8-stable をチェックアウトしよう(詳しくは OpenBSD Stable ウェブページを参照)、上のパッチを適用してから、FAQ 5.3にしたがってカーネルを再構築しよう。
pptp と新しいカーネルのインストールが終わったら、いくつかファイルを編集して接続用の設定をしよう。このパッケージはインハウスの OpenBSD ppp(8) を使うので、ppp(8) を知っている人には設定はほとんど同じだ。あと、 FAQ 6.5も参照。設定ファイルは以下の二つだ:
/etc/ppp/options のほうは、たぶん下のような設定で問題ないはず:
# cat /etc/ppp/options name "LOGINNAME" noauth noipdefault defaultroute debug
LOGINNAME は、あなたのユーザid を入れること。
/etc/ppp/pap-secrets はたった1行のファイルでこんな感じ:
# cat /etc/ppp/pap-secrets LOGINNAME 10.0.0.138 PASSWORD
LOGINNAME はあなたのユーザ ID で、PASSWORD にはあなたのパスワードを入れる。10.0.0.138 は、ADSL などを使っているときにはモデムに割り振られた IP アドレスだ。このファイルは、root だけが読み出し専用になっているように中尉すること(つまり mode 600)。
上の例では、モデムには 10.0.0.138 というアドレスの割り振られたネットワークインターフェースが最初っからついてきた。こんどは、こっちのインターフェースにアドレスを割り当てなきゃいけない。これには、モデムにもらった IP に近いものを選んでおくか、あるいは割り当てられた静的 IP アドレスを使うのがいちばんいい。インターフェースの設定について、詳しくはFAQ 6.1を読もう。
インターフェースの設定がすんだら、以下のコマンドでpptp 接続ができるはず:
# /usr/local/sbin/pptp 10.0.0.138 &
これはインハウスの OpenBSD ppp(8) を使うので、プロセスが二つ立ち上がる。pptp をキルするには、このプロセスを両方ともキルすることだ:
# kill -9 [pid of pppd] % kill -9 [pid of pptp]
何か問題があったらわかるように、別のターミナルウィンドウを開いて/var/log/messages を表示しておくのがお勧めだ。
# tail -f /var/log/message
また起動コマンドを /etc/rc.local に書いておいて、起動のたびに自動的に接続するようにしておくのがお勧めだ。
[FAQ トップに戻る] [5.0 - カーネル設定] [7.0 - キーボード]
www@openbsd.org 翻訳上の問題はhiyori13@alum.mit.edu
$OpenBSD: faq6.html,v 1.93 2001/04/18 17:59:57 ericj Exp $