domain - みる会図書館

1. UNIX MAGAZINE 1999年1月号

1998 年の秋に開催された SOCKS Summit のプレゼンテーション資料・の多くが、以下の Web ページで公開されています。・ socks5-stat の出力例連載 / 遠隔オフィスとの接続ー① ・ Next Generation SOCKS (about/pdf/nextgen ・ pdf) Tota1 Co Ⅱ . 4.8 Mb 260 . 2 Kb 0 . 0 8 . 1 10 . 7 0 . 0 : mI : (http://www.stardust.com/events/socks98/pres- ・ The SOCKS Summit 1998 -- - Conference entations ( あらい・みちこ ASTEC) Connection summary ー Sat NOV 21 04 : 05 : 03 1998 t0 Sun NOV 22 15 : 49 : 09 1998 Current time : Sun Nov 22 15 : 49 : 09 1998 lnput files : /var/adm/messages Date 0f first daemon 10g encountered in input : Sat NOV 21 04 : 05 : 03 1998 Date 0f last daemon 10g encountered in input: Sun NOV 22 14 : 00 : 02 1998 Number Number Number Number Number input lines processed : 2731 0f daemon lines processed: 2724 successful TCP connections: 90 requested UDP connections : 816 requested ICMP connections : 0 0f Of of 0f Tota1 combined connection time (da:hr:mi : (e) : 00 : 00 : 22 : 44 Data transferred from inside t0 out : 66 . 0 Kb Number of failed connections : 0 Fai1ed Connections Data transferred from outside tO in: 5 . 1 Mb Top 5 users by number 0f User@address unknown@leo . domain. CO ・」 p me@cat . domain. CO ・」 p you@tiger.domain ・ CO ・ JP he@tiger.domain ・ CO ・」 p root@cat . domain. CO ・」 p Top 5 users by amount 0f User@address me@cat . domain. CO ・」 p you@tiger.domain ・ CO ・ JP he@tiger.domain ・ CO ・ JP root@cat . domain ・ CO ・」 p connections : TCP Co ⅡⅡ . 0 47 39 3 1 UDP Conn . ICMP CO . 816 47 39 3 1 data transferred : 816 0 0 0 0 Tota1 Data 4 . 8 Mb 270.9 Kb 66 . 8 Kb 29 . 7 Kb 0 . 0 Source—>Dest Kb Kb 29 . 4 Kb 17 .7 Kb 0 0 0 0 0 Dest—>Source 49 . 1 Kb 223.0 unknown@leo . domain ・ CO ・ JP Top 5 users by time elapsed: User@address me@cat . domain. CO ・」 p he@tiger.domain ・ co ・ JP you@tiger . domain. co ・」 p root@cat. domain ・ CO ・ jp unknown@leo. domain. CO ・ JP da 00 : 00 : 00 : 00 00 : 00 : 01 : 20 00 : 00 : 01 : 21 00 : 00 : 03 : 56 00 : 00 : 16 : 07 : hr TOP 5 source addresses by number Of connections : UNIX MAGAZINE 1999.1 45

2. UNIX MAGAZINE 1999年1月号

Top 5 destination addresses Destination Address unknown ftp.ftpdomain.ad. jp WWW. somewhere . org matatabi . forcat . com Top 5 destination addresses Destination Address ftp.ftpdomain.ad ・ jp WWW. somewhere. org matatabi . forcat . com unknown Top 5 destination addresses 連載 4 . 8 Mb 0 . 0 0 . 0 0 . 0 : m1 : S e 00 : 00 : 16 : 07 00 : 00 : 05 : 16 00 : 00 : 01 : 21 00 : 00 : 00 : 00 Src—>Dst 49. 1 00 : 00 : 03 : 56 00 : 00 : 01 : 20 00 : 00 : 01 : 21 8 . 1 00 : 00 : 10 : 12 00 : 00 : 05 : 55 0 . 0 4 . 6 Mb 00 : 00 : 00 : 00 0 . 0 遠隔オフィスとの接続ー① Source Address 1e0. domain. co ・」 p cat . domain. CO ・ JP tiger. domain. co ・ JP Top 5 source addresses Source Address cat . domain ・ CO ・」 p tiger. domain ・ CO ・ JP 1e0. domain. co ・ JP Top 5 source addresses Source Address cat . domain. CO ・」 p tiger. domain ・ CO ・」 p 1e0 . domain. CO ・」 p Tota1 Conn . 42 48 816 TCP Conn . 0 48 42 UDP Conn . ICMP Conn . 816 0 0 amo ・ un. t of data transferred: Tota1 Data 337.7 Kb Source—>Dest 28 . 4 Kb 37.5 Kb 0 0 0 0 . 0 b 309.3 Kb 4.8 Mb Dest—>Source time elapsed: 00 : 00 : 00 : 00 00 : 00 : 05 : 16 00 : 00 : 17 : 27 da : hr : mi ・ Tota1 Conn . TCP Co n. number Of : UDP Conn . ICMP Co Ⅱ取 . 816 47 39 4 0 47 39 4 816 0 0 0 by amount of data transferred : Tota1 Data Source—>Dest 4 . 8 Mb 270. 9 Kb 96 . 4 Kb elapsed: 0 0 0 0 Dest—>Source 0 . 0 b 49.3 Kb 260.2 Kb 4 . 8 Mb time UDP 0 0 0 0 0 816 8 . 1 0 . 0 Dst 223.0 Kb Destination Address ftp.ftpdomain.ad ・ jp matatabi . forcat . com WWW. somewhere. org unknown A11 ports/services: Port/service 6666 7777 8080 ftp ftp—data unknown Restarts da 10 . 7 Kb 47.2 Kb —>Src TCP 3 1 39 1 46 0 : hr 0 0 0 0 0 0 I CMP da 17 . 7 Kb 29.4 Kb 10 . 7 Kb b b Kb 260.2 Kb 219. 6 Kb 0 . 0 Kb b b Socks5 was (re)started 0 times: End 0f summary . 46 : hr : m1 : S e UNIX MAGAZINE 1999.1

3. UNIX MAGAZINE 1999年1月号

連載 / 遠隔オフィスとの接続ー① リスト 1 user SOurce dest port detail failed restart mai 1 out socks5-stat. conf の例 me@cat . domain. CO. 」 p , t cat . domain ・ co ・ jp, t=5 WWW. somewhere . org , t=5 al 1 al 1 a11 me@cat . domain ・ co ・」 p = 5 # and aISO top 5 users "cat . domain. co ・ JP" and top 5 hosts # "www. somewhere . org" and top 5 destinations # a11 ports ShOW ShOW show send ・障書発生時に間題をくるために、必要に応じて Socks サーバーヘログインし、 Socks サーバー上の言算機から手動で socks5-stat を実行する。・出力結果をメールで送信するか標準出力に出力するか・ Socks サーバーの再起動回数を表示するかどうかか・失敗した接続の情報を田に表示するか簡略に表示する・順位表示する数号 ( サービス ) の指定表示するユーサー、ネットワーク ( ホスト ) 、ポート番以下の項目を言当します。 socks5-stat の設定ファイノレ socks5-stat. conf には、行する。機にコピーし、必要に応して手動で socks5-stat を実するために、ログファイルを定期的にローカルな計算特定のユーサーや計算機、サービスの状況を頻繁に監視リスト 1 は、 socks5-stat. conf の例です。ルには、ん e vo 司礰リ [ , 佖 [ , のリ [ , の形式で設定を言当します。ん e 00 には、このファイリストに示したものを使うことができます。 user" では、角財斤したいユーサーを、社・れ佖 7 e@a07れ 02 れれ 07 e または、 t=n の形式で指定します。す。 42 、 t = れ " は順位表示する数の指定で a detailed user report a11 failed connections (default) a11 daemon restarts the summary via email source" および、、 dest" の指定は、発信元アドレスおよひ宛先アドレスの順位表示に関するものであることを除けば、 user の場合と同様です。、 port" は使用状況を角斤するポート番号 ( サービス ) を指定します。ーはすべてのポートを意味します。、、 detail" はユーサー情報を詳細に表示するかどうかを指定します。引数として指定できるのは a Ⅱまたは n 。 ne で、デフォルトは none ( 言田を表示しない ) です。、、 failed" は失敗した接続に関する情報の表示形式を指定します。引数として指定できるのは all または mini- mum 、 none で、デフォルトは all ( 聞帯にを表小する ) restart" は Socks5 の起動や再起動の状況に関する表示を指定します。引数として指定できるのは all または none で、デフォルトは none ( 再起動の状況を表示しない ) です。最後の、、 mailout" は、 socks5-stat の出力結果をメールで送るように指定します。引数の、、 me@cat.domain. co. jp" は送信先の電子メールアドレスです。これで、 socks5-stat スクリプトを実行する準備か整いました。 socks5-stat コマンドの実行 socks5-stat スクリプトと socks5-stat. conf ファイルを正しく設定したら、オフションなしで socks5-stat スクリプトを実行してみましよう。定の内容に従って、 Socks サーバーのログの角財斤結果か表示 ( またはメールで送信 ) されます。 $ socks5—stat UNIX MAGAZINE 1999.1 ログを角斤する期間を設定することができます。以下に 4 オプションを指定すれは、設正ファイルを変更したり、

4. UNIX MAGAZINE 1999年1月号

連載 / UN Ⅸの玉手箱ー① 以下に挙げる 3 不頁のキーワードがあります。・ nameserver UNIX MAGAZINE 1999.1 できます。 8 最大 6 つ ( 全体で 256 文字以のドメインをスペースて区切って指定 DNS サーバーに間い合わせます。とができます。この場合、 /etc/resolv. conf に書かれた順番に従って 7 FreeBSD と Solaris では、最大 3 つの DNS サーバーを孑旨定するこがいいでしよう。場合は検索にがかかるため、通常は指定しないほう索されます。当然、ドメインがローカルドメインでないリストを指定すると 8 、指定されたドメインか順番に検これに対し、 search キーワードの値としてドメインの対しておこなわれます。キーワードで得られるドメイン ( ローカルドメイン ) にホスト名のみで与・えた場合、ホストの検索は domain 通常、間合せの対象となるホストを FQDN ではなく意が必要です。メインの DNS サーバーに間合がおこなわれるので主トはルートドメインに属するものとみなされ、ルートドメイン名が含まれない場合は、間合の対象となるホスローカルドメインとして扱われます。このホスト名にドドでケえたホスト名 (FQDN) に含まれるドメイン名が domain キーワードを省略すると、 hostname コマンドメインのホストか検索の対象となります。おくと、間合迂にホスト名のみを用いた場合、ローカルドメイン ) を与・えます。 domain キーワードを言殳定して値として、クライアントカ嘱するドメイン名 ( ローカル・ d01na111 DNS サーバーとみなされます。いうキーワードか書かれていないと、ローカルホストがします 7 。なお、 /etc/resolv. conf に nameserver とれぞれの DNS サーバーの IP アドレスを 1 っすっ指定利用したい場合は、 nameserver キーワードを用いてそ置いていることがあります。複数の DNS サーバーをきるよう、同しドメイン内に複数の DNS サーバーをバーがダウンしたときにも他のサーバーが処理を代行で DNS サーバーにかかる負荷を分散させたり、あるサードレスをドット表記で指定します。細織によっては、値として、間・作をおこなう DNS サーバーの IP アたとえは、 f00. co. jp の DNS サーバーの IP アドレスが 192.168.1.2 である場合、このドメインに属するクライアントの /etc/resolv. conf は以下のようになります。 domain f00. co . 」 p nameserver 192.168.1.2 # ns . f00 . co ・」 p FreeBSD の場合、 OS のインストール時に DNS クライアントの設疋をしていなけれは、 /etc/resolv. conf ファイルは作成されません。このような場合はエデイタなどを使って新たに作成する必があります。 BSD/OS と So- laris の場合も同様に、 /etc/resolv. conf ファイルを新たに作成します。 /etc/hosts と NIS 、 DNS の併用ホスト名と IP アドレスを管理する仕組みとして、ローカルな /etc/hosts と NIS および DNS の 3 つを紹介しましたが、これらを組み合わせれは、相互補完的に利用することができます。去もの UNIX は、どの情報源をどの順番で検索するかを指定でき、 FreeBSD は /etc/host. conf. 、 BSD/OS は /etc/irs. conf 、 Solaris は /etc/nsswitch. conf というファイルを使って設正します。 FreeBSD の /etc/host. conf FreeBSD か利用する /etc/host. conf ファイルは単純で、 /etc/hosts は、、 hosts" 、 NIS は、ⅲ s " 、 DNS は、 bind " というキーワードに対応しています。これらのキーワードを使い、利用したい情報原を検索する順番に列挙します 9 。 FreeBSD をインストールした直後の /etc/host. conf を図 3 に示します。 bind (DNS) と hosts (/etc/hosts) を使い、 nis (NIS) はコメントアウトされて使わない設定になっています。 NIS を利用するときは、キーワード nis の地頁にある、、 # " を削除します。この場合、ホスト情報を検索する手順は以下のようになります。 1. 最初に DNS サーバーに問合せをおこない、十館きに失敗したらローカルな /etc/hosts ファイルを参照する。 2. /etc/hosts を検索して該当するエントリがみつからなけれは、 NIS サーバーに間い合わせる。 9 キーワードは 1 行に 1 っすつ定し、、 # " 以降はコメントとみなされます。 115

5. UNIX MAGAZINE 1999年1月号

連載 / コミュニケーション用サーパーのインストールと運用ー① 図 6 スプールホストの def ファイル ( ダイヤルアッフ竟 ) LOCAL_HOST_IPADDR=192.168 CHECK_RELAY_DEFAULT=deny CHECK_HOST_ALLOW=192.168 USERTABLE—LOCAL—REWR 工 TE=yes USERTABLE_MAPS= ) local=hash : /etc/ut .10Ca1 ' DEFAULT_RELAY= ' smtp : smtpserver. provider. ne DIRECT_DELIVER_DOMAINS= ' $m' BITNET=auto SMTP8_MAILER_FLAG_SUB= 'M ' ESMTP_MAILER_FLAG_SUB= 'M ' SMTP_MAILER_FLAG_SUB= 'M ) ALWAYS_APPEND_DOMAIN=yes L OWER_MATCH_ STYLE=any ACCEPT_LOWER=yes ACCEPT_ADDRS= ) $m ' REWRITE_GENERIC_TO=10wer REWRITE_GENERIC_FROM=10wer RECIPIENT_GENERIC=yes FROM_ADDRESS= ) $m ' OS_TYPE=bsd4.4 CF_TYPE=R8V8 UNIX MAGAZINE 1999.1 解説は省いて簡単に説明します。ューザーのホーム・ディ現在も頻繁 ( ンヾージョンアップされているので、詳細のミラーをおこなっているようです。 pub/network/mail/fetchmail/ でもアーカイプのみの / fetchmail / で公開されています。 ftp://ftp.win ・ or ・ jp/ このソフトウェアは、 http://www.tuxedo.org/-esr して、 fetchmail があります。か簡単になります。このような動作をしてくれるツールとからはローカルスフ。ールのみを参照すれはいいので、成疋ルをローカルのメールスプールに交ぜてしまえは、 N'IUA このような状況で、 POP サーバーから取ってきたメーバーから拾う必要があります。す。これに対し、外部からのメールは ISP 上の POP サーそれらのメールは LAN 内のスプールホストに蓄えられま LAN 内のホストどうしでメールのやりとりができます。このように LAN 内でメールシステムを作った場合、 fetchmail の利用 LOCAL_HOST_IPADDR=192.168 CHECK_RELAY_DEFAULT=deny CHECK_HOST_ALLOW=192.168 RELAY_MAILER_FLAG_SUB= ' M ) SMTP8_MAILER_FLAG_SUB= ) M ) ESMTP_MAILER_FLAG_SUB= ' M ' SMTP_MAILER_FLAG_SUB= ) M ) SPOOL_HOST=sp001host . private—network. jp OS_TYPE=bsd4.4 CF_TYPE=R8V8—nu11 図 7 そ也のホストの def ファイル ( ダイヤルアッフ竟 ) 図 8 /etc/ut. local 列図 9 . fetchmailrc 列 youichi : mailname koyama@provider.ne ・ JP defaults protocol pop3 Ⅱ 0 mimedecode # isp isp rules P011 popserver. provider. ne ・ JP user koya.ma pass honyarara レクトリに . fetchmailrc という名則で図 9 のようなファイルを準備しておき、そのユーサーがメールを拾いたいと思ったときにコマンドラインから fetchmail を起動すると、 POP サーバーから取ってきたメールをローカルにスプールしてくれます。 p 。 11 で POP サーバー名を指定し、 user と pass には、 ISP の POP サーノヾーでのユーザー名とパスワードを指定します。重川原理としては、 fetchmail は指定された POP サーバーからメールを取ってきたあと、エンべロープの受信人として fetchmail を実行したユーサー名 (@以下がないもの ) を設定したうえでローカルの SMTP サーバーに接続して引き渡すだけです。実際にスプールをおこなう作業は sendmail などに任されるので、 sendmail.cf などは適切に設定する必要があります。この際、エンべロープの受信人に設定されるユーサー名としては、環境変数 USER があればその内容を利用し、なけれは環境変数 LOGNAME を、それもなければ実効 UID からパスワード・ファイルを利用して決定する仕組みになっているようです。毎回 fetchmail コマンドを実行するのか面倒ならは、次のような行を . fetchmailrc に追加すると、デーモンモードとして動作し、 300 秒ごとに POP サーバーをチェックしてくれるようになります。 set daemon 300 今回の例は、私訟、丘なところで実際に使っている設定を中心に解説してみました。これはあくまで設定の一例にすぎす、同じ目的を果たすのにもっと別のよい鮹夬法があるかもしれません。 CF の日本語マニュアルには丁寧な解説があります。それらを参考に、よりよい設定を目指して ☆ ください。 39 にやま・よういち京都大学 )

