ポート番号に関して何かしら仮定をしている、あるいはアドレスやポートに 関するデータをデータストリーム中にエンコードしているなどの理由で、 マスカレードでは動作しないプロトコルがいくつかあります。 後者を動作させるためには、マスカレードのコードにそのプロトコル特有の プロキシを組み込む必要があります。
マスカレードは、外部から到来するサービスを受け付けることができません。 これを可能にするためにはいくつか方法がありますが、それらはマスカレード とはまったく独立したもので、実際には標準的なファイヤウォール手法の一部 です。
もし、高レベルのセキュリティが必要ないならば、単純にポートをリダイレクト することができます。これを行なうにはいくつかの方法があります。私は修正した redir プログラムを使っています (これは sunsite やそのミラーサイトから、 近日中に取得可能になると思います)。 外部からのコネクションに何らかの認証を行ないたい場合には、 TCP ラッパや Xinetd を redir (0.7 あるいはそれ以上) と組み合わせて使う ことによって、指定した IP アドレスだけを通過させることができますし、 他のツールを使うこともできます。ツールや情報を入手するには、 TIS Firewall Toolkit を探してみるといいでしょう。
さらに詳細な情報は、 IP Masquerade Resource を参照してください。
サービスのフォワーディングに関するセクションが、近日中に追加される予定です。
** 以下のリストは、もはや保守されていません。 Linux IP マスカレードを通して動作するアプリケーションに関しては、 このページ を参照して ください。詳細は IP Masquerade Resource を参照してください。**
一般的に言って、TCP や UDP を使うアプリケーションは動作するはずです。 IP マスカレードとアプリケーションに関する提案、ヒント、質問などがあれば、 Lee Nevo 氏によるこのページ applications that work thru Linux IP masquerading を訪ねてみて ください。
一般的なクライアント
サポートされているプラットフォームすべて、ウェブのサーフィン
サポートされているプラットフォームすべて、 電子メールクライアント
サポートされているプラットフォームすべて、リモートセッション
サポートされているプラットフォームすべて、 ip_masq_ftp.o モジュールが必要 (サイトによっては特定のクライアントでアクセスできないことがあります。 例えば、ws_ftp32 ではダメだが netscape だとうまくいくサイトもあります)
サポートされているプラットフォームすべて、ファイル検索 クライアント(すべての archie クライアントがサポートされているわけでは ありません)
サポートされているプラットフォームすべて、USENET ニュースクライアント
Windows上の(サポートされているプラットフォームすべてで 動作する可能性があります)バーチャルリアリティサーフィン
主に UNIX ベースのプラットフォーム、いくつかの 変種では動作しない
すべてのプラットフォーム、ICMP パッチが必要
サポートされているプラット フォームすべて、ip_masq_irc.o モジュールが必要
サポートされているプラットフォームすべて
サポートされているプラットフォームすべて
マルチメディアクライアント
Windows、ネットワークストリーミングオーディオ、 ip_masq_raudio モジュールをロードすることが必要
Windows、ネットワークストリーミングオーディオ
Windows、ネットワークストリーミングオーディオ
Windows、クライアントサーバー方式の 3D チャット プログラム
Windows、クライアントサーバー方式の 3D チャット プログラム
Windows、一対一オーディオコミュニケーション 外部と接続するためには、こちらから呼び出す必要があります。 外部からこちら側を呼び出すことはできません。
Windows、一対一オーディオコミュニケーション 外部と接続するためには、こちらから呼び出す必要があります。 外部からこちら側を呼び出すことはできません。
サポートされているプラットフォームすべて、cuseeme モジュールが 必要、詳細は IP Masquerade Resource 参照のこと
Windows、vdolive パッチが必要
原注: IPhone や Powwow などのクライアントは、ipautofw パッケージを 使うことによって、呼び出す側でなくとも動作する可能性があります (セクション 4.6 参照)。
その他のクライアント
telnet、ftp、ping などを含む DOS パッケージ
MS-Windows、TCP/IP を介して PC を遠隔操作、 ホストでは動作せずクライアントのみで動作
ntp (ネットワークタイムプロトコル) を使用
Linux, ネットワーク管理アカウントパッケージ
接続はするが、音声は一方向 (出て行く方向) にしか流れない
サーバに接続できない
対抗側に接続できない
動作せず、カーネルプロキシを書く必要あり
現在のところ動作しない (アドレスに関して不正な仮定をしている)
未テストだが、私の意見では誰かが X のプロキシ (おそらくマスカレード コードの外部プログラムになるだろう) を作らない限り動作しないだろう。 動作させるためのもう一つの方法は、ssh をリンクとして使い、内部の X プロキシを使用することだろう。
基本的には、すべての TCP/IP をサポートしており、ゲートウェイ/ルータを指定する ことができる OS プラットフォームならば、IP マスカレードと動作するはずです。
ここでは、ipfwadm の使用方法をさらに詳しく説明します。
以下に示すのは、スタティックな PPP アドレスを持った PPP リンクの背後の ファイヤウォール/マスカレードシステムの設定です。信頼されるインターフェースは 192.168.255.1 で、PPP インターフェースは悪者を守るために変更されました :-)。 IP スプーフィング (訳注: IP アドレスを詐称して、内部のホストのふりをすること) やスタッフドルート/マスカレードを検出するため、入り側と出側の インターフェースを別々にリストしてあります。 また、明示的に許可していないことはすべて禁止されています！
#!/bin/sh # # /etc/rc.d/rc.firewall, define the firewall configuration, invoked from # rc.local. # PATH=/sbin:/bin:/usr/sbin:/usr/bin # testing, wait a bit then clear all firewall rules. # uncomment following lines if you want the firewall to automatically # disable after 10 minutes. # (sleep 600; \ # ipfwadm -I -f; \ # ipfwadm -I -p accept; \ # ipfwadm -O -f; \ # ipfwadm -O -p accept; \ # ipfwadm -F -f; \ # ipfwadm -F -p accept; \ # ) & # Incoming, flush and set default policy of deny. Actually the default policy # is irrelevant because there is a catch all rule with deny and log. ipfwadm -I -f ipfwadm -I -p deny # local interface, local machines, going anywhere is valid ipfwadm -I -a accept -V 192.168.255.1 -S 192.168.0.0/16 -D 0.0.0.0/0 # remote interface, claiming to be local machines, IP spoofing, get lost ipfwadm -I -a deny -V your.static.PPP.address -S 192.168.0.0/16 -D 0.0.0.0/0 -o # remote interface, any source, going to permanent PPP address is valid ipfwadm -I -a accept -V your.static.PPP.address -S 0.0.0.0/0 -D your.static.PPP.address/32 # loopback interface is valid. ipfwadm -I -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0 # catch all rule, all other incoming is denied and logged. pity there is no # log option on the policy but this does the job instead. ipfwadm -I -a deny -S 0.0.0.0/0 -D 0.0.0.0/0 -o # Outgoing, flush and set default policy of deny. Actually the default policy # is irrelevant because there is a catch all rule with deny and log. ipfwadm -O -f ipfwadm -O -p deny # local interface, any source going to local net is valid ipfwadm -O -a accept -V 192.168.255.1 -S 0.0.0.0/0 -D 192.168.0.0/16 # outgoing to local net on remote interface, stuffed routing, deny ipfwadm -O -a deny -V your.static.PPP.address -S 0.0.0.0/0 -D 192.168.0.0/16 -o # outgoing from local net on remote interface, stuffed masquerading, deny ipfwadm -O -a deny -V your.static.PPP.address -S 192.168.0.0/16 -D 0.0.0.0/0 -o # outgoing from local net on remote interface, stuffed masquerading, deny ipfwadm -O -a deny -V your.static.PPP.address -S 0.0.0.0/0 -D 192.168.0.0/16 -o # anything else outgoing on remote interface is valid ipfwadm -O -a accept -V your.static.PPP.address -S your.static.PPP.address/32 -D 0.0.0.0/0 # loopback interface is valid. ipfwadm -O -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0 # catch all rule, all other outgoing is denied and logged. pity there is no # log option on the policy but this does the job instead. ipfwadm -O -a deny -S 0.0.0.0/0 -D 0.0.0.0/0 -o # Forwarding, flush and set default policy of deny. Actually the default policy # is irrelevant because there is a catch all rule with deny and log. ipfwadm -F -f ipfwadm -F -p deny # Masquerade from local net on local interface to anywhere. ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/16 -D 0.0.0.0/0 # catch all rule, all other forwarding is denied and logged. pity there is no # log option on the policy but this does the job instead. ipfwadm -F -a deny -S 0.0.0.0/0 -D 0.0.0.0/0 -o
-I、-O あるいは -F を使用して、特定のサイトへのトラフィックをブロックする ことができます。ルールセットは上から順にスキャンされ、-a は既存のルール セットへの「追加」を意味するため、制限はグローバルルールの前に記述しないと いけないことに注意してください。たとえば (テストしていませんが)
-I ルールの使用。おそらく最も高速だが、ローカルマシンからのアクセス のみを禁止するため、ファイヤウォールそのものは依然として「禁止された」 サイトへのアクセスが可能。もちろんそのような組合せを許可したいことも 考えられる。
... start of -I rules ... # reject and log local interface, local machines going to 204.50.10.13 ipfwadm -I -a reject -V 192.168.255.1 -S 192.168.0.0/16 -D 204.50.10.13/32 -o # local interface, local machines, going anywhere is valid ipfwadm -I -a accept -V 192.168.255.1 -S 192.168.0.0/16 -D 0.0.0.0/0 ... end of -I rules ...
-O ルールの使用。パケットはまずマスカレードを通過するため最も遅いが、 このルールは禁止されたホストへのファイヤウォールからのアクセスをも 禁止する。
... start of -O rules ... # reject and log outgoing to 204.50.10.13 ipfwadm -O -a reject -V your.static.PPP.address -S your.static.PPP.address/32 -D 204.50.10.13/32 -o # anything else outgoing on remote interface is valid ipfwadm -O -a accept -V your.static.PPP.address -S your.static.PPP.address/32 -D 0.0.0.0/0 ... end of -O rules ...
-F ルールの使用。おそらく -I よりも遅く、このルールもマスカレードされた (つまり内部の) マシンからのアクセスのみを禁止する。ファイヤウォール そのものは依然として禁止されたサイトへのアクセスが可能。
... start of -F rules ... # Reject and log from local net on PPP interface to 204.50.10.13. ipfwadm -F -a reject -W ppp0 -S 192.168.0.0/16 -D 204.50.10.13/32 -o # Masquerade from local net on local interface to anywhere. ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/16 -D 0.0.0.0/0 ... end of -F rules ...
192.168.0.0/16 が 204.50.11.0 にアクセスするために特別なルールは必要 ない。これはグローバルルールによって取り扱われる。
上記のルールでインターフェースをコーディングする方法は複数ある。 例えば -V 192.168.255.1 の代わりに -W eth0 というコードを書くことが できるし、-V your.static.PPP.address の代わりに -W pp0 と書くことが できる。個人的な好みと分かりやすさによって選択できる。
ipchains は、主にカーネル 2.2.x での使用を前提としたファイヤウォール ルールセットの設定ツールです (2.0.x で動かすためのパッチがあります)。
近日中にこのセクションをアップデートして、ipchains の使い方の例をいくつか 載せる予定です。
詳細は、 Linux IP Firewalling Chains page や Linux IPCHAINS HOWTO を参照してください。
/etc/resolv.conf に、複数(3つまで)のネームサーバーを
書いておくという方法もあります。同一のネームサーバーを3回書いても構い
ません。1つだけ書く場合に比べて、DNS のタイムアウト時間が3倍になります。
3つ以上書いても無視されるようです。)
IPautofw は、Linux マスカレードのための TCP と UDP の一般的な フォワーダです。 一般的には、UDP を必要とするパッケージを使用する場合、それ特有の IP マスカレードモジュールをロードする必要があります (ip_masq_raudio、ip_masq_cuseeme など)。 ipautofw はより一般的な方法で動作し、アプリケーション特有のモジュールが フォワードしないトラフィックも含め、あらゆるタイプのトラフィックをフォワード します。正しく管理しないと、これによってセキュリティホールが生じます。
これは Michael Owings 氏の提供によるものです。
ここでは、CU-SeeMe (Cornell と White Pine の両方のバージョン) を Linux の IP マスカレードと一緒に動かすために必要な作業を説明します。
CU-SeeMe はデスクトップビデオ会議パッケージで、Windows や Macintosh のクライアントが利用可能です。フリーのバージョンは Cornell University から取得可能です。 機能の増強された商用バージョンは White Pine Software から購入できます。
IP マスカレードは、LAN 上のワークステーションが、1台の Linux の背後で「仮装」 (マスカレード) することを可能にします。LAN 上のワークステーションは、正当な IP アドレスなしで、インターネットにほぼ透過的にアクセスすることができます。 Linux マシンは LAN からインターネットへ出て行くパケットを書き換え、その Linux マシンから発信されたかのように見せかけます。入ってくる応答パケットは 再び書き換えられ、LAN 上の正しいワークステーションに送り返されます。 このようにして、多くのインターネットアプリケーションが LAN 上のワーク ステーションで透過的に使用できるようになります。いくつかのアプリケーション (たとえば CU-SeeMe) に関しては、正しくパケットを送り返すために Linux マスカレードのコードに手助けが必要です。この手助けは通常、特別なカーネル ローダブルモジュールとして提供されます。IP マスカレードに関するより詳細な 情報は、 The Linux IP Masquerading Website を参照してください。
まず、適当に設定されたカーネルが必要です。IP マスカレードと IP オートフォワーディングの両方に対するサポートが完全に組み込まれてコンパイル されている必要があります。IP オートフォワーディングは、2.0.30 以降のカーネル の設定オプションとして提供されます。それ以前のカーネルは、パッチを当てる 必要があります。IP オートフォワーディングに関しては、 Linux IP Masquerade Resource を 参照してください。
次に、最新バージョンの ip_masq_cuseeme.c を持ってくる必要があります。 最新バージョンは匿名 ftp によって、 ftp://ftp.swampgas.com/pub/cuseeme/ip_masq_cuseeme.c から 入手可能です。このモジュールはまた、カーネル 2.0.31 に組み込まれる 予定です。カーネル中のバージョンをこの新しいバージョンで置き換えて ください。ip_masq_cuseeme.c は通常 Linux ソースツリーの net/ipv4 にあります。このモジュールをコンパイルし、インストールしてください。
そして、UDP ポート 7648-7649 の IP オートフォワーディングを、以下のように 設定してください。
ipautofw -A -r udp 7648 7649 -c udp 7648 -u または ipautofw -A -r udp 7648 7649 -h www.xxx.yyy.zzz <!-- <verb> ipautofw -A -r udp 7648 7649 -c udp 7648 -u OR ipautofw -A -r udp 7648 7649 -h www.xxx.yyy.zzz-->
最初の形式は、最後に呼び出しを行なったワークステーションが、ポート 7648 (Cu-SeeMe のプライマリポート) を使用できるようにします。2番目の形式による ipautofw の起動は、Cu-SeeMe の呼び出しを www.xxx.yyy.zzz だけに許します。 固定的にワークステーションの IP アドレスを指定する必要がないという柔軟性が あるため、私は最初の形式を好んで使います。しかしこの形式の場合、ワーク ステーションが外部からの呼び出しを受け付けるためにはあらかじめ外部への 呼び出しを行なっておかなければいけません。
どちらの形式も、クライアントマシンの UDP ポート 7648-7649 を、外部の世界に 開放することになります。これはセキュリティに重大な問題をもたらすものでは ありませんが、必要な用心を怠らないことは必要です。
最後に、以下のようにして新しい ip_masq_cuseeme モジュールをロードします。
modprobe ip_masq_cuseeme
さあ、これで LAN 上のマスカレードされたマシンから CU-SeeMe を起動して、 外部のリフレクタあるいは別の CU-SeeMe ユーザと接続することが可能なはずです。 外部からの呼び出しも受け付けられるはずです。その際、外部からはマスカレード されたワークステーションではなく、Linux ゲートウェイの IP アドレスを使用 しなければならないことに注意してください。
だめ。不可能。だめなんだってば。 White Pine はソース IP アドレス (クライアントプログラムによって計算される) を使って、送信の前にパスワードを暗号化します。アドレスを書き換える必要が あるため、リフレクタは暗号を解読するのに間違ったソース IP を使用してしまい、 結果として不正なパスワードが得られてしまいます。この問題は、 (私が提案したように) White Pine がパスワードの暗号化方式を変更するか、 彼らがパスワード暗号化ルーチンを公開して私が ip_masq_cuseeme に変更を 加えられるようにすることによってのみ解決可能です。2番目の方法が実現する 可能性はゼロに近いので、私はすべての読者が White Pine にコンタクトして、 最初の方法を提案することを期待しています。このページへのトラフィックは 比較的高いので、この問題を White Pine の優先度リストの上の方に載せるのに 必要なだけの電子メールを喚起できるのではないかと期待しています。
この問題に私の注意を向けてくれた Thomas Griwenka 氏に感謝します。
ip_masq_cuseeme や、ポート 7648 に対する IP オートフォワーディングが動作 している同じマシンでリフレクタを動かしてはいけません。両者ともポート 7648 を必要とするので、全然動かないでしょう。リフレクタを別のインターネット リーチャブルなホストで動かすか、リフレクタを動かす前に CU-SeeMe クライアントサポートを外してください。
現時点では、LAN 上で複数のユーザが同時に CU-SeeMe を使うことはできません。 これは主に CU-SeeMe がポート 7648 を使うことに頑固に固執していることによる ものです。このため、今は1台の LAN ワークステーションにしか (容易には) リダイレクトできないのです。
先に書いたように ipautofw を -c (control port) で起動することによって、 CU-SeeMe が使えるワークステーションアドレスを固定的に指定する必要が なくなります。コントロールポート 7648 を使って送信した最初のワーク ステーションが、7648-7649 上のトラフィックを受信する権利を得るのです。 このワークステーションがポート 7648 を使わなくなって5分たつと、別の ワークステーションが CU-SeeMe を使えるようになります。
コメントや質問は、 mikey@swampgas.com までお願いします。ご希望なら、 CU-SeeMe で呼び出してもらっても結構です。
このセクションは近日中にアップデートし、ipportfw や masqadmin といった IP マスカレードに関連するツールを取り扱う予定です。