Provided by:
manpages-ja_0.5.0.0.20060115-1_all 
TCPMUXス
xinetd は RFC 1078 に準拠した TCPMUX サービスをサポートする。
サービスがそれに対応する well-known ポートを持たなくても、 well-known
ポートである TCPMUX を通じてアクセスがでい襦
TCPMUX を通じてアクセスされるサービスは、それぞれ /etc/xinetd.conf
にサービスエントリーを持つか、もしくは includedir
ディレクトリの設定ファイルにサービスエントリがなければならない。
service_name フィールド(各 xinetd
の設定ファイルで、サービスの最初で定義される)は xinetd に(RFC 1078
プロトコルによって)渡される文字列に等しくなければならない。
それはリモートのサービス要求者が最初に well-known ポートである TCPMUX
に アクセスしたとい謀呂気譴襦
プライベートなプロトコルは高い確率で一意になるサービス名を使うべい澄
ひとつの方法は、ドメイン名の前にサービス名を付加することである、
type フィールドは TCPMUX または TCPMUXPLUS のどちらかである。
TCPMUXPLUS が指定された場合、 xinetd
はサービスを初期化する前にプロセス呼び出して、 (RFC 1078
で定義される)プロトコルの最初のハンドシェイクを処理する。 type が
TCPMUX
の場合は、ハンドシェークを遂行するために開始されているサーバが対処する。
サービスが標準的なシステムファイル (RPC サービスなら、 /etc/rpc,
RPCサービスでないなら /etc/services など) に無い場合は、 type には
UNLISTED も指定する。
これらのサービスに対する socket_type は stream でなければならず、また
protocal は tcp でなければならない。
以下は TCPMUX サービス設定のサンプルである。
service myorg_server
{
disable = no
type = TCPMUX
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/etc/my_server_exec
}
well-known ポートの TCPMUX を通じてアクセスされる各サービスの
サービスエントリの他に、TCPMUX 自身のサービスエントリも xinetd
の設定の中に含まれなければならない。 以下のサンプルを見よ:
service tcpmux
{
type = INTERNAL
id = tcpmux
socket_type = stream
protocol = tcp
user = root
wait = no
}
意
1. 以下のサービス属世蓮∈得瀋蠅琶儿垢垢襪海箸_socket_type,
wait, protocol, type である。
2. 属 only_from と no_access
が(直接、defaultsのどちらでも)指定されなかったサービスは、
アドレスの照合は成功したものとして扱われる
(すなわち、アクセスは拒否されない)。
3. アドレス照合はリモートホストの IP アドレスとを基にしており、
ドメインアドレスには依らない。
長い時間がかかるリモートホストの名前検索を避けられるので、そうなっている
(なぜならば、 xinetd は単一スレッドであり、
名前検索はデーモンがその検索を終えるまで、
他の全ての要求を受け付けるのを妨げるからである)。 この枠組の-
い面は、リモートホストの IP アドレスが変わってしまうと xinetd
を再設定するまでは、アクセスが拒否されてしまうことである。
アクセスが実際に供されるかどうかは、 新たな IP
アドレスが許可されたアクセスにあるかどうかによる。 例えば、ホストの
IP アドレスが 1.2.3.4 から 1.2.3.5 に変更され、 only_from が
1.2.3.0 と指定されていれば、アクセスは拒否されない。
4. ログオプション USERID が指定され、もしリモートホストが ident
サーバを動かしてないか、または ident
サーバが壊れた返事を送り返してい燭蕁 サービスフラグ IDONLY
が使われない限り、アクセスは拒否されない。
5. プロセスをフォークし、
それがリモートホストとローカルサーバの間でフィルタとして振舞うことにより、
横取りが機能する。 これは明らかに税修鳳洞舛魑擇椶垢里如
各サービスごとのセゥ絅螢謄と-
能との間の妥協は、あなたに任されている。
以下の表は横取りのオーバーヘッドを示す。
最初の表は様々なデータグラムサイズでの、UDP
ベースのサービスにおけるデータグラムあたりのオーバーヘッドである。
TCP
ベースのサービスについては、横取りによるバンド幅の減少を計測した。
計測の間は、ある量のデータをクライアントからサーバへ送った
(時間のオーバーヘッドは UDP ベースのサービスと同じはずだが、
連続するデータ転送の最初のパケットだけにかかる)。 データ量は表の
__
から得られる。すなわち、各 send(2)
システムコールはそれほど多くのデータを転送した。
バンド幅の減少は、秒あたりのバイト数と、
横取りが行われなかった場合からの割合で与えられる。 全ての計測は
SunOS 4.1 が走る SparcStation IPC で行われた。
データグラムサイズ(バイト) 遅延(ミリ秒)
-------------------------- ------------
64 1.19
256 1.51
1024 1.51
4096 3.58
送信バイト バンド幅減少
---------- ------------
10000x64 941 (1.2%)
10000x256 4,231 (1.8%)
10000x1024 319,300 (39.5%)
10000x4096 824,461 (62.1%)
例
#
# xinetd のサンプル設定ファイル
#
defaults
{
log_type = FILE /var/log/servicelog
log_on_success = PID
log_on_failure = HOST RECORD
only_from = 128.138.193.0 128.138.204.0
only_from = 128.138.252.1
instances = 10
disabled = rstatd
}
#
# 注意 1: protocol 属世鷲要ない
# 注意 2: instances 属世魯妊侫ルト値を上書
#
service login
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/etc/in.rlogind
instances = UNLIMITED
}
#
# 注意 1: instances 属世魯妊侫ルト値を上書
# 注意 2: log_on_success フラグは引た
#
service shell
{
socket_type = stream
wait = no
user = root
instances = UNLIMITED
server = /usr/etc/in.rshd
log_on_success += HOST RECORD
}
service ftp
{
socket_type = stream
wait = no
nice = 10
user = root
server = /usr/etc/in.ftpd
server_args = -l
instances = 4
log_on_success += DURATION HOST USERID
access_times = 2:00-9:00 12:00-24:00
}
# telnet セッションを、8 メガバイトのメモリーと子プロセスを
# 合計 20 CPU 秒に制限
service telnet
{
socket_type = stream
wait = no
nice = 10
user = root
server = /usr/etc/in.telnetd
rlimit_as = 8M
rlimit_cpu = 20
}
#
# このエントリとその次は、内部サービスを指定する。
# 違うソケットタイプの同じサービスなので、
# 各エントリを唯一に識別するために id 属世鰺僂い
#
service echo
{
id = echo-stream
type = INTERNAL
socket_type = stream
user = root
wait = no
}
service echo
{
id = echo-dgram
type = INTERNAL
socket_type = dgram
user = root
wait = no
}
service servers
{
type = INTERNAL UNLISTED
protocol = tcp
port = 9099
socket_type = stream
wait = no
}
#
# RPC サービスのサンプル
#
service rstatd
{
type = RPC
socket_type = dgram
protocol = udp
server = /usr/etc/rpc.rstatd
wait = yes
user = root
rpc_version = 2-4
env = LD_LIBRARY_PATH=/etc/securelib
}
#
# リストにないサービスのサンプル
#
service unlisted
{
type = UNLISTED
socket_type = stream
protocol = tcp
wait = no
server = /home/user/some_server
port = 20020
}
目
xinetd(1L),
xinetd.log(5)
Postel J., Echo Protocol, RFC 862, May 1983
Postel J., Discard Protocol, RFC 863, May 1983
Postel J., Character Generator Protocol, RFC 864, May 1983
Postel J., Daytime Protocol, RFC 867, May 1983
Postel J., Harrenstien K., Time Protocol, RFC 868, May 1983
M. Lottor, TCP Port Service Multiplexer (TCPMUX), RFC 1078, Nov 1988
StJohns M., Identification Protocol, RFC 1413, February 1993
グ
INTERCEPT フラグが使われなかった場合、 wait が yes で socket_type が
stream のとい蓮 リモートホストアドレスのアクセス制御は行われない。
INTERCEPT フラグが使われなかった場合、 wait が yes で socket_type が
dgram のサービスの
リモートホストアドレスによるアクセス制御は、最初のパケットにのみ行われる。
アクセス制御リストにないホストからのパケットをサーバは受け付けてしまう。
これは RPC サービスの場合に起い襦
環曲竸瑤 空白 を入れる方法がない。
wait が yes で socket_type が stream のとぁ
接続が受け付けられた場合のみ、ソケットがサーバへ渡される。
INTERCEPT
フラグは、内部サービスとマルチスレッドサービスではサポートされない。
14 June 2001 XINETD.CONF(5)