6. UNIX MAGAZINE 1999年1月号

連載 / コミュニケーション用サーパーのインストールと運用ー① 本を 1 つのドメイン (daigaku ・ ac. (p) て漣用し 1 、メールスフ。ールも 1 台だけだったのが、ユーサーか増えたので研究室ごとにサブドメインを準備し、メールスプールも各研究室ごとに確保したいようなときは、どのように設定すれはよいのでしようか。この場合、単純にメールスプールをサブドメインごとに準備すると、これまで user@daigaku.ac.jp といった形式のアドレスを利用していたユーザーに対して、今後はれSe7迥工む1ab. daigaku. ac. jp という形式のアドレスの利用を強いることになります。もちろん、ユーザー数か増えたのでユーサー名の衝突を避けるという目的で分割するのであればそれでもよいでしよう。しかし、たんにスプールの容量を自山に確保できるように分割する場合などは、従来のメールアドレスをそのまま利用し続けたいこともあります ( もちろん、ユーサー名は従来どおり大学全体で一となるような付け方をします ) 。そのときは、次のようなホスト構成を用います。・従来の、、大学全体でのメールスフール " を担当していたホスト ( ここでは、ホスト名を hubhost. daigaku ・ ac. jp とします ) をハプホストにし、従来どおり daigaku. ac. jp ドメインの MX (Mail eXchanger) とする。・各研究室ごとに設けられたサブドメイン ( ェ ab. daigaku ・ ac. (p) に対応する研究室内ューサー専用のメールスプール用ホストを 1 台すっ準備し ( ホスト名を spoolhost.m-lab. daigaku ・ ac. jp とする ) 、そのホストを工む1ab. daigaku ・ ac. jp ドメインの MX とする。・ユーザーがどのホストから発信しても、従来どおり From : 以下に user@daigaku.ac.jp が付くようにする。・学の外から use@daigaku.ac.jp に出されたメールは hubhost. daigaku ・ ac. jp に届くので、このスト上で /etc/aliases か . forward を用いて、各研究室のスプールホストに中幻医する。このようにすると、メールスプールが分かれたこと以外は、従来と変わらない使用感をユーサーに提供できます。ただし、従来は学内のユーサーに対してはすべて社 set 、のみの (@以下がない ) アドレスでメールを出せたのが、各研究室ごとにスプールホストを置いたために、他の研 1 ここでは大 : 本を例にしましたが、適「学部本」や「学利全体」のように読み替えてください。 UNIX MAGAZINE 1999.1 図 1 ハプホストの def ファイル CF_TYPE=R8V8 OS_TYPE=bsd4.4 FROM_ADDRESS= ' $m' ACCEPT_ADDRS= ' $m' BITNET=auto LOCAL_HOST_DOMAIN= ' daigaku ・ ac ・ jp ALLOW-RELAY_TO= ' daigaku ・ ac ・ jp 図 2 スプールホストの def ファイル ( ハプホストを用いる構成 ) CF_TYPE=R8V8 OS_TYPE=bsd4.4 FROM_ADDRESS= ' xx—lab. daigaku ・ ac ・ JP RECIPIENT_GENERIC=yes ACCEPT_ADDRS= ' $m' ACCEPT_LOWER=yes LOWER_MATCH_STYLE=any SPECIAL_FROM= ' daigaku. ac ・ jp ) SPECIAL_USERS= ) /etc/mail/users-in-daigaku' HUB_HOST= ' hubhost . daigaku ・ ac ・ jp REMOTE_USERS= ' /etc/mail/users—in—daigaku ) NON REMOTE_USERS= ) /etc/mail/users—in—lab ) RELAY_LOCAL_TO_HUBHOST=no LOCAL_STICKY=yes B I TNET=aut 0 PRIVACY_FLAGS= ' goaway' LOCAL_HOST_DOMAIN= ' xx—lab . daigaku ・ ac ・ JP ALLOW_RECIPIENT_DOMAIN= ) xx—lab. daigaku ・ ac ・ jp 究室のユーザー宛のメールについてはドメイン部分を省略できなくなります。これは、宛先が他の研究室のユーサーのメールはいったんハプホストに転送し、そこで /etc/ aliases などの処理を施したのち各スプールホストに送ることで対処できますにれが、ハプホストと呼ばれる理山です ) 。ただし、この機能を用いた場合も、学外へのメールについてはハプホストを経由せす、茁妾スフ。ールホストから酉当されます。 CF には、このような環境に対応するための設定変数として HUB-HOST が、はかの関連する変数として RE- MOTE-USERS と NON-REMOTE-USERS があります 2 。これを使った def ファイルの記述例を、ノ、フホスト " 、、 ( 各研究室の ) スプールホストその他のホスト " の 3 不鶤頁に分けて、図 1 ~ 3 に示します。この設定では、各研究室用のスプールホスト (spool- host.m-lab. daigaku. ac. (p) 上に、 /etc/mail/users-in -daigaku と /etc/mail/users-in-lab というファイルを準備する必要があります。前者にはすべての学内ューサー 2 なぜか NON-REMOTE-USERS については MANUAL. jpn 中に解第ありませんが、 Standards/sendmaiI-v8. def などには言当生があリます。 35

7. UNIX MAGAZINE 1999年1月号

DAEM 〇 NS & DRAG NS 0 サプネットの適刀な構成法 •William LeFebvre アドレス空間を有効利用するため、 IP ネットワークを複数のサプネットに分割する手法がよく利用されている。しかし、サプネットの彳難リを誤解していると、設引、を誤って混乱を招く可能性がある。また、クラスレスな糸子路制御方式 (CIDR: CIassIess Inter-Domain Rout- ing) の出現もこの問題を複雑にしている。今回は、伝統的なサプネットの構成法とその制約事項を紹介したあと、クラスレスな辛各制御によってサプネットのルールがどのように変わるかを考察する。 IP アドレスに詳しい人であれは、クラス A 、 B 、 C という 3 つのアドレスクラスをご存しだろう。それぞれのクラスは、アドレスのネットワーク部とホスト部の境界が異なる。各クラスの境界は図 1 のようになっている。バケットが、ローカルではないネットワーク (nonlocal network) 1 に送られる場合は、経路に対するすべての判断はアドレスのネットワーク部だけをもとにしておこなわれる。 IANA (lnternet Assigned Numbers Authority) は、 IP ネットワークのネットワーク番号の発行権限を InterNIC に委譲している。ある組織がネットワーク ( ネットワーク番号 ) をケえられると、ネットワークのアドレスをさらに分割してサプネットを構成することができる 2 。内部ネットワークを設言 1 するときは、はしめにサプネ 1 、 distant network" と呼ぶこともある ( 訳注 : 本文では、リモート・ネットワーク " と呼」 : ) 。 2 訳注 : 現状では、内部ネットワークにはプライベート・アドレス ( 10.0.0.0 ~ 10.255.255.255 / 8 、 172.16.0.0 ~ 172.31.255. 255 / 12 、 192.168.0.0 ~ 192.168.255.255 / 16 ) を使い、割り当てられたネットワーク番号 ( グローバル・アドレス ) はファイアウォールの外側のホストだけに使うのが一 -- 勺である。 UNIX MAGAZINE 1999.1 from UNIX REVI. EW 図 1 IP アドレスのクラス 31 クラス A クラス B クラス C 133 ネットワーク部ネットワーク部ネットワーク部 170 6 ( 例 ) ホスト部ホスト部ホスト部ット番号とホスト番号の境界を決めなければならない。この作業をすることで、 2 つの部分から構成されていたアドレスは、ネットワーク部とサプネット部、ホスト部の 3 つに分割されることになる。選択した境界はサプネットマスクとして表現され、通常は 10 進数をドットで区切った表記が用いられる。値が 1 のビットは、アドレスのネットワーク部かサプネット部に対応する。たとえば、 255.255.255.0 は標準的なクラス C のネットマスクに相当する。 255.255.255.224 の場合は、最後のオクテットの 3 ピット目が境界で、残りの 5 ビットがアドレスのホスト部になる。サプネットの境界か決まったら、内部ネットワークのそれぞれにサプネット番号を割り当てる。ホストのアドレスは各サプネット内で割り当てることができる。この時点で、 2 つのホストアドレスが予約されていることに注意してほしい。ホストアドレスが 0 の場合は物理ネットワーク物本を表し、ホストアドレスのピットがすべて 1 の場合はプロードキャスト・アドレスになる。あるサイトが 133.170.0.0 というクラス B のネットワーク番号を割り当てられているとしよう ( 図 2 ) 。ネットワークの設言としては、アドレスの 3 番目のオクテッ 105

