TCP/IP を使ったアプリケーションプロトコルのうちの一部には、現在の Linux の IP マスカレーディングでサポートされていないものもあります。 というのも、これらは暗黙のうちに特定のポート番号を使っていたり、 あるいはそれらのデータストリーム中に、 TCP/IP アドレスやポート番号を 暗号化して仕込んでいたりするからです。 後者のプロトコルを動かすためには特別なプロキシか IP MASQ モジュール をマスカレーディングのコードに仕込む必要があります。
デフォルトではいくつかの例外をのぞいて、Linux IP マスカレーディングでは外部から入ってくる サービスを取り扱うことができません。
もし、高いレベルでセキュリティを確保する必要がないなら、単純に IP とポートをフォワードなり リダイレクトすればすむでしょう。やり方はたくさんありますが、最も安定しているのは IPPORTFW を使ったやりかたでしょう。詳細は、 フォワーダ (ポート転送ツール) の章を参照してください。
もし、外部から入ってくる接続に何らかの認証を設定したいなら、TCP-wrapper か Xinetd を 設定して特定の IP アドレスからのみの接続を許すことができます。TIS Firewall Toolkit は ツールや情報を入手するのによい場所でしょう。
より詳細なセキュリティ情報については、 TrinityOS と IP マスカレードの情報源 から見つけることができます。
** Linux Masquerade Application list には、アプリケーションをLinux の IP マスカレーディングを 通じて動かすための多くの情報が掲載されています。このサイトは最近になって、Steve Srevemeyer によってデータベースバックエンドで動作するように書き改められました。素晴らしい情報源です！
一般的に、標準的な TCP 及び UDP を使ったアプリケーションであれば 動作します。 もし、ヒントやアドバイス等があるなら、詳細については IP マスカレードの情報源 を参照してください。
一般的なクライアント -
IP マスカレードがサポート済みの全てのプラットフォーム で動作する、ファイル探索クライアント (但し、全ての archie クライアント が動作するわけではない)。
FTP 接続については、ip_masq_ftp.o カーネルモジュールを使うことで、全てのサポート済みプラットフォーム上で 動作する。
【訳注: NAT 環境の一部 (marked forward 併用時) では、 ip_masq_ftp が 動作しないことが確認されています。 ftp クライアントをパッシブ (PASV) モードで起動すれば、 ip_masq_ftp.o が なくても大概の ftp サーバへの接続が可能です。 PASV モードの詳細については、例えば http://www.rtpro.yamaha.co.jp/RT/FAQ/TCPIP/ftp-passive-mode.html 辺りが参考になるかと思います。】
全てのサポート済みプラットフォームで動作する。
全てのサポート済みプラットフォームで動作する、Webサーフィン。
種々のサポート済みプラットフォームで動作する。 なお、 DCC は ip_masq_irc.o モジュールを導入すれば動作する。
【訳注: DCC については、 Linux 2.2.x カーネル の訳注を参照してください。】
全てのサポート済みプラットフォームで動作する、 USENET ニュースクライアント。
カーネルオプションの ICMP マスカレードを有効にすることで、 全てのプラットフォーム上で動作する。
すべてのプラットフォームで動作する、電子メールクライアント
全てのサポート済みプラットフォームで動作する、 安全な TELNET/FTP クライアント。
全てのサポート済みプラットフォームで動作する、 sendmail, qmail, PostFix 等のメールサーバ。
全てのサポート済みプラットフォームで動作する、 リモートセッション。
UNIX と Windows プラットフォームで提供されているが、 いくつかの亜種は動かないかもしれない。
Windows (あるいはこれ以外のサポート済みプラットフォーム) にて動作する、「バーチャル・リアリティ【訳注: 仮想現実】」技術による Web サーフィン。
全てのサポート済みプラットフォームで動作する。
マルチメディア 及び 通信クライアント -
- MS Netmeeting, Intel Internet Phone Beta 及びその他の H.323 アプリケーション - これらについては、 IP マスカレードを 経由した接続で動かすための方法が今のところ２つ存在します -
2.2.x カーネルで Microsoft Netmeeting v3.xを動かすための安定して動作するベータ版モジュールが IP マスカレードの情報源 または http://www.coritel.it/projects/sofia/nat.html にあります。これらはまた別なバージョン として、Netmeeting 2.x を 2.0.x カーネルで動かすためのモジュールが先の MASQ WWW サイトにありますが これは Netmeeting v3.x はサポートしていません。
商用ソフトによる別の解決方法としては、 Equivalence の PhonePatch による H.323 ゲートウェイがあります。
Windows で動作する クライアント・サーバ方式の 3D チャットプログラム
全てのサポート済みプラットフォームで動作しますが、 ip_masq_cuseeme を組み込むことが必要です。 詳細については CuSeeme の章を参照してください。
提供されたすべてのプラットフォームで動作。 Linux カーネルを IPPORTFW サポートを有効にしてコンパイルし、 ICQ 自身は 非 SOCKS プロキシの内部で動作するように設定しなければなりません。 設定の全詳細については ICQ の章を参照してください。
Windows で動作する ピア・ツー・ピアの音声による 通信を可能とするものです。 あなたの側から相手を呼び出せば通話ができますが、他の方があなたを呼び出すには 特定のポートに対する転送を設定しなければなりません。 詳細については フォワーダ (ポート転送ツール) の章を参照してください。
Windows で動作する、ネットワーク・ストリーム・オーディオ・プログラム
Windows で動作する、ピア・ツー・ピアタイプの文字と音声を 併用できる「ホワイトボード」通信プログラムです。 あなたの側から相手を呼び出せば通話ができますが、他の方があなたを呼び出すには 特定のポートに対する転送を設定しなければなりません。 詳細については フォワーダ (ポート転送ツール) の章を参照してください。
Windows で動作する、ネットワーク・ストリーミング・ オーディオ・プログラムです。 ip_masq_raudio UDP モジュールを使えば、高品位の再生が可能です。
Windows で動作するストリーミング・オーディオ・プログラムです。
Windows で動作します。 ip_masq_vdolive モジュールを使えば可能です。
【訳注: 原文は ip_masq_vdolive patch となっていますが、実際は モジュールです。】
Windows で動作する、クライアント・サーバ方式の 3D チャットプログラムです。
ネットワーク対応ゲームの類 - LooseUDP パッチについての詳細は LooseUDP の章を参照してください。
ゲームマシンに対して、 TCP ポート 116 と 118、 更に UDP ポート 6112 を IPPORTFW にて有効にすることで動作します。 詳細は フォワーダ (ポート転送ツール) の章を参照してください。 FSGS と Bnetd サーバはまだ NAT 環境でうまく動くように書き直されて いませんので、 IPPORTFW が必要となることに注意してください。
【訳注: FSGS (Free Standard Game Server) は、ブリザード社製の ゲームソフトをネットワーク対戦時に使用する battle.net を主催する サーバソフトウェアです。 詳細は、 Net-Games ...are you ready to play? 及び B-Ring を参照してください。 なお、訳者が確認した限りでは、 B-Ring web サイトのトップページに アクセスするには、 ipchains で tcp ポート 11000 番を REJECT に 設定しなければなりませんでした。 bnetd は、 Starcraft Battle.net server のエミュレータで、 GPL に従ったソースが自由に入手できるだけでなく、 Linux, Irix の バイナリも配布されています。 詳細は、 http://www.bnetd.org/ 等を参照してください。】
LooseUDP パッチ及び NAT 環境でもうまく動く .DLLs from Activision が必要です。
LooseUDP パッチを適用するか、または ゲームマシンに対してTCP ポート 116と118 、更に UDP ポート 6112 に 対して IPPORTFW を有効にすることが必要です。 詳細については フォワーダ (ポート転送ツール) を参照してください。
LooseUDP パッチまたは ゲームマシンに対して TCP ポート 116と118、更に UDP ポート 6112 に対して IPPORTFW を 有効にすることが必要です。 新しいバージョンでは TCP ポート 6112 と UDP ポート 6112 だけが 使われています。 詳細については、 フォワーダ (ポート転送ツール) の章を参照してください。
LooseUDP パッチまたは ゲームマシンに対して TCP ポート 116と118、更に UDP ポート 6112 に対して IPPORTFW を 有効にすることが必要です。 詳細については フォワーダ (ポート転送ツール) を参照してください。
そのままでも動作しますが、MASQ された linux ボックスより内側のネットワークに複数の Quake I/II/III プレイヤーが 居る場合は、 ip_masq_quake を使うことが必要となります。 また、このモジュールはデフォルトでは Quake I と QuakeWorld をサポートする ようにしかなっていません。 もし、Quake II 以降や、あるいはデフォルトではないサーバのポート番号を使う 必要があるなら、 rc.firewall-2.0.x や rc.firewall-2.2.x ルールセットのモジュールの組み込みの章を 参照してください。
LooseUDP パッチと 内部のゲームマシンに対する TCP と UDP ポート 6112 を IPPORTFW してやる必要があります。 詳細については、 フォワーダ (ポート転送ツール) を参照してください。
LooseUDP パッチを使えば動作します。
その他のクライアント -
Linuxで動作するネットワーク管理アカウント・パッケージ
DOSで動作する telnet, ftp, ping などを含むソフトウエアセット
MS-Windows で動作する、TCP/IP プロトコルを 通じて、遠隔地にある PC を操作するためのプログラム。 クライアントではなくホストとして動作させる場合は、特別なポート・ フォワーディング設定がなければ動作しません。 詳細については、 フォワーダ (ポート転送ツール) の章を参照してください。
NTP(ネットワーク経由の時刻制御プロトコル)をつかっている
サーバに接続できない
通話相手に接続できない
今のところ動作していない(相手の指定方法に不適切な前提を用いている)
この章では、カーネル 2.0.x のファイアウォール・ツールである IPFWADM を 使う際の、より詳細なガイドを示します。 IPCHAINS のルールセットについては後述します。
この例は、固定的にアドレスが与えられるような PPP 接続の背後にある ファイアウオールとマスカレードです (動的にアドレスが与えられる PPP の 使用法については、含まれてはいますが無効にしています)。 信頼できるインタフェースは 192.168.0.1 であり、 PPP インターフェースの アドレスは「悪い奴ら」から守るために変更されています。 出入りそれぞれのインタフェースはそれぞれ別にリストしていますが、これは ルーティングやマスカレードをわかりやすくする以外にIP スプーフィング 【訳注: 偽装】や、不正なルーティングを検出しやすくするためのものでも あります。 明確に許可されていないものは禁止です (実際には拒否されます)。 もし、あなたの IP マスカレード BOX が、この rc.firewall スクリプトを 入れたあとでまともに動かなくなったとしたら、 /var/log/messages あるいは /var/adm/messages にある SYSLOG ファイルに何かファイアウオール関係の エラーがないか確認して、設定が間違っていないかを確かめてください。
PPPやケーブルモデムなどを使った、IPFWADM によるもっと強固な IP マスカレードの実用的な例については TrinityOS - Section 10 や GreatCircle's Firewall WWW page を参照してください。
注意 - もし、 TCP/IP アドレスが PPP, ADSL, ケーブルモデムなどを 経由して ISP から動的に割り当てられる場合には、この強固なルールセットを 起動時に設定することはできません。 このような場合には、 IP アドレスが割り当てられる度にこの ファイアウオール・ルールセットを再度読み込ませるか、あるいは /ec/rc.d/rc.firewall ルールセットをもっとインテリジェントに作る必要が あります。 PPPユーザがこのルールセットを適用する場合には、以降に示す "Dynamic PPP IP fetch" と書かれた部分のコメントを注意深く適切に 外してください。 また、強固なルールセット及び動的に割り当てられる IP アドレスについての もっと詳しい解説は、 TrinityOS - 10章 にあります。
また、GUI ベースでファイアウオール設定を生成するようなツールが いくつか存在します。 詳細は、 よくある質問 (FAQ) の章を参照してください。
最後に、もし静的に割り当てられる IP アドレスを使っているなら、以下の例の "ppp_ip="your.static.PPP.address"" となっている部分をあなたの IP アドレスに書き換えてください。
【訳注: 一般的なプロバイダ経由の PPP 接続の場合、プロバイダ側から IP アドレスが動的に割り当てられますので、殆どの個人ユーザはこの行に IP アドレスを書き入れる必要はありません。】
----------------------------------------------------------------
#!/bin/sh
#
# /etc/rc.d/rc.firewall: IPFWADM を使ったやや強固なファイアウオール・ルールセット
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# テスト用 - しばらく待機してからすべてのファイアウオールルールをクリアする。
# 10分後にすべての設定を一旦解除する必要があるなら、以下のコメントを解除してください。
# (sleep 600; \
# ipfwadm -I -f; \
# ipfwadm -I -p accept; \
# ipfwadm -O -f; \
# ipfwadm -O -p accept; \
# ipfwadm -F -f; \
# ipfwadm -F -p accept; \
# ) &
# 必要なすべての IP マスカレードモジュールをロードする
#
# 注意 - 必要な IP マスカレードモジュールだけをロードします。すべてのIP マスカレード
# モジュールが以下に記述されていますが、ロードされないようにコメントとなって
# います。
# モジュールを最初にロードする時にまず必要
#
/sbin/depmod -a
# PORT 方式を使ってFTP ファイル転送における適切な IP マスカレードを提供します
#
/sbin/modprobe ip_masq_ftp
# UDP プロトコルを経由した、RealAudio のマスカレードを提供します。このモジュールがなくても
# RealAudio は TCP モードで動作しますが、音質は低下します。
#
#/sbin/modprobe ip_masq_raudio
# IRC DCC ファイル転送のマスカレードを提供します
#
#/sbin/modprobe ip_masq_irc
# 以下の指定によって Quake と QuakeWorld をデフォルトで提供します。
# このモジュールは Linux の マスカレードサーバから内側のユーザが
# 複数存在する場合のためのものです。
# もし、Quake I, II, あるいは III を使いたいならば、２番目の例を
# 使ってください。
#
# 注意 - もし、QUAKE モジュールのロード時にエラーが出た場合は、古いバグのあるカーネルが動いています。
# ----- その場合はより新しいカーネルに置き換えてください。
#
#Quake I / QuakeWorld (ports 26000 and 27000)
#/sbin/modprobe ip_masq_quake
#
#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960)
#/sbin/modprobe ip_masq_quake 26000,27000,27910,27960
# CuSeeme ビデオ会議ソフトウエアに対するマスカレードを提供
#
#/sbin/modprobe ip_masq_cuseeme
# VDO-Live ビデオ会議ソフトウエアに対するマスカレードを提供
#
#/sbin/modprobe ip_masq_vdolive
#非常に重要 - IP フォワーディングはデフォルトでは無効になっているので、有効にします。
#
# Redhat ユーザの場合は、/etc/sysconfig/network のオプション指定行を
#
# FORWARD_IPV4=false
# から
# FORWARD_IPV4=true
# に変更してください。
#
echo "1" > /proc/sys/net/ipv4/ip_forward
#非常に重要 - 2.2.x カーネルでは IP デフラグメンテーションのサポートはデフォルトでは無効です。
#
# コンパイル時の指定によるものですが、2.2.12 カーネル以降は変更されています。
#
echo "1" > /proc/sys/net/ipv4/ip_always_defrag
# 動的に割り当てられる IP アドレスを使用するユーザ向け -
#
# IP アドレスを SLIP, PPP, DHCP などから動的に取得する場合は、次のオプションを有効にしてください。
# このオプションは、IP マスカレードで動的 IP アドレスの操作を許可し、Dialdや同様なプログラムの
# 使用をより容易にするものです。
#
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr
# あなたの静的な IP アドレスを以下に指定します
#
# 動的に割り当てられる IP アドレスを使用するなら、新しい IP アドレスが割り当てられるたびに適用
# するように、ルールセットを書き換えなければなりません。そのためには、、以下のような一行のスクリプトを
# 有効にする必要があります。（スクリプト例内の一重引用符と二重引用符の違いは意味を持ちますので注意）
#
#
# DHCP を利用する場合 -
# ---------------------
# TCP/IP アドレスを DHCP から取得する場合は、 ppp セクションの下にある、
# "#" でコメントアウトされた部分を有効にし、"ppp0" とある部分を、
# インターネット接続用のインタフェースの名前に置き換えなければ
# なりません (例えば、 eth0 や eth1 等) 。
# DHCP は割り当てた IP アドレスを随時変更することに注意してください。
# この変更を正しく反映させるには、 DHCP リースが更新される度毎に、
# DHCP クライアントを再度実行してファイアウォールルールセットを反映
# させなければなりません。
#
# 注意 #1 - 旧バージョンの "pump" のような (新しいバージョンでは
# 問題点は修正されています) DHCP クライアントによっては、
# IP アドレスリース更新後にスクリプトを実行することが
# できないものがあります。
# その場合は、"dhcpcd" か "dhclient" に置き換えなければ
# なりません。
#
# 注意 #2 - 最近のバージョンの "dhcpcd" では、コマンド文法が変わって
# います。
#
# 旧バージョンでの指定方法は、次のようなものでした -
# dhcpcd -c /etc/rc.d/rc.firewall eth0
#
# 新しいバージョンでは次のように指定します -
# dhcpcd eth0 /etc/rc.d/rc.firewall
#
# 注意 #3 - Pump を使う場合、 /etc/pump.conf ファイルに次の記述を
# 追加してください -
#
# script /etc/rc.d/rc.firewall
#
#
# PPP を利用する場合 -
# --------------------
# お気づきではないかもしれませんが、PPP 接続が確立する度毎に、
# /etc/ppp/ip-up スクリプトが動作します。
# これを利用して、新しい IP アドレスの取得と強固なファイアウォール・
# ルールセットの再設定を行います。
#
# もし、/etc/ppp/ip-up がすでに存在しているなら、それを編集して"/etc/rc.d/rc.firewall"
# という記述を最後のあたりに追加するようにしてください。
#
# もし、/etc/ppp/ip-up スクリプトが存在しなかったなら、/etc/rc.d/rc.firewall スクリプト
# を実行するための次のようなリンクを作成する必要があります。
#
# ln -s /etc/rc.d/rc.firewall /etc/ppp/ip-up
#
# * 続いて、以下のコメントアウトされたシェルコマンドを必要に応じて有効にしてください *
#
#
#
# PPP 及び DHCP を利用する場合 -
# --------------------------------
# 次の行の "#" を削除して、その次の行の先頭に "#" を入れてください。
#
#ppp_ip="`/sbin/ifconfig ppp0 | grep 'inet addr' | awk '{print $2}' | sed -e
's/.*://'`"
#
ppp_ip="your.static.PPP.address"
# マスカレードのタイムアウト
#
# 2 時間= TCP セッション
# 10 秒 = TCP/IP の "FIN" パケットが受信されたあとのトラフィック
# 60 秒 = UDP トラフィック (マスカレードされた環境での ICQ ユーザは、
# ICQ クライアントの設定で、ファイアウォールタイムアウト値を
# 30秒に指定しなければなりません)
#
/sbin/ipfwadm -M -s 7200 10 60
#############################################################################
# 到着パケットについて、既存のルールを破棄し、初期ポリシーを
# 拒絶【訳注: reject】に設定。実際は、拒絶してログに記録する
# 最終ルールを用意するので、このポリシーは動作には無関係になる。
# 【訳注: ルールを reject にすると、ルールに合致したパケットを破棄して、
# "destination-unreachable" (目的地に到達しない) という ICMP パケットを
# 相手側 (送信元アドレスのマシン) に発信します。
# deny にすると、"destination-unreachable" パケットも出さずに、受信した
# パケットを単に破棄します。
#
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p reject
# ローカルマシン側からローカルインタフェースに入るパケットは、どこに
# 向かうものも有効とする。
#
/sbin/ipfwadm -I -a accept -V 192.168.0.1 -S 192.168.0.0/24 -D 0.0.0.0/0
# リモートインタフェース側から入って来る IP スプーフィング【訳注: IP 偽装】
# パケットや迷子パケットは、本来ならローカルマシンからであるべきものなので、
# 拒絶する。
#
/sbin/ipfwadm -I -a reject -V $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o
# リモートインターフェースから入る、宛先アドレスが PPP アドレスのパケットは、
# どの発信元アドレスからのものも有効とする。
# 【訳注: 以下のコマンドの前に、
# /sbin/ipfwadm -I -a deny -V $ppp_ip -S 0.0.0.0/0 -y -D $ppp_ip/32 -o
# があるか、或は以下のコマンドが
# /sbin/ipfwadm -I -a accept -V $ppp_ip -S 0.0.0.0/0 -k -D $ppp_ip/32
# となっている方がより好ましいと思います。】
#
/sbin/ipfwadm -I -a accept -V $ppp_ip -S 0.0.0.0/0 -D $ppp_ip/32
# ループバックインタフェースを有効とする
#
/sbin/ipfwadm -I -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
# 最終ルール。その他の到着パケットは拒絶され、ログに記録される。ポリシーには
# ログ記録のためのオプションがないため、これがその役割を代わりに果たすことに
# なる。
#
/sbin/ipfwadm -I -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#############################################################################
# 送出パケットについて、既存のルールを破棄し、初期ポリシーを
# 拒絶【訳注: reject】に設定。実際は、拒絶してログに記録する最終ルールを
# 用意するので、このポリシーは動作には無関係になる。
#
/sbin/ipfwadm -O -f
/sbin/ipfwadm -O -p reject
# ローカルインタフェースから出力される、ローカルネットへ向かうパケットは
# どこからのものも有効とする。
#
/sbin/ipfwadm -O -a accept -V 192.168.0.1 -S 0.0.0.0/0 -D 192.168.0.0/24
# リモートインタフェース上でローカルネットへ送出されるパケットは、
# 偽装ルーティングなので、拒絶する。
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -o
# リモートインタフェース上でローカルネットから送出されるパケットは、
# あり得ないマスカレーディングなので、拒絶する。
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o
# リモートインタフェース上でローカルネットから送出されるパケットは、
# あり得ないマスカレーディングなので、拒絶する。
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -o
# 【訳注: 上記ルールは2つ上のものと全く同じですので、明らかに間違いと
# 思われます。】
# リモートインタフェースからのそれ以外の送出パケットは有効
#
/sbin/ipfwadm -O -a accept -V $ppp_ip -S $ppp_ip/32 -D 0.0.0.0/0
# ループバックインタフェースを有効にする
#
/sbin/ipfwadm -O -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
# 最終ルール。その他の送出パケットは拒絶され、ログに記録される。
# ポリシーにはログ記録のためのオプションはないため、これがその役割を
# 代わりに果たすことになる。
#
/sbin/ipfwadm -O -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#############################################################################
# 転送パケットについて、既存のルールを破棄し、初期ポリシーを
# 否定【訳注: deny】に設定。実際は、否定してログに記録する最終ルールを
# 用意するので、このポリシーは動作には無関係になる。
#
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p deny
# ローカルインタフェース上のローカルネットからその他の宛先へのパケットを
# マスカレードする。
#
#
/sbin/ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/24 -D 0.0.0.0/0
#
# 最終ルール。その他の転送パケットは拒絶され、ログに記録される。
# ポリシーにはログ記録のためのオプションはないため、これがその役割を
# 代わりに果たすことになる。
#
/sbin/ipfwadm -F -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#ファイル終わり。
IPFWADM では、 -I, -O あるいは -F ルールによって、特定のサイトへの トラフィックを阻止することができます。 このルールは最初から最後へと順に適用されていきます。 また、 IPFWADM の "-a"オプションは、既存のルール群に対して新しい ルールを「追加」するものだということに注意してください。 これに留意すると、全体のルールを指定する前に、他の個別の制限が必要と なってきます。 たとえば、次のようなものです -
-I (到着)ルール -
-I (input) ルールを使う -
【訳注: 全てのインターフェースに到着するパケットが通過するルールです。 個別のインターフェースの指定は、 -V オプション又は -W オプションで 指定します。】
これはおそらくトラフィックをブロックする為の、最も手っ取り早くて 効率の良い方法ですが、マスカレードされたマシンに対してのみ阻止でき、 ファイアウォールマシン自身へのトラフィックは阻止できません。 もちろん、この組み合わせを許可したいということもあるでしょうが。
さて、 204.50.10.13 というアドレスへのトラフィックを阻止する場合 -
/etc/rc.d/rc.firewall ルールセットの中の
/etc/rc.d/rc.firewall のルールセットの中 -
... -I ルールのはじまり ... # ローカルインタフェース上で、 204.50.10.13 というマシンへのパケットを # 拒絶してログを取る。 # /sbin/ipfwadm -I -a reject -V 192.168.0.1 -S 192.168.0.0/24 -D 204.50.10.13/32 -o # ローカルインタフェース上で、あらゆるローカルマシンから発せられる # パケットは、どこへ向かうものも有効とする。 # /sbin/ipfwadm -I -a accept -V 192.168.0.1 -S 192.168.0.0/24 -D 0.0.0.0/0 ... -I ルールの終わり ...
-o (送出)ルール -
-O (output) ルールを使う -
【訳注: 全てのインターフェースから送出されるパケットが通過するルールです。 個別のインターフェースの指定は、 -V オプション又は -W オプションで 指定します。】
これはトラフィックをブロックするには遅い方法です。 何故ならば、パケットは破棄されるより以前にマスカレードを通ってしまう からです。 しかしながらこのルールでも、禁止しているサイトからのファイアウォール マシンに対するアクセスを阻止することができます。
... -O ルールの始まり ... # 204.50.10.13 に向けられたパケットを拒否してログを採取する # /sbin/ipfwadm -O -a reject -V $ppp_ip -S $ppp_ip/32 -D 204.50.10.13/32 -o # 上記以外のリモートインタフェース上でのあらゆるパケットの送出は # 有効にする。 # /sbin/ipfwadm -O -a accept -V $ppp_ip -S $ppp_ip/32 -D 0.0.0.0/0 ... -O ルールの終わり ...
-F (転送)ルールの使用 -
-F (forward) ルールを使う -
【訳注: 全てのインターフェース上で転送されるパケットが通過するルールです。 個別のインターフェースの指定は、 -V オプション又は -W オプションで 指定します。】
おそらく、トラフィックをブロックするには、 -I (input) ルールより 遅い方法ですが、マスカレードされたマシン (たとえば、ローカルエリア ネットワークのマシン) に対するトラフィックだけは阻止できます。 ファイアウォールマシンは禁止したいサイトから到達可能のままです。
... -F ルールの開始 ... # PPP インタフェース上での 204.50.10.13 に向けたパケットを拒否してログ採取する # /sbin/ipfwadm -F -a reject -W ppp0 -S 192.168.0.0/24 -D 204.50.10.13/32 -o # ローカルインターフェース側のローカルネットからのマスカレードを行う # /sbin/ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/24 -D 0.0.0.0/0 ... -F ルールの終わり ...
192.168.0.0/24 のマシンから 204.50.11.0 に向けてのアクセスを許す特別なルールは不要です。 なぜなら、それらは全体的なマスカレーディングのルールによってまかなわれているからです。
注意 - 前出の方法以外にも、各インタフェースを記述する方法はあります。 例えば、 "-V 192.168.255.1" という記述の代わりに、"-W eth0"とも 書けますし、 "-V $ppp_ip" という記述の代わりに "-W ppp0" とも 書けます。 "-V" を使う方法は IPCHAINS へ移行する場合には使えません。 しかし、 IPFWADM のユーザがどちらを選択するかは個人の自由であり、 明文化して述べるまでもないことです。
この章では、 2.2.x 系カーネルのファイアウォールツールである IPCHAINS の 詳細なガイドを記します。 IPFWADM については前出を参照してください。
この例は、固定的な IP アドレスを持つ PPP 接続の背後にある ファイアウォールとマスカレードです (動的にアドレスを与えられる PPP の 命令については含まれてはいますが有効にはしていません)。 信頼できるインタフェースは 192.168.0.1 であり、 PPP インターフェースの アドレスは「悪い奴ら」から守るために書き換えています。 出入りそれぞれのインタフェースは別々に列挙していますが、 これは ルーティングやマスカレードをわかりやすくする以外に IP スプーフィングや不正なルーティングを検出しやすくするためのものでも あります。 明確に許可されていないものは禁止です(実際には拒絶されます)。 もし、あなたの IP マスカレード BOX が、この rc.firewall スクリプトを 入れたあとでまともに動かなくなったとしたら、 /var/log/messages あるいは /var/adm/messages にある SYSLOG ファイルに何かファイアウオール関係の エラーがないか確認して、設定が間違っていないかを確かめてください。
PPPやケーブルモデムなどを使った、IPCHAINS によるもっと強固な IP マスカレードの実用的な例については TrinityOS - Section 10 や GreatCircle's Firewall WWW page を参照してください。
注意 #1 - 2.2.16以前の Linux カーネルには、 TCP 接続でルート権限 を奪取される危険性があり、更に 2.2.11 以前のものには IPCHAINS の フラグメンテーションに関するバグがあります。 このため、強固な IPCHAINS ルールセットを稼働させる際には、攻撃に対して 無防備です。 修正されたバージョンのカーネルを使ってください。
注意 #2 - もし、TCP/IPアドレスが PPP, ADSL, ケーブルモデムなどを 経由して ISP から動的に割り当てられる場合には、この強固なルールセットを 起動時に設定することはできません。 このような場合には、IP アドレスが割り当てられる度にこの ファイアウォール・ルールセットを再度読み込ませるか、あるいは /ec/rc.d/rc.firewall ルールセットをもっとインテリジェントに作る必要が あります。 PPP ユーザがこのルールセットを適用する場合には、後述する "Dynamic PPP IP fetch" と書かれた部分のコメントを注意深く適切に 外してください。 また、強固なルールセット及び動的に割り当てられる IP アドレスについての もっと詳しい解説は、 TrinityOS - Section 10 にあります。
また、GUI ベースでファイアウォールの設定を生成するようなツールが いくつか存在します。 詳細は よくある質問 (FAQ) の章を参照してください。
最後に、もし静的に割り当てられる IP アドレスを使っているなら、以下の例の "ppp_ip="your.static.PPP.address"" となっている部分をあなたの IP アドレスに書き換えてください。 ----------------------------------------------------------------
#!/bin/sh
#
# /etc/rc.d/rc.firewall - やや強固な IPCHAINS ファイアウオール・ルールセット
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# 必要なすべての IP マスカレードモジュールをロードする
#
# 注意 - 必要な IP マスカレードモジュールだけをロードします。すべての IP マスカレードモジュールが
# 以下に記述されていますが、ロードされないようにコメントとなっています。
# モジュールを最初にロードする時にまず必要
#
/sbin/depmod -a
# PORT 方式を使ってFTP ファイル転送における適切な IP マスカレードを提供します
#
/sbin/modprobe ip_masq_ftp
# UDP プロトコルを経由した、RealAudio のマスカレードを提供します。このモジュールがなくても
# RealAudio は TCP モードで動作しますが、音質は低下します。
#
/sbin/modprobe ip_masq_raudio
# IRC DCC ファイル転送のマスカレードを提供します
#
#/sbin/modprobe ip_masq_irc
# 以下の指定によって Quake と QuakeWorld をデフォルトで提供します。このモジュールは Linux
# の マスカレード・ボックスから内側の複数ユーザが存在する場合のためのものです。
# もし、Quake I, II, あるいは III を使いたいならば、２番目の例を使ってください。
#
# 注意 - もし、QUAKE モジュールのロード時にエラーが出た場合は、古いバグの
# ------ あるカーネルが動いています。
# その場合はより新しいカーネルに置き換えてください。
#
#Quake I / QuakeWorld (ports 26000 and 27000)
#/sbin/modprobe ip_masq_quake
#
#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960)
#/sbin/modprobe ip_masq_quake 26000,27000,27910,27960
# CuSeeme ビデオ会議ソフトウエアに対するマスカレードを提供
#
#/sbin/modprobe ip_masq_cuseeme
# VDO-Live ビデオ会議ソフトウエアに対するマスカレードを提供
#
#/sbin/modprobe ip_masq_vdolive
#非常に重要 - IP フォワーディングはデフォルトでは無効になっているので、有効にします。
#
# Redhat ユーザの場合は、/etc/sysconfig/network のオプション指定行を
#
# FORWARD_IPV4=false
# から
# FORWARD_IPV4=true
# に変更してください。
#
echo "1" > /proc/sys/net/ipv4/ip_forward
#非常に重要 - 2.2.x カーネルでは IP デフラグメンテーションのサポートはデフォルトでは無効です。
#
# コンパイル時の指定によるものですが、2.2.12 カーネル以降は変更されています。
# また、ディストリビューションによっては /proc テーブルから
# このオプションが除外されていることもありますので、その場合は
# /proc ディレクトリに存在しなければ気にしなくても構いません。
#
echo "1" > /proc/sys/net/ipv4/ip_always_defrag
# 動的に割り当てられる IP アドレスを使用するユーザ向け -
#
# IP アドレスを SLIP, PPP, DHCP などから動的に取得する場合は、次のオプションを有効にしてください。
# このオプションは、IP マスカレードで動的 IP アドレスの操作を許可し、Diald や同様なプログラムの
# 使用をより容易にするものです。
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr
# インターネットを必要とする、いくつかのプログラムに対する LooseUDP パッチを有効にする
#
# IP マスカレードを経由してインターネットゲームを動かそうとしていて、どうしてもそれが動かないという
# のなら、このオプションを有効にしてみてください(以下の "#" を削除します)。UDP ポートスキャンに
# 対する脆弱性の可能性があるので、このオプションはデフォルトで禁止されています。
#
#echo "1" > /proc/sys/net/ipv4/ip_masq_udp_dloose
# あなたの静的な IP アドレスを以下に指定します
#
# 動的に割り当てられる IP アドレスを使用するなら、新しい IP アドレスが割り当てられるたびに適用
# するように、ルールセットを書き換えなければなりません。そのためには、、以下のような一行のスクリプトを
# 有効にする必要があります。（スクリプト例内の一重引用符と二重引用符の違いは意味を持ちますので注意）
#
#
# DHCP を利用する場合 -
# -----------
# TCP/IP アドレスを DHCP から取得する場合は、ppp セクションの下にある"#"でコメントアウトされた
# 部分を有効にし、"ppp0" とある部分を、インターネット接続用のインタフェースの名前に置き換えなければ
# なりません(たとえば、eth0 や eth1 などに）。
# DHCP は割り当てた IP アドレスを随時変更することに注意してください。この変更を正しく反映させるには
# DHCP リースが更新されるたびに、DHCP クライアントを再度実行してファイアウオールルールセットを反映
# させなければなりません。
#
# 注意 1 - いくつかの DHCP クライアントは古いバージョンの "pump" で（新しいバージョン
# では問題点は修正されています）、それはリース更新後にスクリプトを実行することが
# できないものです。その場合は、"dhcpcd" か "dhclient" に置き換えなければ
# なりません。
#
# 注意 2 - "dhcpcd" は最近のバージョンでは、コマンド文法が変わっています。
#
# 旧バージョンでの指定方法は、次のようなものでした -
# dhcpcd -c /etc/rc.d/rc.firewall eth0
#
# 新しいバージョンでは次のように指定します -
# dhcpcd eth0 /etc/rc.d/rc.firewall
#
#
# 注意 3 - Pump を使う場合、/etc/pump.conf ファイルに次の記述を追加してください。
#
# script /etc/rc.d/rc.firewall
#
# PPP を利用する場合 -
# ----------
# お気づきではないかもしれませんが、PPP 接続が行われるたびに、/etc/ppp/ip-up スクリプトが
# 常に動作します。このことを利用して、新しい IP アドレスの取得と強固なファイアウオール・ルール
# セットの再設定を行います。
#
# もし、/etc/ppp/ip-up がすでに存在しているなら、それを編集して"/etc/rc.d/rc.firewall"
# という記述を最後のあたりに追加するようにしてください。
#
# もし、/etc/ppp/ip-up スクリプトが存在しなかったなら、/etc/rc.d/rc.firewall スクリプト
# を実行するための次のようなリンクを作成する必要があります。
#
# ln -s /etc/rc.d/rc.firewall /etc/ppp/ip-up
#
# * 続いて、以下のコメントアウトされたシェルコマンドを必要に応じて有効にしてください *
#
# PPP 及び DHCP を利用する場合 -
# -------------------
# 次の行の "#" を削除して、その次の行の先頭に "#" を入れてください。
#extip="`/sbin/ifconfig ppp0 | grep 'inet addr' | awk '{print $2}' | sed -e
's/.*://'`"
# 静的な IP アドレスで PPP を使う場合 -
#
extip="your.static.PPP.address"
# PPP と DHCP を使う場合は、必ずこの部分に正しい外部インタフェースの名前を指定します
extint="ppp0"
# 内部の IP アドレスの割り当てを指定します
intint="eth0"
intnet="192.168.0.0/24"
# マスカレードのタイムアウト
#
# 2 時間= TCP セッション
# 10 秒 = TCP/IP の "FIN" パケットが受信されたあとのトラフィック
# 60 秒 = UDP トラフィック (マスカレードされた環境での ICQ 利用者は ICQ 自体の設定の中で
# 30秒のファイアウオールタイムアウトを指定しなければなりません)
#
#
ipchains -M -S 7200 10 60
#############################################################################
# 到着パケットについて、既存のルールを破棄し、初期ポリシーを
# 拒絶【訳注: reject】に設定。実際は、拒絶してログに記録する
# 最終ルールを用意するので、このポリシーは動作には無関係になる。
# 【訳注: ルールを REJECT にすると、ルールに合致したパケットを破棄して、
# "destination-unreachable" (目的地に到達しない) という ICMP パケットを
# 相手側 (送信元アドレスのマシン) に発信します。
# DENY にすると、"destination-unreachable" パケットも出さずに、受信した
# パケットを単に破棄します。
#
ipchains -F input
ipchains -P input REJECT
# ローカルマシン側からローカルインタフェースに入るパケットは、どこに
# 向かうものも有効とする。
#
ipchains -A input -i $intint -s $intnet -d 0.0.0.0/0 -j ACCEPT
# リモートインタフェース側から入って来る IP スプーフィング【訳注: IP 偽装】
# パケットや迷子パケットは、本来ならローカルマシンからであるべきものなので、
# 拒絶する。
#
ipchains -A input -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT
# リモートインターフェースに入って来る、宛先アドレスが PPP アドレスの
# パケットは、どの発信元アドレスからのものも有効とする。
# 【訳注: 以下のコマンドの前に、
# ipchains -A input -i $extint -S 0/0 -d $extip/32 -p tcp -y -j DENY -l
# があるか、或は以下のコマンドが
# ipchains -A input -i $extint -S 0/0 -d $extip/32 -p tcp ! -y -j ACCEPT
# となっている方がより好ましいと思います。】
#
ipchains -A input -i $extint -s 0.0.0.0/0 -d $extip/32 -j ACCEPT
# ループバックインタフェースを有効とする
#
ipchains -A input -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
# 最終ルール。その他の到着パケットは拒絶され、ログに記録される。ポリシーには
# ログ記録のためのオプションがないため、これがその役割を代わりに果たすことに
# なる。
#
ipchains -A input -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
#############################################################################
# 送出パケットについて、既存のルールを破棄し、初期ポリシーを
# 拒絶【訳注: reject】に設定。実際は、拒絶してログに記録する最終ルールを
# 用意するので、このポリシーは動作には無関係になる。
#
ipchains -F output
ipchains -P output REJECT
# ローカルインタフェースから出力される、ローカルネットへ向かうパケットは
# どこからのものも有効とする。
#
ipchains -A output -i $intint -s 0.0.0.0/0 -d $intnet -j ACCEPT
# リモートインタフェース上でローカルネットへ送出されるパケットは、
# 偽装ルーティングなので、拒絶する。
#
ipchains -A output -i $extint -s 0.0.0.0/0 -d $intnet -l -j REJECT
# リモートインタフェース上でローカルネットから送出されるパケットは、
# あり得ないマスカレーディングなので、拒絶する。
#
ipchains -A output -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT
# リモートインタフェースからのそれ以外の送出パケットは有効
#
ipchains -A output -i $extint -s $extip/32 -d 0.0.0.0/0 -j ACCEPT
# ループバックインタフェースを有効とする。
#
ipchains -A output -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
# 最終ルール。その他の送出パケットは拒絶され、ログに記録される。
# ポリシーにはログ記録のためのオプションはないため、これがその役割を
# 代わりに果たすことになる。
#
ipchains -A output -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
#############################################################################
# 転送パケットについて、既存のルールを破棄し、初期ポリシーを
# 否定【訳注: deny】に設定。実際は、否定してログに記録する最終ルールを
# 用意するので、このポリシーは動作には無関係になる。
#
ipchains -F forward
ipchains -P forward DENY
# ローカルインタフェースでのローカルネットからその他の宛先へのパケットをマスカレードする
#
ipchains -A forward -i $extint -s $intnet -d 0.0.0.0/0 -j MASQ
#
# 最終ルール。その他の転送パケットは拒絶され、ログに記録される。
# ポリシーにはログ記録のためのオプションはないため、これがその役割を
# 代わりに果たすことになる。
#
ipchains -A forward -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
# ファイルの終わり
IPCHAINS では "input", "output", "forward" の各ルールにおいて、 特定のサイトへのトラフィックを阻止することができます。 このルールは上から下へと順に適用されていき、 "-A"オプションは IPCHAINS に 対して新しいルールを既存のルール群に対して「追加」するものだということに 注意してください。 これに留意すると、全体のルールを指定する前に他の個別の制限が必要と なってきます。 たとえば、次のようなものです -
"input" ルールを使う -
【訳注: 全てのインターフェースに到着するパケットが通過するルールです。 個別のインターフェースの指定は、 -i オプションに続けてインターフェース名 を指定します。】
これはおそらくトラフィックをブロックする為の、最も手っ取り早くて 効率の良い方法ですが、マスカレードされたマシンに対してのみ阻止でき、 ファイアウォールマシン自身へのトラフィックは阻止できません。 もちろん、この組み合わせを許可したいということもあるでしょうが。
さて、 204.50.10.13 というアドレスへのトラフィックを阻止する場合 -
/etc/rc.d/rc.firewall ルールセットの中の
... 入力 ルールのはじまり ... # ローカルインタフェース側の 204.50.10.13 というマシンへのパケットを拒否する # ipchains -A input -s 192.168.0.0/24 -d 204.50.10.13/32 -l -j REJECT # ローカルインタフェース側のどのローカルマシンのどこへ向かうパケットも有効とする # ipchains -A input -s 192.168.0.0/24 -d 0.0.0.0/0 -l -j ACCEPT ... 入力 ルールの終わり ...
"output" ルールを使う -
【訳注: 全てのインターフェースから送出されるパケットが通過するルールです。 個別のインターフェースの指定は、 -i オプションに続けてインターフェース名 を指定します。】
これはトラフィックをブロックするには遅い方法です。 何故ならば、パケットは破棄されるより以前にマスカレードを通らなければ ならないからです。 しかしながらこのルールでも、禁止しているサイトからのファイアウォール マシンに対するアクセスを阻止することができます。
... 出力ルールの始まり ... # 204.50.10.13 に向けられたパケットを拒否してログを採取する # ipchains -A output -s $ppp_ip/32 -d 204.50.10.13/32 -l -j REJECT # その他のリモートインタフェース側への送出は有効にする # ipchains -A output -s $ppp_ip/32 -d 0.0.0.0/0 -l -j ACCEPT ... 出力ルールの終わり ...
"forward" ルールを使う -
【訳注: 全てのインターフェース上で転送されるパケットが通過するルールです。 個別のインターフェースの指定は、 -i オプションに続けてインターフェース名 を指定します。】
おそらく、トラフィックをブロックするには "input" ルールより 遅い方法ですが、マスカレードされたマシン (例えばローカルエリア ネットワークのマシン) に対するトラフィックだけは阻止できます。 ファイアウォールマシンは禁止したいサイトから到達可能のままです。
... 転送ルールの開始 ... # PPP インタフェース上での 204.50.10.13 に向けたパケットを拒否してログ採取する # ipchains -A forward -i ppp0 -s 192.168.0.0/24 -d 204.50.10.13/32 -l -j REJECT # ローカルインターフェース側のローカルネットからのマスカレードを行う # ipchains -A forward -i ppp0 -s 192.168.0.0/24 -d 0.0.0.0/0 -j MASQ ... 転送ルールの終わり ...
192.168.0.0/24 のマシンから 204.50.11.0 に向けてのアクセスを許す特別なルールは不要です。 なぜなら、それらは全体的なマスカレーディングのルールによってまかなわれているからです。
注意 - IPFWADM と違って、IPCHAINS はインタフェース名を指定する方法が 一つしかありません。 IPCHAINS は "-i eth0" のように指定しますが、 IPFWADM では "-W"で インタフェース名を指定し、また "-V" でインタフェースのIPアドレスを指定します。
複数の内部ネットワークを持つ場合のマスカレードはかなり単純です。 まず確認することは、全ての (内部と外部両方の) ネットワークが正しく 動作していることです。 それから、両方の内部インタフェースについてインターネットと他の 内部インタフェースに対してマスカレードしてトラフィックを許可するように 設定します。
続いて、内部インタフェースについて、マスカレードを許可します。 この例では、全部で３つのインタフェースを使います - eth0 はインターネットへの接続を行う外部インタフェース、 eth1 は 192.168.0.0 のネットワーク、そして eth2 は 192.168.1.0 のネットワークです。 rc.firewall ルールセットでの、既存のマスカレードを許可している行の 後に、次のような内容を追加します -
# 内部のインタフェースの間での相互の通信を許可する /sbin/ipchains -A forward -i eth1 -d 192.168.0.0/24 /sbin/ipchains -A forward -i eth2 -d 192.168.1.0/24 # インターネットに対するマスカレードされた通信を許可する /sbin/ipchains -A forward -j MASQ -i eth0 -s 192.168.0.0/24 -d 0.0.0.0/0 /sbin/ipchains -A forward -j MASQ -i eth0 -s 192.168.1.0/24 -d 0.0.0.0/0
# 内部のインタフェースの間での相互の通信を許可する /sbin/ipfwadm -F -a accept -V 192.168.0.1 -D 192.168.1.0/24 /sbin/ipfwadm -F -a accept -V 192.168.1.1 -D 192.168.0.0/24 # インターネットに対するマスカレードされた通信を許可する /sbin/ipfwadm -F -a masq -W eth0 -S 192.168.0.0/24 -D 0.0.0.0/0 /sbin/ipfwadm -F -a masq -W eth0 -S 192.168.1.0/24 -D 0.0.0.0/0
eth0 が複数回指定されるのは、上の例では間違いではないことに注意してください。Linux カーネルは どのインタフェースが送出トラフィックに対して使われるのかを知る必要があるからです。上の例で eth0 は インターネットに対する接続のためのもので、それぞれの内部インタフェースについて指定されています。
IPPORTFW, IPAUTOFW, REDIR, UDPRED 等のプログラムは Linux の IP マスカレード で使用される汎用的な TCP と UDP ポートの転送のために使われるツールです。 これらのツールは一般的に FTP や Quake 用に作成された IP マスカレード用の モジュールの代わりに使うことができます。 これらポートフォワーダによって、インターネットから IP マスカレードサーバの 元で動作するプライベートアドレスに配置されたマシンに向かって送られる データ接続をリダイレクトすることができます。 転送機能は、 TELNET, WWW, SMTP, FTP (後述する特別なパッチが必要です), ICQ や、その他多くのものを含んでいます。
注意 - IP マスカレードを伴わない単純なポート転送をお求めでも、Linux の IP 転送ツールを使うには、カーネルと IPFWADM か IPCHAINS いずれかによる ルールセットが必要です。
ではなぜ異なる選択が幾つもあるのでしょうか? IPAUTOFW, REDIR それに UDPRED (これらへの URL は 2.0.x カーネルの必要条件 の章に記載してあります) などは、IP マスカレードを使うユーザにとって、 これらの機能を提供する最初のツール類でした。 その後、 Linux の IP マスカレード機能が成熟するにつれて、これらのツールは IPPORTFW という、もっと高度な解決方法にとって代わられるようになりました。 より新しいツールの登場によって、IPAUTOFW や REDIR という古いツールの ユーザは大いに落胆させられることになりました。 というのも、これらのツールは Linux カーネルに対して、自身の存在を適切に 通知することなく動いているので、負荷のかかるような状況では Linux サーバを クラッシュさせてしまうようなことすらあったからです。 MFW という最新の方法もあります。 MFW の最も大きな利点は、IPCHAINS ツールとの高い統合性です。 この方法では、IPCHAINS ルールセットは特定のパケットに対して印を付け、 適切な転送を行うためのルールを提供するために使われます。 今のところ、これについてはこの HOWTO では述べていません。
注意 #2 - 2.2.x 系カーネルにおける PORTFW では、ネットワーク内部の マシンから、インターネット上にあるネットワーク外部のマシンに対する アクセスに同じポート転送された IP アドレスを使うことができますが、 ネットワーク内部の他のマシンに対しては使えません。 もし、これがあなたの場合に該当するなら、ネットワーク内部のサーバへの リダイレクトを行うために REDIR ポート転送ツールを試してみてください。 後に述べる NetFilter ツールセットを使うのも良い考えだと思います。 なぜ内部/外部の転送が動かないのかの技術的説明については、2.2.x 系カーネルの PORTFW に関する章の最後にある Juan による注釈をご覧ください。
注意 #3 - 内部のマスカレードされた FTP サーバに対するトラフィックの 転送は PORTFW FTP として知られていますが、現在 2.0.x 系と 2.2.x 系のいずれのカーネルでも提供されるようになりました。 現状では主流の Linux カーネルではサポートされていませんが、カーネル にパッチを適用するか、外部 FTP プロキシサーバによって可能となります。 カーネルモジュールコードはまだ実験中で、PASSIVE 接続よりは ACTIVE FTP セッションによる接続のほうが良好な結果となる場合もあるようです。 興味深いことに、逆の振る舞いで動くケースもあるようです。 あなたの場合の結果がどうだったか私たちに教えてください。 この件について、以降の2.0.x 系 及び 2.2.x 系それぞれの章に別な パッチを用いた解決方法が詳細に述べられています。
2.0.x 系カーネルの IPPORTFW でも、 2.2.x 系カーネルの IPPORTFW サポートの ある IPMASQADM を使う場合でも、ネットワークセキュリティに関する考慮は それらのポートフォワーダ組み込みの前に必要です。 なぜなら、これらのツールは基本的には転送された TCP/UDP ポートについて、 ファイアウォール上にセキュリティ上の穴を作るためのものだからです。 これは、あなたの Linux マシン【訳注: ファイアウオール自身】に対して 被害を及ぼすことはありませんが、トラフィックが転送される先の内部マシンに 対して影響をおよぼします。 とはいえ、そんなに心配しないでください。 これは Steven Clarke (IPPORTFW の作者) が注意を促すために述べなければ ならなかった、以下のような場合です -
「ポート転送は、IPFWADM や IPCHAINS ルールの内部からのみ呼び出されるように作られており、
IP マスカレードは、IP フォワーディングの一種の拡張と見なされる。
しかしながら、 IPPORTFW は IPFWADM ルールセットの到着及び送出マスカレードルールに適合する
パケットだけについて、取り扱うようになっている。」
ここで述べているのは、強固なファイアウオールルールセットの必要性なのです。 強固なルールセットについては 強い IPFWADM のルールセット と 強い IPCHAINS のルールセット を参照してみてください。
ですから、 IPPORTFW による転送サポートを 2.2.x または 2.0.x 系の カーネルにインストールするためには、IPPORTFW を利用できるように Linux カーネルを再コンパイルしなければなりません。
まず最初に、最新の 2.2.x カーネル【訳注: 翻訳時点では 2.2.19 でした】を /usr/src/linuxディレクトリに展開します。 まだこの手順をやっていない方は、 カーネルのコンパイル の章の詳細を参照してください。 続いて、"ipmasqadm.c" プログラムを 2.2.x カーネルの必要条件 に述べている方法でダウンロードして入手し、 /usr/src/ ディレクトリに置きます。
引き続いて、 2.2.x 系カーネルを カーネルのコンパイル の章に示されているようにコンパイルします。 カーネルのオプションを設定する際に、IPPORTFW オプションには YES を 指定してください。 カーネルがコンパイルでき、再起動を確認したら、再びこの章に 戻って説明の続きを読んでください。
では、 IPMASQADM ツールのコンパイルとインストールを行います -
cd /usr/src
tar xzvf ipmasqadm-x.tgz
cd ipmasqadm-x
make
make install
さて、例としてここで、あなたのインターネット上の TCP/IP アドレスに対する 全ての WWW インターネットトラフィック (ポート80) を、内部のマスカレードされた マシンの IP アドレス、 192.168.0.10 に向ける場合を取り上げます。
PORTFW FTP - これについては先に説明したように、 FTP サーバに対する ネットワーク内部のマスカレードされたマシンへの転送は 2つの方法があります。 最初の方法はまだベータレベルですが、内部にあるマスカレードされた FTP サーバへ、 FTP 接続をポート転送する 2.2.x カーネル用の IP_MASQ_FTP モジュールを使うことです。 もう一つの方法は、 FTP プロキシプログラム ( 2.2.x カーネルの必要条件 の章に URL を記載してあります) です。 FTP カーネルモジュールについては、 IP_MASQ_FTP モジュールをアンロードしたり 再ロードすることなしに、 PORTFW の FTP ポートを動的に追加することが できますが、これはその時点で存在している他の FTP 転送を無効にしてしまいます。 この新しいコードの詳細については、 IP マスカレードの web サイト http://ipmasq.cjb.net/ をご覧ください。 また、 2.0.x 系カーネルの章に、ポート転送された FTP 接続に関する例と 若干の情報があります。
注意 - ポート転送をポート 80 で有効にしたなら、それ以降は IP マスカレードサーバでそのポートを使うことはできなくなります。 つまり、マスカレードサーバ上ですでに Web サーバを動かしていた場合は、 ポート転送によって、すべてのインターネットからの Web アクセスは IP マスカレードサーバのページではなく、内部の Web サーバに対して 振り向けられてしまうのです。
いずれにせよ、ポート転送を有効にするには、 /etc/rc.d/rc.firewall のルールセットを書き換えなければ いけません。以下のような行を追加しますが、"$extip" の部分はあなたのインターネットに公開する IP アドレス を指定するように書き換えてください。
注意 - もし、PPP, ADSL, ケーブルモデムなどにより ISP から 動的な TCP/IP アドレスを割り当てられている場合は、 /etc/rc.d/rc.firewall ルールセットをもっとインテリジェントに作成する必要があります。 そのための情報は、前出の 強い IPCHAINS のルールセット の章か TrinityOS - Section 10 に強固なルールセットを動的な IP アドレス環境で 作成する詳細が述べられています。 ここではヒントだけ - PPPの 場合は /etc/PPP/ip-up です。
/etc/rc.d/rc.firewall
--
#echo "IPPORTFW によるリダイレクションを外部 LAN に適用.."
#
/usr/sbin/ipmasqadm portfw -f
/usr/sbin/ipmasqadm portfw -a -P tcp -L $extip 80 -R 192.168.0.10 80
--
これだけです！ /etc/rc.d/rc.firewall ルールセットを再度実行してテストしてみてください。
もし、"ipchains: setsockopt failed: Protocol not available" という エラーメッセージを受け取ってしまったら、あなたはまだ新しいカーネルを 動作できていません。 新しいカーネルを正しく組み込んだことを確認し、 LILO を再度実行し、 再起動してみてください。 もし、新しいカーネルが動いているのが確実ならば、 "ls /proc/net/ip_masq" コマンドを実行して、 "portfw" ファイルが存在しているか確認してください。 これが無いなら、カーネルの構築でなにかエラーが出ているはずですので、 そこからもう一度やり直してください。
なぜ PORTFW が外部と内部のインタフェースの双方でトラフィックをリダイレクト できないのか理解したい方のために、 Juanjo 【訳注: IP_MASQ_FTP モジュールの 作者】からのメールをここでお見せします。 彼はもっとうまく説明してくれています -
From Juanjo Ciarlante
--
>次のような場合 -
>
>ipmasqadm portfw -a -P tcp -L 1.2.3.4 80 -R 192.168.2.3 80
>
>外部からの接続は問題なく動くけれど、内部から同じ 1.2.3.4 に対する
>接続要求は失敗します。
>ローカルネットの 192.168.2.0 から www.periapt.com へのアクセスを、
>プロキシなしで許可するようなチェインを用意することはできますか?
実際のところできないね。
大概、僕は ipmasqadm ルールを外部の為に設定し、*そして*
ポートリダイレクタを内部のために設定しているんだ。
リダイレクションの前に ipmasqadm のフックがあるから、このフックは外部
からの接続の発生を捉える。
_だけど_ そうでない場合は、何もしないで素通ししてしまう(つまり、適当な
ルールの適用が行われる)。
実際、"概念的な"問題は、真のクライアント (ピア) の IP パケットの
到達先が、 (ありがたいことにマスカレードによって) 目的のサーバとして
同じネットワークに存在していることに起因する。
失敗する"ローカルなマスカレード"というのは次のような場合 -
クライアント: 192.168.2.100
マスカレード: 192.168.2.1
サーバ: 192.168.2.10
1)クライアントからサーバへのパケット
a) クライアント: 192.168.2.100:1025 -> 192.168.2.1:80 [SYN]
b) (マスカレード): 192.168.2.100:1025 -> 192.168.2.10:80 [SYN]
(そして、 192.168.2.1:61000 と 192.168.2.100:1025 が
関連づけられて記憶される)
c) サーバ: マスカレードされたパケットを受ける (1b)
2)サーバからクライアントへのパケット
a) サーバ: 192.168.2.10:80 -> 192.168.2.100:1025 [SYN,ACK]
b) クライアント: 192.168.2.100:1025 -> 192.168.2.10:80 [RST]
さあ、 (1a) と (2a) を比べてごらん。
見ての通り、同じネットワークに存在するもの同士だと、サーバは
マスカレードを通らずに直接クライアントに向けて応答するんだ。
(サーバがマスカレードにパケット操作を元に戻させるようなことはしない)
だから、クライアントは接続をリセットしてしまう。
これが役に立つとうれしいよ。
よろしく
Juanjo
最初に、/usr/src/linux ディレクトリに最新の 2.0.x 系カーネルがあることを 確認してください。 まだだった場合の詳細については、 カーネルのコンパイル の章を参照してください。 続いて、 "ipportfw.c" プログラムと "subs-patch-x.gz" カーネルパッチを 2.0.x カーネルの必要条件 の章を参照して入手し、 /usr/src/ ディレクトリに 置きます。
注意 - "subs-patch-x.gz" の "x" はサイトで入手できる最新のバージョン番号に 読み替えてください。
次に、内部サーバへの FTP トラフィックのポート転送を考えているなら、 2.0.x カーネルの必要条件 の章にある、新しい IP_MASQ_FTP モジュールのパッチを入手してください。 これは2.2.x 系カーネルとは違うパッチで、動的に FTP ポートを割り当てる 機能などは提供されていないことにご注意ください。
それから、IPPORTFW パッチ(subs-patch-x.gz)を Linux ディレクトリにコピーします。
cp /usr/src/subs-patch-1.37.gz /usr/src/linux
つづいて、IPPORTFW カーネルオプションを作るためにパッチを適用します。
cd /usr/src/linux
zcat subs-patch-1.3x.gz | patch -p1
よろしい。 カーネルのコンパイル の章に示されているように、カーネルをコンパイルしましょう。 カーネルの構成時に有効になった IPPORTFW オプションをここでは YES に 設定してください。 コンパイルが完了し、再起動したなら、この章の説明を続けます。
新しくコンパイルされたカーネルを使って、実際の"IPPORTFW" プログラムをインストールします。
cd /usr/src
gcc ipportfw.c -o ipportfw
mv ipportfw /usr/local/sbin
さて、この例ではあなたのインターネット上の TCP/IP アドレスに対する 全ての WWW インターネットトラフィック (ポート80) を内部のマスカレードされた マシンの IP アドレス、 192.168.0.10 に向ける場合を取り上げます。
注意 - ポート 80 でポート転送を有効にすると、 Linux IP マスカレードサーバからはそのポートは使えなくなります。 つまり、もし予めマスカレードサーバ上で WWW サーバが動作していたとして、 そのサーバで内部のマスカレードされたコンピュータへのポート 80 での転送を 行ったならば、全てのインターネット上のユーザはマスカレードサーバ上の ページではなく、-内部の- WWW サーバ上のページを見ることになります。 これを回避するための唯一の方法は、たとえば 8080 のような別なポートで 転送をかけることです。 これで動作はできますが、内部のマスカレードされた WWW サーバに対する アクセスに対して、全てのインターネット上のユーザは :8080 という文字を URL に追加しなければなりません。
いずれにせよ、ポート転送を有効にするには、/etc/rc.d/rc.firewall ルールセットを 編集しなければなりません。そして、次のような行を追加し "$extip" という文字列を あなたのインターネット上の IP アドレスに置き換えなければなりません。
注意 - もし、 PPP や ADSL や ケーブルモデムなどのような形で ISP から動的な IP アドレス割り当てを受けているならば、 /etc/rc.d/rc.firewall ルールセットはもっと知的に動作するよう作成しなければなりません。 そのためには、既出の 強い IPCHAINS のルールセット の章か、 TrinityOS - Section 10 を参照して、強固なルールと動的な IP アドレス割り当てに関する情報を 参照してください。 ここではちょっとしたヒントだけを - PPP ユーザでは /etc/ppp/ip-up です。
/etc/rc.d/rc.firewall
--
#echo "IPPORTFW によるリダイレクションを外部 LAN について有効に .."
#
/usr/local/sbin/ipportfw -C
/usr/local/sbin/ipportfw -A -t$extip/80 -R 192.168.0.10/80
# ポート 20 に対するポート転送は動作中の接続に対しては不要です。
# 内部にある FTP サーバはポート 20 番での接続を開始して、既存のやり方での
# マスカレードされたコンピュータを取り扱うことができます。
--
これだけです！ /etc/rc.d/rc.firewall ルールセットを再度動かしてテストしましょう！
もしも、"ipfwadm: setsockopt failed: Protocol not available" というエラーメッセージが 出てしまった場合は、あなたはまだ新しいカーネルを動作させていないことになります。 新しいカーネルファイルを適切な場所に移動させて、LILO コマンドを再実行し、システムを 再起動させてください。
FTP サーバに対するポート転送 -
もし内部ネットワークに存在する FTP サーバへのポート転送を考えているなら、事態は より複雑になります。というのも、標準的な IP_MASQ_FTP カーネルモジュールは このような動作のためには作られていないにも関らず、何人かのユーザからは問題なく動いて いるという報告があるからです。私の知るかぎり、パッチをあてない状態では 30 分を越える 転送時間を要する場合においては、問題がないと言っているユーザでも転送は失敗すると 思います。どちらにせよ、既存の ip_masq_ftp モジュールを使った次のようなポート転送の 方法を試みて、あなたの環境で動くかどうか確かめて見ることをお薦めします。 もしそれが動かないならば、改良された ip_masq_ftp モジュールを試しましょう。
Fred Viles はポート転送が動作するように改良した IP_MASQ_FTP モジュールを、それら を必要とするユーザのために作成しています。このモジュールが使えるかどうかを調べたい なら、次のアーカイブをダウンロードしてみてください。Fred の作成した文書では 詳細に述べられています。また、このパッチはあくまで実験的なものなのでそのつもりで 扱ってください。さらに、2.0 系カーネルから 2.2 系カーネルまでのいくつかのパッチしか 存在していません。
さて、2.0 系カーネル用のパッチを動かすためには、次の事項が必要です -
この作業を終えてから、/etc/rc.d/rc.firewall ルールセットを編集して、次のような行を追加 しますが、"$extip"の部分は外部 IP アドレスとなるように注意してください。
この例では、先程のようにインターネットからあなたの TCP/IP アドレスに対する FTP (ポート番号 21) の接続要求は、内部にある IP アドレス 192.168.0.10 にあるマスカレードされたコンピュータに 転送されます。
注意 - 一旦ポート 21 でポート転送を有効にすると、このポートは IP マスカレードサーバからは使えなくなります。 つまり、 FTP サーバがあらかじめマスカレードサーバで動作していたとしたら、 ポート転送はすべてのインターネットからの接続に対しては、 マスカレードサーバではなく内部の FTP サーバへの接続を 提供することになります。
/etc/rc.d/rc.firewall
--
#echo "IPPORTFW によるリダイレクションを外部 LAN について有効に .."
#
/usr/local/sbin/ipportfw -C
/usr/local/sbin/ipportfw -A -t$extip/21 -R 192.168.0.10/21
#注意 - もしあなたが複数のローカルなポート番号を使っていてポート転送を
# 複数の FTP サーバ(たとえば 21,2121,2112など)に対して行いたいなら
# ip_masq_ftp モジュールを複数のポートに対してリスンするように設定
# しなければなりません。そのためには、たとえば、
# /etc/rc.d/rc.firewall の内容を
#
# /sbin/modprobe ip_masq_ftp ports=21,2121,2112
#
# のようにし、これが有効となるように /etc/rc.d/rc.firewall スクリプトを
# 再度実行しなければなりません。
# ポート 20 に対するポート転送は動作中の接続に対してはおそらく不要です。
# 内部にある FTP サーバはポート 20 番での接続を開始して、既存のやり方での
# マスカレードされたコンピュータを取り扱うことができます。
--
これだけです! /etc/rc.d/rc.firewall ルールセットを再度動かしてテストしましょう!
もしも、"ipfwadm: setsockopt failed: Protocol not available" というエラーメッセージが 出てしまった場合は、あなたはまだ新しいカーネルを動作させていないことになります。 新しいカーネルファイルを適切な場所に移動させて、LILO コマンドを再実行し、システムを 再起動させてください。新しいカーネルを動かしているつもりなのに、このエラーが出た場合は、 "ls /proc/net" を実行して "ip_portfw" ファイルが存在するかどうか確認してください。 これが存在しない場合は、カーネルの構成時にエラーが出ているはずです。もう一度やり直しましょう。
Linux での IP マスカレードでは "ip_masq_cuseeme" カーネルモジュールを 使うことによって CuSeeme をサポートしています。 このカーネルモジュールは、 /etc/rc.d/rc.firewall スクリプトで 読みこまれなければなりません。 "ip_masq_cuseeme" モジュールが読み込まれると、リモートのリフレクタ 【訳注: CU-SeeMeのサーバのこと】やユーザとの間で接続を行うことができます。
注意 - CuSeeme を使用する場合は、IPAUTOFW より IPPORTFW ツールを使いましょう。
もし CuSeeMe に対してもう少し明確な情報が必要ならば、 Michael Owings's CuSeeMe page にある Mini-HOWTO か IP マスカレードの情報源 にミラーされた内容を見てください。
Linux のマスカレードサーバの背後で ICQ を動かすようにするための方法は二つあります。 一つの方法は、ICQ のマスカレードモジュールを使うことで、もう一つは IPPORTFW を 使うことです。
ICQ マスカレードモジュールにはいくつかの利点があります。このモジュールは複数 の ICQ ユーザに対しても単純な設定で動作します。また ICQ クライアントプログラムに 対してなんら特別な変更を加える必要がありません。最近では このモジュールのバージョン 2.2 系カーネルへのアップデートではファイル転送やリアルタイムチャットもサポートする ようになりました。 しかし、2.0 系カーネルではファイル転送やリアルタイムチャットは完全にはサポート されていません。ともかく、2.2 系カーネルの上で IP マスカレードを行って ICQ を動かす ようにしたほうがいいだろうとは思います。
IPPORTFW を設定する場合、Linux と ICQ クライアントに対して ICQ メッセージング、 URL、チャット、ファイル転送などなどを変更しなければなりません。
もし、 Andrew Deryabin の djsf@usa.net 2.2 系カーネル向け ICQ IP マスカレードモジュールに 関心があるなら、 2.2.x カーネルの必要条件 の章に詳しい説明があります。
マスカレードサーバの内部で ICQ を動かすために古典的な方法を取りたい場合は、 次のような方法で行います -
下記は、IPFWADM による 2.0 系カーネルのための例です。
ここで二つの例をあげておきました。どちらも問題なく動作します。
例その 1
--
/usr/local/sbin/ipportfw -A -t10.1.2.3/2000 -R 192.168.0.10/2000
/usr/local/sbin/ipportfw -A -t10.1.2.3/2001 -R 192.168.0.10/2001
/usr/local/sbin/ipportfw -A -t10.1.2.3/2002 -R 192.168.0.10/2002
/usr/local/sbin/ipportfw -A -t10.1.2.3/2003 -R 192.168.0.10/2003
/usr/local/sbin/ipportfw -A -t10.1.2.3/2004 -R 192.168.0.10/2004
/usr/local/sbin/ipportfw -A -t10.1.2.3/2005 -R 192.168.0.10/2005
/usr/local/sbin/ipportfw -A -t10.1.2.3/2006 -R 192.168.0.10/2006
/usr/local/sbin/ipportfw -A -t10.1.2.3/2007 -R 192.168.0.10/2007
/usr/local/sbin/ipportfw -A -t10.1.2.3/2008 -R 192.168.0.10/2008
/usr/local/sbin/ipportfw -A -t10.1.2.3/2009 -R 192.168.0.10/2009
/usr/local/sbin/ipportfw -A -t10.1.2.3/2010 -R 192.168.0.10/2010
/usr/local/sbin/ipportfw -A -t10.1.2.3/2011 -R 192.168.0.10/2011
/usr/local/sbin/ipportfw -A -t10.1.2.3/2012 -R 192.168.0.10/2012
/usr/local/sbin/ipportfw -A -t10.1.2.3/2013 -R 192.168.0.10/2013
/usr/local/sbin/ipportfw -A -t10.1.2.3/2014 -R 192.168.0.10/2014
/usr/local/sbin/ipportfw -A -t10.1.2.3/2015 -R 192.168.0.10/2015
/usr/local/sbin/ipportfw -A -t10.1.2.3/2016 -R 192.168.0.10/2016
/usr/local/sbin/ipportfw -A -t10.1.2.3/2017 -R 192.168.0.10/2017
/usr/local/sbin/ipportfw -A -t10.1.2.3/2018 -R 192.168.0.10/2018
/usr/local/sbin/ipportfw -A -t10.1.2.3/2019 -R 192.168.0.10/2019
/usr/local/sbin/ipportfw -A -t10.1.2.3/2020 -R 192.168.0.10/2020
--
例その 2
--
port=2000
while [ $port -le 2020 ]
do
/usr/local/sbin/ipportfw -A t10.1.2.3/$port -R 192.168.0.10/$port
port=$((port+1))
done
--
IPCHAINS を使った 2.2 系カーネルのための例を次に示します -
ここで二つの例をあげておきました。どちらも問題なく動作します -
例その 1
--
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2000 -R 192.168.0.10 2000
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2001 -R 192.168.0.10 2001
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2002 -R 192.168.0.10 2002
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2003 -R 192.168.0.10 2003
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2004 -R 192.168.0.10 2004
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2005 -R 192.168.0.10 2005
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2006 -R 192.168.0.10 2006
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2007 -R 192.168.0.10 2007
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2008 -R 192.168.0.10 2008
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2009 -R 192.168.0.10 2009
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2010 -R 192.168.0.10 2010
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2011 -R 192.168.0.10 2011
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2012 -R 192.168.0.10 2012
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2013 -R 192.168.0.10 2013
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2014 -R 192.168.0.10 2014
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2015 -R 192.168.0.10 2015
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2016 -R 192.168.0.10 2016
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2017 -R 192.168.0.10 2017
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2018 -R 192.168.0.10 2018
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2019 -R 192.168.0.10 2019
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2020 -R 192.168.0.10 2020
--
例その 2
--
port=2000
while [ $port -le 2020 ]
do
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 $port -R
192.168.0.10 $port
port=$((port+1))
done
--
新しい rc.firewall が準備できたら、"/etc/rc.d/rc.firewall" とタイプして 設定が問題ないことを確認するためにルールセットの再読み込みを行います。 もし何かエラーが出た場合、IPPORTFW サポートのあるカーネルを動作させていないか、 rc.firewall ファイルになにかタイプミスがあることでしょう。
ICQ の [プリファレンス] - [接続] 設定で "LANから使う" と "ファイアウォールまたはプロキシを経由して使う" を設定してください。 それから、 "ファイアウォール設定" をクリックして、"SOCKS プロキシを 使わない" を設定します。 以前は "ファイアウォールタイムアウト" を "30" にすることを推奨して いましたが、多くの利用者はこれにより ICQ の信頼性が下がることに 気づいている点に注意してください。 ICQ は規定のタイムアウト設定 (この ICQ オプションを有効にしない状態) が 最も信頼性が高いので、マスカレードサーバでのタイムアウトを160秒にします。 このタイムアウト設定を変更する方法については rc.firewall-2.0.x と rc.firewall-2.2.x ルールセットを参照してください。 それから、 "次へ" をクリックして "以下の TCP 監視ポートを使う" の 項目では、 "2000" から "2020" までを指定してください。そして"完了"を クリックして終わりです。
ICQ クライアントは変更を有効にするために ICQ の再起動を促してきます。実は、私の 場合は変更を正しく反映させて動かすために Windows9x 自体を再起動させなければなり ませんでしたが、ある人はそんなことをする必要はないとも言っています。もしだめなら両方 試してみてください。
LooseUDP パッチは NAT との親和性があり、通常 UDP を用いるゲームを Linux IP マスカレードサーバの背後で問題なく動作させるためのものです。 今のところ、LooseUDP はバージョン 2.0.36 以上のカーネルに対しては パッチとして提供され、2.2.3 以上のカーネルには組み込まれていますが、 2.2.16 以上のカーネルではデフォルトで禁止状態になっています。
LooseUDP を2.0.x 系カーネルで動作させるには次の手順に従います -
LooseUDP パッチを /usr/src/linux ディレクトリに置き、次のようにタイプします。
圧縮されたパッチファイルの場合 - zcat loose-udp-2.0.36.patch.gz | patch -p1
圧縮されていないパッチファイルの場合 - cat loose-udp-2.0.36.patch | patch
-p1
お使いの patch プログラムのバージョンにもよりますが、次のようなテキストを 見ることになるでしょう -
patching file `CREDITS'
patching file `Documentation/Configure.help'
patching file `include/net/ip_masq.h'
patching file `net/ipv4/Config.in'
patching file `net/ipv4/ip_masq.c'
もし、"Hunk FAILED" がパッチ過程の各々でそれぞれ一度だけ表示されているなら、それは 警告ではありません。古いパッチファイルが当たっているのだと思われますが、この状態であれば 動作します。全く失敗に終わってしまった場合は、IPPORTFW パッチがカーネルに適用されている かどうか、まず確認してみてください。
このパッチが組み込まれると、 カーネルのコンパイル の章に示されている通りに "IP: loose UDP port managing (EXPERIMENTAL) (CONFIG_IP_MASQ_LOOSE_UDP) [Y/n/?]" オプション に対して "Y" と答えて構成してください。
2.2 系カーネルで LooseUDP が動くようにするためには、次のような手順を実施します -
echo "0" > /proc/sys/net/ipv4/ip_masq_udp_dloose
という行にある "0" を "1" に変更して、 rc.firewall ルールセットを再実行します。
この実例は、
rc.firewall-2.2.x
と
stronger-rc.firewall-2.2.x
にあります。新しく LooseUDP が有効となったカーネルを動かすと、殆どの NAT との 親和性のあるゲームが問題なく動くようになります。 いくつかのページで、 BattleZone などといったゲームに NAT 親和性を 持たせるパッチを提供する web ページもあります。 詳細は Game-Clients の章を参照してください。