名称

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 アドレスにちょうど 進みます。

内向きの宛先の変換 (書き換え)

パケットのリダイレクト (出力先変更) は、パケットの宛先フィールドを変更するために使用され、ネットワークインタフェースで 移動しているパケットに対してサポートされます。 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)