8. UNIX MAGAZINE 1999年1月号

CIDR によるネットワークの再構成 by Larry Bennett •f 「 0n1 Performance Computing ほんのすこし前まで、インターネットの世界はそれほど広くなく、 1 つの IP 経路制徊俵さえあれは考えうる目的地をすべて糸できた。インターネットが急に拡大すると、糸習各制御表のサイズもそれにともなって大きくなり、管理か難しくなってきた。膨大な量の清幸ミ飛び交うなかで、ネットワーク・バケットをそれぞれの目的地に振り分けるルータにかかる負担か増大した。アドレスの間題は、 128 ビットのアドレッシング能力をもつ IPv6 により長期的には角夬されるだろうが、 IPv6 の普及にはまた時間がかかる。去麒月的な対策として、 IPv4 を拡張する技法が開発、実装されるようになった。それが CIDR (Classless Inter-Domain Routing) である。 CIDR には次のような特徴がある。 1. ネットワーク・クラスの放棄によりス→ヾーネット 1 化が可能になる。 2. プロックアドレス割当てを実装する。 3. 階層型の糸各制御カ呵能になる。こでは、 CIDR の機能について解説し、インターネットの IP アドレス構成と糸響各制御に関する問題点を考える。ます、 IP アドレスの基本を簡単にみておこう。たとえは、インターネットのようなシステム似ード、インターネットワーク ) は、ルータで接続された 2 つ以 E の論理ネットワークによって構成される。現在の IP (v4) では、インターネットワーク上の各システムはインターフェイスごとに 32 ピットの IP アドレスをもっている。 IP アドレスは、扱いやすいようにドット付きの 10 進数表記で表現され、 8 ビットすつの 4 グループに分 1 連続するネットワーク・アドレスをもっ 2 つ以 E のネットワークを組み合わせたもの ( 。 UNIX MAGAZINE 1999 ユけて記述される。たとえば、 2 進数で表されたアドレス 10000010 00100011 10010110 00000011 は、 10 進 ~ 去では 130.35.150.3 と表記される。 IP アドレスは 2 つの部分に分割される。ネットワーク ID ( ネットワーク・プレフィックスとも呼はれる ) が 1 つの論理ネットワークを表し、ホスト ID はそのネットワーク上の特定のホストを定義する。 2 つの部分の境界は 32 ビットのあいだのどこかに存在する。従来のアドレス構成法は、、クラスフル・アドレッシング " とも呼はれ、ネットワーク・クラスによって境界が異なっている。最初の 0 が何ビット目にあるかによって、そのアドレスが ( A 、 B 、 C のうち ) どのクラスに属しているかが分かる。図 1 に、 3 つの従来型アドレスクラスを示す。ロサプネットとネットワーク・マスク残念ながら、従来の IP アドレスの使い方では、現代のインターネットワークで必喫とされる能力を囎軍することはできない。たとえは、最大 65 , 534 のホストを収容できるクラス B アドレスをもつ Beech 社があるとしよう。 Beech 社はそれだけの数のシステムを 1 つのネットワークて運用するのではない。 TokenRing や Ethernet などによるいくつかのネットワークを細系調内で使っている。そこで、ネットワーク管理者はサプネットを用いて、管理が容易になるようにクラス B のネットワーク・アドレスをいくっかの部分に分割する。ホスト ID とネットワーク ID のあいだの境界線を動かしてアドレスをサプネット化し、ネットワーク部分により多くのピット数を・与える。ネットワーク上のホストとルータには、 IP アドレスとともにサプネットマスクが与えら 81

9. UNIX MAGAZINE 1999年1月号

スのデータベースを正しく管理することは、ネットワーク環竟でホストを利用するためのもっとも基本的な設定であるといえます。ローカル管理とリモート管理ホスト名と IP アドレスのデータベースを管理するにはいくっかのガ去がありますが、いずれの去であ最終的にはホストやネットワークの管理者が手作業で糸財寺することになります。データベースを誰 ( どのホスト ) がもつかによって、管理ガ去は以下の 2 つに大きく分かれます。連載 / IJN Ⅸの玉手箱ー① 前者を、、ローカル管理 " 、後者を・特定のホスト ( サー。ー ) がデータベースをもち、残りすべてのホストがローカルにデータベースをもつガ去、、リモート管理 " と呼ぶことにします。こでは便宜的にのホストはサーバーに間い合わせる・去 UNIX MAGAZINE 1999 ユ hosts) というファイルか 1 司凵齬リをもっています。トールされているディレクトリ *hosts" ( たとえ tiC:*Windows* 2 Windows 95 / 98 や Windows NT では、、、 Windows カゞインス NIS のサーバーにはマスターとスレープの 2 不頁があり NIS は、 1 つのサーバーでデータベースを管理します。情報を得るため、データベースをもつ必がありません。トは、必要なときにサーバーに間い合わせることによってデータベースを特定のサーバーカ理します。クライアンテムでは、図 l-b のように、ホスト名と IP アドレスの (Domain Name System) が代表的です。これらのシスで、 NIS (Network lnformation Service) や DNS そこで考案されたのがリモート管理に分類される方法 NIS と DNS スか起こる可能生も高くなります。新の手間も増え、更新を忘れたり登録を間違うといったミはそれでもよかったのですが、ホストの台数に比例して更した。ネットワークに接続されるホストの数が少ないうちホストがもつデータベースを更新しなければなりませんではこのガ去しかなく、ホスト情報に変更があった場合は全 UNIX マシンでネットワーク竟を構築し始めた当初します 2 。では、 /etc/hosts というファイルがデータベースに相当れたホストすべてがデータベースをもつ去です。 UNIX ローカル管理は図 1 ー a のように、ネットワークに接続さ図 1 ホスト情報データベースの里 ( a ) ローカル管理ホスト情報データベースロホスト情報データベース ( b ) リモート管理サーバーロアータベース問合せ応答クライアントロホスト情報データベースデータベースロロクライアントクライアントますが、スレープはマスターがもつオリジナルデータのコピーをもっているサーバーであり、マスターか利用できないときの代替サーーとして機能します。 NIS を階層的な管理が - 可能なように拡張した NIS 十というシステムもあり、 SoIaris などてイ吏用されています。これに対し、 DNS は管理範囲ごとにサーバーを置き、その管理範川内の情報をデータベースて管理します。クライアントはつねに管理範囲内のサーバーに対して問合ををおこないますが、管理乖観月外のホストに関す引帯にを知りたい場合は、そのサーバーが別のサーバーに対して問い合わせて結果をクライアントに返します。いすれの場合も、サーバーのもっデータベースは管理者が手竹喋て財寺しなけれはなりません。しかし、データべースはサーバーて集中的に管理されているため、ローカル管理にくらべてイ 1 喋の負担はかなり軽減されます。さらに、 NIS や DNS ではホスト名と IP アドレス以外の情報を管理してクライアントに提供できます。たとえば、 NIS は前々回に紹介したパスワード情報やグループ情報をはしめとするさまざまな情報を扱うことができ、 DNS はそれぞれの管理範囲にあるメールサーバーなどの情報を提供す 111

