日本語 man コマンド類 (ja-man-1.1j_5) と日本語 man ドキュメント (ja-man-doc-5.4 (5.4-RELEASE 用) など) をインストールすると、以下のような man コマンド閲覧、キーワード検索が コンソールからできるようになります。
4.11-RELEASE-K, 5.4-RELEASE-K, 5.5-RELEASE-K, 6.0-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K, 12.1-RELEASE-K は、 プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K から 12.3-RELEASE-K, 13.0-RELEASE-K から 13.2-RELEASE-K は、全翻訳済み)
13.3-STABLE-K, 15.0-CURRENT-K は現在、作成中で日々更新されています。
Table of Contents
IPNAT(5) IPNAT(5)
名称
ipnat, ipnat.conf - IPFilter NAT ファイルの形式
解説
ipnat.conf ファイルは、IPFilter のネットワークアドレス変換 (Network
Address Translation, NAT) 構成要素のための規則を指定するために使用され
ます。ipnat.conf ファイルで指定される規則をロードするために、ipnat(8)
プログラムが、使用されます。
標準 NAT の機能性について、規則は、map で始まるべきであり、次に、発信パ
ケットのためのインタフェースを指定する進行は、それらの発信元アドレスを
書き直します。これに続いて、古い発信元アドレス、とオプションのポート番
号が指定されることが期待されます。
一般的に、すべての NAT 規則は、次のレイアウトに適合します: 最初の単語
は、どのタイプの NAT 規則が存在するか示し、これは、パケットと一致するた
めにいくつかのスタンザ (stanzas) が続き、"->" が続き、次に、これは、パ
ケットに置かれる新しいデータについて記述するいくつかのさらなるスタンザ
が続きます。
このテキストと他のもので、NAT 規則について話題にするとき、用語 "left
hand side" (LHS, 左辺) の使用は、"->" の前に現われるテキスト、その後に
現われるテキストのための "right hand side" (RHS, 右辺) を参照します。本
質的に、LHS は、パケットの照合で、RHS は、使用される新しいデータです。
変数
この設定ファイルは、IPFilter で使用されるすべての他のもののように、テキ
ストの全体にわたる変数の置換の使用をサポートします。
nif="ppp0";
map $nif 0/0 -> 0/32
は、次のようになります
map ppp0 0/0 -> 0/32
パーザが foo のための割り当てに到達するとき、$bar が存在する限り、
'foo="$bar baz";' のように、変数を再帰的に使用することができるので、
シェル環境変数から使用される変数を定義する方法に関する説明については、
ipnat(8) を参照してください。
外向きの発信元変換 (マッピング)
パケットの発信元アドレスの変更は、map 規則を使用して、伝統的に実行され
ます。様々な制御に従って、発信元アドレスとオプションのポート番号の両方
を変更することができます。
外に出て行くこと開始するために、使用される共通の規則は、次の形式です:
map le0 0/0 -> 0/32
ここで、(0/32 は、インタフェース自体の現在の時点のアドレスと同意語です)
インタフェース le0 のそれに (すべてのパケットと一致する 0/0 のアドレス/
マスクペア) le0 から発信するすべてのパケットの発信元アドレスを変更する
ことを説明します。アドレスの変更なしでパケットを通過したいなら、次のよ
うに書きます:
map le0 0/0 -> 0/0
単に内部ネットワークの一部と、このホストをさかのぼって経路変更される異
なるアドレスに変更したいなら、次のように行うかもしれません:
map le0 10.1.1.0/24 -> 192.168.55.3/32
いくつかの例で、内部アドレスを外に向けてマップするすべてのサブネットが
あり、その場合には、次のように変換を表示することができます:
map le0 10.0.0.0/8 -> 192.168.55.0/24
IPFilter は、それらがすべて使用されたようになることを保証するために
192.168.55.0/24 のアドレス空間の 256 のアドレスの各々を通って循環しま
す。
もちろん、これは、それ自体のポート番号のペアごとに、行なわれた多くの接
続で、TCP と UDP に対して問題を引き起こします。不運であるなら、新しいア
ドレス/ポートのペアのマッピングが既に存在するので、変換を落とすことがで
きます。この問題を軽減するために、ポートの変換またはポートのマッピング
を追加します:
map le0 10.0.0.0/8 -> 192.168.55.0/24 portmap tcp/udp auto
この例で、単語 "auto" は、他のものによって踏みつけられる、それらの心配
なしで使用する LHS の各アドレスのためのポート番号のプライベートの範囲を
計算するように IPFilter に伝えます。それらを期限切れにすることができ
る、IPFilter より速く生成されている接続があるなら、これは、問題を導くか
もしれません。この例で、ポート番号のプライベートの範囲から抜け出したい
なら、次のように記述できます:
map le0 10.0.0.0/8 -> 192.168.55.0/24 portmap tcp/udp 5000:65000
そして、今、le0 を介する各接続は、192.168.55.0/24 の IP アドレスのサブ
ネットと同様にポート番号空間 5000-65000 の列挙を追加します。
使用される新しいアドレスが完全なサブネットではなく連続する範囲内である
なら、次のようにこれを表現することができます:
map le0 10.0.0.0/8 -> range 192.168.55.10-192.168.55.249
portmap tcp/udp 5000:65000
これは、包括的に、192.168.55.10 から 192.168.55.249 まで使用する 240 の
IP アドレスの範囲があることを IPFilter に伝えます。
使用のためのアドレスのいくつかの範囲があったなら、次のようなラウンドロ
ビンの方法で各々を使用することができます:
map le0 10.0.0.0/8 -> range 192.168.55.10-192.168.55.29
portmap tcp/udp 5000:65000 round-robin
map le0 10.0.0.0/8 -> range 192.168.55.40-192.168.55.49
portmap tcp/udp 5000:65000 round-robin
特定の IP プロトコルに影響を与える変換規則を指定するために、プロトコル
名または数は、次のような規則に追加されます:
map le0 10.0.0.0/8 -> 192.168.55.0/24 tcp/udp
map le0 10.0.0.0/8 -> 192.168.55.1/32 icmp
map le0 10.0.0.0/8 -> 192.168.55.2/32 gre
MTU が通常のイーサネットよりわずかに小さいところで PPPoE のような接続を
終了する TCP 接続について、いずれかの終りが、大きすぎ、フラグメンテー
ションの結果であるパケットを送信することを試みるありそうな状態を縮小し
て、一致する内部マシンによって提示された最大のセグメントサイズ (Maximum
Segment Size, MSS) を縮小するために役に立つかもしれません。これは、次の
ような TCP map 規則がある mssclamp オプションを使用して達成されます:
map pppoe0 0/0 -> 0/32 mssclamp 1400 tcp
ICMP パケットについて、問い合わせパケットで ICMP ID 空間をマップするこ
とができます:
map le0 10.0.0.0/8 -> 192.168.55.1/32 icmpidmap icmp 1000:20000
LHS で最初の一致する基準に関してより明確にしたいなら、ipf.conf(5) で、
それにより似ている構文を使用して拡張することができます:
map le0 from 10.0.0.0/8 to 26.0.0.0/8 ->
192.168.55.1
map le0 from 10.0.0.0/8 port > 1024 to 26.0.0.0/8 ->
192.168.55.2 portmap 5000:9999 tcp/udp
map le0 from 10.0.0.0/8 ! to 26.0.0.0/8 ->
192.168.55.3 portmap 5000:9999 tcp/udp
注: 発信元アドレスと一致する否定は、map / map-block 規則で可能な NOT
です。
NAT コードには、他のすべてのプロトコルに対して TCP、UDP、ICMP と別のも
ののための組み込みのデフォルトのタイムアウトがあります。一般的に、一旦
応答パケットが (TCP 以外に) 見られたら、削除されたシュリンクへのエント
リのためのタイムアウト。利用者自身のタイムアウトを指定したいなら、両方
の指示のために 1 つのタイムアウトを設定することによって、これを、達成す
ることができます:
map le0 0/0 -> 0/32 gre age 30
または、応答のための異なるタイムアウトを設定します:
map le0 from any to any port = 53 -> 0/32 age 60/10 udp
NAT を使用するとき、多くの人々が遭遇する緊急の問題は、アプリケーション
の通信の内側でアドレスプロトコルを組み込むことができるということです。
この問題に対処するために、IPFilter は、FTP のような、より共通のトラブル
メーカのために多くの組み込みのプロキシ (代理人) を提供しています。これ
らのプロキシ (代理) は、次のように使用することができます:
map le0 0/0 -> 0/32 proxy port 21 ftp/tcp
この規則で、単語 "proxy" は、内部のプロキシでこの変換を接続したいと利用
者に伝えます。"port 21" は、この規則が活性化されるなら、21 となる宛先
ポート番号を要求する特別の制限です。単語 "ftp" は、パケットが一致しなけ
ればならない "tcp" プロトコルである、カーネルが内部的に試みて解決するプ
ロキシ識別子です。
プロキシのリストとそれらの相対的な状態については、下記を参照してくださ
い。
フィルタリング規則を NAT 規則に関連させるために、内向きまたは外向きの処
理のいずれかの間にタグを設定し、照合することは可能です。現在のところ、
転送されたパケットのためのタグは、転送によって保存されないので、いった
んパケットが IPFilter を去ると、タグは、忘れられます。map 規則につい
て、次のようなフィルタ規則によって設定されたタグと一致することができま
す:
map le0 0/0 -> 0/32 proxy portmap 5000:5999 tag lan1 tcp
これは、"set-tag (nat = lan1)" のようなスタンザ (stanza) を含む "pass
out" 規則で使用されます。
パケットが受信されるインタフェースが、パケットが送信されるインタフェー
スと異なるなら、変換規則は、これを考慮に入れて書き込まれる必要がありま
す:
map hme0,le0 0/0 -> 0/32
これは、直観に反したように見えるかもしれませんが、ipnat.conf のための規
則でリストされるときのインタフェースは、常に inbound、outbound の順に
なっています。この場合に、hme0 は、返りのインタフェースになり、le0 は、
発信のインタフェースになります。利用者があらゆるインタフェースで返りの
パケットを許可したいなら、使用する正確な構文は、次の通りです:
map *,le0 0/0 -> 0/32
map 規則の特別の変異型は、map-block と呼ばれて存在します。このコマンド
は、ネットマスクの差がサイズで 14 ビット以上の差であるところで、より小
さなネットワーク上に大規模なネットワークをマップしなければならないと
き、使用することを目的としています。これは、各発信元アドレスが使用する
ポートのそれ自体のプライベートな範囲があることを保証するためにアドレス
空間とポート空間を分割することによって達成されます。例えば、次の規則:
map-block ppp0 172.192.0.0/16 -> 209.1.2.0/24 ports auto
は、それ自体の 252 のポートがある 172.192.0.0 から 172.192.0.255 までの
各アドレスで 209.1.2.0/32 にマップされる 172.192.0.0/24 の結果となりま
す。map の上記の使用とは対照的に、ある理由で、172.192.0.2 の (例えば)
172.192.0.2 のユーザが 260 の同時の外向きの接続を望むなら、それらは、
map-block で 252 に制限されますが、map コマンドで次の IP アドレスにちょ
うど進みます。
拡張の照合
それにアドレス変換を適用する前に、パケットの発信元と宛先の両方で一致す
ることが望ましいなら、ipf.conf(5) で使用されるように、同じ from-to 構文
を使用することによって、これを、達成することができます。その後に起こる
ことは、上で議論された map 規則、と下で議論された rdr 規則に等しく適用
されます。単純な例は、次の通りです:
map bge0 from 10.1.0.0/16 to 192.168.1.0/24 -> 172.12.1.4
これは、10.1.0.0/16 と一致する発信元アドレスと 192.168.1.0/24 と一致す
る宛先があるホストから着信するパケットとのみと一致します。次のような
TCP のためのポートで、これを拡張することができます:
rdr bge0 from 10.1.0.0/16 to any port = 25 -> 127.0.0.1 port 2501 tcp
ここで、ポート 25 への 10.1.0.0/16 から TCP パケットのみ、ポート 2501
にリダイレクト (出力先を変更) されます。
ipf.conf(5) と同様に、一致したいネットワークとアドレスの大きな組がある
なら、ippool.conf(5) の ippool(8) を使用してプールを定義することがで
き、次のような ipnat 規則で参照します:
map bge0 from pool/100 to any port = 25 -> 127.0.0.1 port 2501 tcp
注: この状況で、規則は、"0" のネットマスクがあると見なされるので、た
とえ、単に定義されたプール /24 のものまたは /32 のものがあって
も、それらに /16 のものまたは /24 のものがあるあらゆる規則の後、
最後に見つけられます。また、プールは、ipnat.conf(5) の from-to
構文が許可されるところで、使用されます。
内向きの宛先の変換 (書き換え)
パケットのリダイレクト (出力先変更) は、パケットの宛先フィールドを変更
するために使用され、ネットワークインタフェースで移動しているパケットに
対してサポートされます。map 規則のための同じ一般的な構文がサポートされ
る一方、違いと制限があります。
最初に、デフォルトで、すべてのリダイレクション規則は、ネットワークまた
はネットワークアドレスの範囲ではないので、規則は、次のように書かれ、単
一の IP アドレスををターゲットとします:
rdr le0 0/0 -> 192.168.1.0
そのクラス C ネットワークのすべての 256 の IP アドレスに渡ってパケット
を展開しません。次のような規則を試みるなら:
rdr le0 0/0 -> 192.168.1.0/24
次に、解析エラーを受信します。
否定とともに、しかしながら制限の移動の rdr 規則で map 規則で使用される
from-to 発信元-宛先照合を使用することができます - 否定される発信元アド
レスのみ一致することができます:
rdr le0 from 1.1.0.0/16 to any -> 192.168.1.3
rdr le0 ! from 1.1.0.0/16 to any -> 192.168.1.4
パケットを広げたいアドレスの連続的な組があるなら、2 つの方法の 1 つで、
これを行なうことができ、保存する、オプションの単語 "range" は、次の通り
です:
rdr le0 0/0 -> 192.168.1.1 - 192.168.1.5
rdr le0 0/0 -> range 192.168.1.1 - 192.168.1.5
パケットに渡って分割する 2 つのアドレスのみがあるなら、推奨された方法
は、次のようにコンマ (",") を使用することです:
rdr le0 0/0 -> 192.168.1.1,192.168.1.2
いくらか自然に解体する宛先アドレスの大きなグループがあるなら、次のよう
なラウンドロビン技術を使用して、それらによって循環することができます:
rdr le0 0/0 -> 192.168.1.1,192.168.1.2 round-robin
rdr le0 0/0 -> 192.168.1.5,192.168.1.7 round-robin
rdr le0 0/0 -> 192.168.1.9 round-robin
ターゲットとされている多くのリダイレクト規則とホストがあるなら、同じ宛
先アドレスをターゲットとする単一発信元アドレスから、それらのすべてがあ
ることが望ましいかもしれません。これを達成するために、単語 sticky は、
次のような規則に追加されます:
rdr le0 0/0 -> 192.168.1.1,192.168.1.2 sticky
rdr le0 0/0 -> 192.168.1.5,192.168.1.7 round-robin sticky
rdr le0 0/0 -> 192.168.1.9 round-robin sticky
ラウンドロビンとコンマの使用と sticky 機能を単に組み合わせることができ
ます。
TCP と UDP のパケットについて、宛先ポート番号で一致し、それを修正するこ
とは可能です。例えば、80 から 3128 まで宛先ポートを変更するために、次の
ような規則を使用します:
rdr de0 0/0 port 80 -> 127.0.0.1 port 3128 tcp
ポートの範囲が LHS で与えられ、単一のポートが RHS で与えられるなら、
ポートのすべての範囲は、移動されます。例えば、次のようなものがあったな
ら:
rdr le0 0/0 port 80-88 -> 127.0.0.1 port 3128 tcp
次に、ポート 80 は、3128 となり、ポート 81 は、3129 など、となります。
単なる単一のポートに多くの異なるポット (pot) をリダイレクトしたいなら、
等号 ("=") は、次のような RHS のポート番号の前に置かれます:
rdr le0 0/0 port 80-88 -> 127.0.0.1 port = 3128 tcp
この場合に、ポート 80 は、3128 に行き、ポート 81 は、3128 に行く、など
となります。
map 規則と同様に次のような age オプションを使用して、手動でタイムアウト
を設定することは、可能です:
rdr le0 0/0 port 53 -> 127.0.0.1 port 10053 udp age 5/5
プロキシの使用は、map 規則と外向きのセッションに制限されません。また、
構文は、わずかに異なりますが、プロキシをリダイレクト規則で使用すること
ができます:
rdr ge0 0/0 port 21 -> 127.0.0.1 port 21 tcp proxy ftp
rdr 規則について、供給されたインタフェースは、map 規則と同じ順序になっ
ています - 入力が最初で、次に出力。発信インタフェースが確かでない状況
で、また、あらゆるインタフェースで一致に効果があるワイルドカード ("*")
を使用することは可能です。
rdr le0,* 0/0 -> 192.168.1.0
可能なだけオプションの設定がある単一の規則は、何か次のように見えます:
rdr le0,ppp0 9.8.7.6/32 port 80 -> 1.1.1.1,1.1.1.2 port 80 tcp
round-robin frag age 40/40 sticky mssclamp 1000 tag tagged
発信元と宛先の書き直し
上記の 2 つのコマンドがパケットのアドレスするフィールドの変更で、多くの
柔軟性を提供している一方、発信元と宛先の両方を同時に変換するか、または
入力の発信元アドレスまたは出力の宛先アドレスを変更することは、しばし
ば、利益があります。これらのものをすべて行なうことで、rewrite (再書き込
み) NAT 規則を使用して達成することができます。
rewrite (再書き込み) 規則は、以前のようなプロトコルと発信元/宛先情報と
一致するパケットの同じレベルを要求しますが、さらに、in または out は、
次にように指定することができます:
rewrite in on ppp0 proto tcp from any to any port = 80 ->
src 0/0 dst 127.0.0.1,3128;
rewrite out on ppp0 from any to any ->
src 0/32 dst 10.1.1.0/24;
RHS において、送信されているパケットに入れる新しい発信元と宛先の両方の
情報を指定することができます。ipnat.conf で使用されている他の規則と同様
に、ネットワークインタフェース (0/32) に関連したオリジナルのアドレス情
報 (0/0) とアドレスを使用することができる手っ取り早い構文があります。
TCP と UDP について、アドレスとポート情報の両方を、変更することができま
す。現在のところ、次のように使用される (X-Y) ポート番号の範囲または単一
のポート番号 (= X) のいずれかを指定することは単に可能です:
rewrite in on le0 proto tcp from any to any port = 80 ->
src 0/0,2000-20000 dst 127.0.0.1,port = 3128;
新しい宛先を作成するために利用可能な数の空間の列挙を通して 4 つのフィー
ルドがあります:
発信元アドレス
発信元ポート
宛先アドレス
宛先ポート
これらの 1 つが静的となるように起こるなら、それは、スキップされ、次のも
のが増加されます。例として:
rewrite out on le0 proto tcp from any to any port = 80 ->
src 1.0.0.0/8,5000-5999 dst 2.0.0.0/24,6000-6999;
変換されたパケットは、次の通りです:
1st src=1.0.0.1,5000 dst=2.0.0.1,6000
2nd src=1.0.0.2,5000 dst=2.0.0.1,6000
3rd src=1.0.0.2,5001 dst=2.0.0.1,6000
4th src=1.0.0.2,5001 dst=2.0.0.2,6000
5th src=1.0.0.2,5001 dst=2.0.0.2,6001
6th src=1.0.0.3,5001 dst=2.0.0.2,6001
など。
map 規則と同様に、アドレスの前の単語 range を含めることによって、アドレ
スの範囲を指定することが可能です:
rewrite from any to any port = 80 ->
src 1.1.2.3 - 1.1.2.6 dst 2.2.3.4 - 2.2.3.6;
パケットの迂回
カプセル化を解除される単なる別のコンピュータではなく、UDP ソケットへパ
ケットを送信したいなら、これを divert 規則を使用して達成することができ
ます。
打ち向きと外向きのパケットの両方で divert 規則を使用することができま
す。しかしながら、規則は、アドレスの範囲、またはネットマスクでなく、
ちょうど単一のアドレスで、外向きのパケットのためのホストアドレスを指定
しなければなりません。さらに、構文は、UDP のために要求された情報を供給
しなければなりません。divert 規則のように見えるものの例は、次の通りで
す:
divert in on le0 proto udp from any to any port = 53 ->
src 192.1.1.1,54 dst 192.168.1.22.1,5300;
RHS でなく、LHS において、一致する能力の通常の集合であり、発信元と宛先
アドレスの両方とポートを指定する要求です。
この機能が、他のシステムで実行されている IPFilter ではなくソケットで
ターゲットとするパケットと共に使用されることを目的としているように、パ
ケットを undivert (迂回しない) するために提供される規則はありません。
注: UDP ヘッダとカプセル化されている IP ヘッダの追加によって、パケッ
トが、外向きのネットワークインタフェースによって許可されたサイズ
を超過しているなら、diverte (迂回) されたパケットは、フラグメン
トされているかもしれません。現在のところ、この機能が両方の終了点
に透過となることを目的としているように、パス MTU 発見を起こらせ
ることは可能ではありません。パス MTU 発見が使用されていて、カプ
セル化されるパケットに "do not fragment" フラグが設定されている
なら、ICMP エラーメッセージは、新しいパケットがフラグメント化さ
れる必要があるなら、送信側に送りもどされます。
共通オプション
このセクションは、すべての規則で利用可能なオプションを処理します。
purge purge キーワードが NAT 規則の終りに追加されるとき、アクティブな
NAT セッションのすべては、規則が個別の操作として削除されるとき、
削除されます。NAT 規則がすべてがフラッシュアウトされるなら、オペ
レータが同様に NAT テーブルをフラッシュすることが期待され、した
がって、NAT 規則がフラッシュアウトされるとき、NAT セッションは、
削除されません。
規則順序
注: ipnat.conf の規則は、リストされるようにシーケンシャルに読み込まれ、
この方法でカーネルにロードされますがパケットの照合は、32 から 0 まで
行って、ネットマスクで行なわれます。規則が 1 組のアドレスまたはネット
ワークを参照する pool または hash を使用するなら、これらのフィールドの
ためのネットマスク値は、"0" であると見なされます。それで、利用者の
ipnat.conf に次の規則がある場合:
rdr le0 192.0.0.0/8 port 80 -> 127.0.0.1 3132 tcp
rdr le0 192.2.0.0/16 port 80 -> 127.0.0.1 3131 tcp
rdr le0 from any to pool/100 port 80 -> 127.0.0.1 port 3130 tcp
rdr le0 192.2.2.0/24 port 80 -> 127.0.0.1 3129 tcp
rdr le0 192.2.2.1 port 80 -> 127.0.0.1 3128 tcp
次に、192.2.2.1 がある規則は、上記の規則の順序で、どこに現われるかにか
かわらず、first に一致します。実際に、パケットと一致するために、それら
が使用される順序は、次の通りです:
rdr le0 192.2.2.1 port 80 -> 127.0.0.1 3128 tcp
rdr le0 192.2.2.0/24 port 80 -> 127.0.0.1 3129 tcp
rdr le0 192.2.0.0/16 port 80 -> 127.0.0.1 3131 tcp
rdr le0 192.0.0.0/8 port 80 -> 127.0.0.1 3132 tcp
rdr le0 from any to pool/100 port 80 -> 127.0.0.1 port 3130 tcp
ここで、最初の行は、実際に /32 です。
利用者の ipnat.conf ファイルに一致するターゲットフィールド (map 規則の
ための発信元アドレスと rdr 規則のための宛先アドレス) があるエントリがあ
るなら、ipnat.conf ファイルの順序は、重要です。それで、利用者に次がある
場合:
rdr le0 from 1.1.0.0/16 to 192.2.2.1 port 80 -> 127.0.0.1 3129 tcp
rdr le0 from 1.1.1.0/24 to 192.2.2.1 port 80 -> 127.0.0.1 3128 tcp
次に、パケットは、2 番目の規則と一致せず、それらは、すべて最初と一致し
ます。
IPv6
上記の例のすべてで、IPv4 アドレスが存在するところで、IPv6 アドレスも使
用することができます。すべての規則は、NAT 規則の両方の半分がある IPv4
アドレスまたは両方の半分のための IPv6 アドレスのいずれかを使用しなけれ
ばなりません。単一の規則で、IPv6 アドレスと IPv4 アドレスを混合すること
は、エラーとなります。
"0/32" のような省略記法について、IPv6 に対して等価なものは、"0/128" で
す。IPFilter は、アドレスが、IPv4 ではなく IPv6 であるべきである、暗黙
の指示として、32 を超える、あらゆるネットマスクを扱います。0/0 で明白と
なるために、IPv6 に対しては、::0/0 を使用します。
パーネルのプロキシ (代理)
IP フィルタは、単純で、少数に付属し、ユーザプログラムを通してパケットを
強制せずにオープンされる、二次的なチャネルを許可するカーネルにロードさ
れるコードに組み込まれるプロキシ (代理) です。ｐｒｏｋｉｓｉの現在の状
態は、3 つの状態の 1 つとして、以下にリストされます:
老化 (aging) - プロトコルは、プロキシが書かれた時から大ざっぱに理解され
ますが、それは、よくテストされていないか、または維持されていませ
ん。
開発的 (developmental) - 基本的な機能は、存在し、ほとんどの場合動作しま
すが、拡張された実際の使用の問題となるかもしれません。
実験的 (experimental) - よくてもプロトコルの大まかなサポートは、適切に
プロトコルをサポートするためのコードへの可能性のある大規模な変更
で、よくても散発的であるテストとして動作するかどうか分かりませ
ん。
成熟する (mature) - よくテストされ、プロトコルは、プロキシによって適切
に解釈されます。
現在、プロキシのリストでコンパイルされたものは、次の通りです:
FTP - 熟成中
(map ... proxy port ftp ftp/tcp)
IRC - 試験的
(proxy port 6667 irc/tcp)
rpcbind - 試験的
PPTP - 試験的
H.323 - 試験的
(map ... proxy port 1720 h323/tcp)
Real Audio (PNA) - 熟成済
DNS - 開発的
(map ... proxy port 53 dns/udp { block .cnn.com; })
IPsec - 開発的
(map ... proxy port 500 ipsec/tcp)
netbios - 試験的
R-command - 熟成中
(map ... proxy port shell rcmd/tcp)
関連ファイル
/dev/ipnat
/etc/protocols
/etc/services
/etc/hosts
関連項目
ipnat(4), hosts(5), ipf(5), services(5), ipf(8), ipnat(8)
IPNAT(5)