10. UNIX MAGAZINE 1999年1月号

連載 / UN Ⅸの玉手箱ー① NIS UNIX MAGAZINE 1999 ユ覧ください。味のある方はオンライン・マニュアル gethostbyname(3) などをご 3 具ー勺には、 gethostbyname() などのライプラリ関数を指します。興して /etc/hosts 、 NIS 、 DNS のどれを利用するかといっこれに対し、 FreeBSD や BSD/OS では、情報源とありました 3 。のライプラリ関数を NIS 対応のものに入れ替える必要がドレスの変換に NIS を使うには、変換をおこなう c 言語てやらなければなりません。旧い OS でホスト名と IP アて NIS を利用するには、 NIS を使うことをマシンに教え IP アドレス ( あるいはその逆 ) を得るための情報源とし実際に他のホストにアクセスする際に、ホスト名からはおこなわれません。マンドを実行する際、ホスト名から IP アドレスへの変換はできますが、 telnet や rlogin などのネットワーク・コけの状態では、 NIS サーバーからの hosts マップの参照ただし、 NIS クライアントとしてセットアップしただ bash$ ロ 192.168.1.11 Ⅱ ullpc. f00 ・ co. jp nullpc fs bash$ ypmatch 192.160.1.11 hosts. byaddr 192 .168.1.15 somepc. f00 . co. jp somepc bash$ ypmatch somepc hosts 192.168.1.15 somepc . f00. co ・ jp somepc 192.168.1.11 nullpc. f00. co ・ jp nullpc fs 192 .168 . 1 . 10 mypc. f00. co. jp mypc bash$ ypcat hosts て特定のホス日辭長を検索することができます。 hosts マッフの一覧を表示したり、 ypmatch コマンド ypbind が正常に動いていれは、 ypcat コマンドでう名前で指定できるようになっています。のマッフです。 hosts. byname マッフは、、、 hosts" といで、後者は IP アドレスをキーとしてホスト名を得るためスト名をキーとして IP アドレスを検索するためのマッフ hosts. byaddr というマッフ。で管理されます。前者はホ NIS サーバーでは、ホスト情報は hosts ・ byname とば、 NIS サーバーからホスト情報を得ることができます。 NIS ドメイン名を設疋して ypbind デーモンを起動すれた。あるホストを NIS クライアントとして利用する場合、いては、連載の第 5 回 ( 1998 年 11 月号 ) で紹介しまし NIS の概要と NIS クライアントのセットアップにつたことや、複数の情報源を併用する場合の優回立を設定ファイルて指定できるようになっています。具ー勺な設定ガ去については DNS のあとに紹介するので、 NIS のホスト情報を利用する場合はそちらを参照し、適切に設定してください。なお、 FreeBSD マシンを NIS サーバーとして設定する方法については、次回で詳しく紹介する予定です。 BSD/OS には、残念ながら NIS サーバーに必要なデーモン・プログラム (ypserv) などが付属していません。 DNS DNS は連載の第 3 回 ( 1998 年 8 月号 ) でも触れたように、ホスト情報をインターネット全体で分散管理することを目指し、米国のインターネットの前身である ARPA- NET で開発されたシステムです。 DNS 自体はサーーの構成や間伶をなどのプロトコルを定めた、、仕様 " であり、 RFC1034 や RFC1035 などで規定されています。 DNS の仕様にもとづき、カリフォルニア大学バークレイ校が実装したサーバーなどのプログラム群が BIND (Berkeley lnternet Name Domain) と呼はれるノヾッケージで、 BSD 系の UNIX のみならす、多くの UNIX で使われています。 DNS の仕組みやプロトコルの詳細については本誌の「 UNIX Communication Notes - ー BIND による名則管理 ( 1 ) ~ ( 5 ) 」 [ 1 ] 、サーバーのセットアッブガ去については「 UNIX 知恵袋ーネームサーバなどを参照していただくとして、ある DNS サーバーが管理するネットワークの範囲はゾーン (zone) と呼はれます。ゾーンは DNS サーバーカ嘱するドメインに対応する場合もありますし、そのドメインに加えて ( 複数の ) 下位ドメインも含む場合もあります。こでいうドメインとは、 FQDN のドメイン名が示すドメインと同しで、 UNIX のファイルシステムのようにツリー状の階層構造をもちます。ツリーの項点は、、ルートドメイン " と呼ばれ、ルートドメインの直ードは国などを表すドメインて構成されます。たとえば、日本であれば、、 jp " 、英国であれば、、 uk" などとなっています。国を表すドメインの下は系の不鶤頁や地域を表すドメインて構成され、 jp ドメイン ( 日本 ) の場合、企業を表す 113