日本語 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
IPFW(8) FreeBSD システム管理者マニュアル IPFW(8)
名称
ipfw -- ファイアウォール、トラフィックシェイパ、パケットスケジューラ、
カーネル内 NAT のためのユーザインタフェース
書式
ファイアウォール設定
ipfw [-cq] add rule
ipfw [-acdefnNStT] [set N] {list | show} [rule | first-last ...]
ipfw [-f | -q] [set N] flush
ipfw [-q] [set N] {delete | zero | resetlog} [number ...]
ipfw set [disable number ...] [enable number ...]
ipfw set move [rule] number to number
ipfw set swap number number
ipfw set show
SYSCTL ショートカット
ipfw enable
{firewall | altq | one_pass | debug | verbose | dyn_keepalive}
ipfw disable
{firewall | altq | one_pass | debug | verbose | dyn_keepalive}
検索テーブル
ipfw [set N] table name create create-options
ipfw [set N] table {name | all} destroy
ipfw [set N] table name modify modify-options
ipfw [set N] table name swap name
ipfw [set N] table name add table-key [value]
ipfw [set N] table name add [table-key value ...]
ipfw [set N] table name atomic add [table-key value ...]
ipfw [set N] table name delete [table-key ...]
ipfw [set N] table name lookup addr
ipfw [set N] table name lock
ipfw [set N] table name unlock
ipfw [set N] table {name | all} list
ipfw [set N] table {name | all} info
ipfw [set N] table {name | all} detail
ipfw [set N] table {name | all} flush
DUMMYNET 設定 (トラフィックシェイパとパケットスケジューラ)
ipfw {pipe | queue | sched} number config config-options
ipfw [-s [field]] {pipe | queue | sched} {delete | list | show}
[number ...]
カーネル内 NAT
ipfw [-q] nat number config config-options
ステートフル IPv6/IPv4 ネットワークアドレスとプロトコル変換
ipfw [set N] nat64lsn name create create-options
ipfw [set N] nat64lsn name config config-options
ipfw [set N] nat64lsn {name | all} {list | show} [states]
ipfw [set N] nat64lsn {name | all} destroy
ipfw [set N] nat64lsn name stats [reset]
ステートレス IPv6/IPv4 ネットワークアドレスとプロトコル変換
ipfw [set N] nat64stl name create create-options
ipfw [set N] nat64stl name config config-options
ipfw [set N] nat64stl {name | all} {list | show}
ipfw [set N] nat64stl {name | all} destroy
ipfw [set N] nat64stl name stats [reset]
XLAT464 CLAT IPv6/IPv4 ネットワークアドレスとプロトコル変換
ipfw [set N] nat64clat name create create-options
ipfw [set N] nat64clat name config config-options
ipfw [set N] nat64clat {name | all} {list | show}
ipfw [set N] nat64clat {name | all} destroy
ipfw [set N] nat64clat name stats [reset]
IPv6 から IPv6 ネットワーク接頭辞変換
ipfw [set N] nptv6 name create create-options
ipfw [set N] nptv6 {name | all} {list | show}
ipfw [set N] nptv6 {name | all} destroy
ipfw [set N] nptv6 name stats [reset]
内部診断
ipfw internal iflist
ipfw internal talist
ipfw internal vlist
規則と前処理のリスト
ipfw [-cfnNqS] [-p preproc [preproc-flags]] pathname
解説
ipfw ユーティリティは、ipfw(4) ファイアウォール、dummynet(4) トラフィック
シェイパ/パケットスケジューラとカーネル内 NAT サービスを制御するための
ユーザインタフェースです。
ファイアウォールの設定、または規則セットは、1 から 65535 までの番号が付け
られた規則のリストでできています。パケットは、プロトコルスタック中の多く
の異なった場所からファイアウォールに渡されます (パケットの発信元と宛先に
よっては、ファイアウォールが同じパケットで複数回起動される可能性がありま
す)。ファイアウォールに渡されたパケットは、規則番号の順序で、規則セット中
のそれぞれの規則に対して比較されます (同じ数がある複数の規則が許可されま
す、その場合、それらは、挿入された順序で処理されます)。一致したとき、一致
する規則に対応するアクションが実行されます。
アクションと特定のシステム設定によって、さらなる処理に対して一致するもの
の後に、いくつかの規則でファイアウォールにパケットを再投入することができ
ます。
規則セットは、修正または削除することができず、すべてのパケットと一致する
(65535 と番号が付けられる) デフォルトの規則を常に含んでいます。デフォルト
の規則に関連したアクションは、カーネルがどのように設定されるかに依存して
deny または allow のいずれかを指定できます。
規則セットが keep-state, record-state, limit または set-limit オプション
がある 1 つ以上の規則を含んでいるなら、ファイアウォールには、ステートフル
(状態依存型) の振る舞いがあります、すなわち、照合において動的規則を作成し
ます、すなわち、それらの作成を引き起こしたパケットとして同じ 5 つの組 (プ
ロトコル、発信元と宛先アドレスおよびポート) があるパケットと一致する規
則。生存時間が有限である動的規則は、check-state, keep-state または limit
規則の最初に生じた時点でチェックされ、正当なトラフィックのみをオンデマン
ドで、ファイアウォールをオープンするために通常使用されます。keep-state と
limit は、(これらだけが規則によって一致するのみならず) すべてのパケットの
ために check-state を暗黙に意味しますが、record-state と set-limit には、
check-state を暗黙でないことを注意してください。ipfw のステートフルな振る
舞いに関する詳細については、下記の「ステートフルファイアウォール」と「使
用例」のセクションを参照してください。
すべての規則 (動的なものを含む) は、わずかに関連するカウンタがあります:
パケットカウント、バイトカウント、ログカウントと最後に一致した時間を示し
ているタイムスタンプ。ipfw コマンドでカウンタを表示するか、またはリセット
することができます。
各規則は、32 個の異なるセットの 1 つに属し、有効にする、無効にする、セッ
トを入れ換える、セット中のすべての規則を別のセットへ移動する、セット中の
すべての規則を削除するような、セットを不可分に操作する ipfw コマンドがあ
ります。これらは、一時的な設定をインストールするか、または設定をテストす
るめに役に立つかもしれません。セットに関する詳細については、セクション
「規則のセット」を参照してください。
add コマンドで規則を追加することができます。delete コマンドで個別またはグ
ループで、(セット 31 のそれらを除いて) flush コマンドで全体的に削除されま
す。オプションで show と list コマンドを使用して、カウンタの内容を表示さ
れます。最後に、zero と resetlog コマンドでカウンタをリセットすることがで
きます。
コマンドオプション
次の一般的なオプションは、ipfw を呼び出すとき、利用可能です:
-a 規則をリストするとき、カウンタ値を表示します。show コマンドは、こ
のオプションの意味を含みます。
-b 規則の本体ではなく、アクションとコメントだけを表示します。-c の意
味を含みます。
-c 規則を入力するかまたは表示するとき、コンパクトな形式でそれらを印
刷 (表示) します。すなわち、規則が何の追加情報も持たないとき、"ip
from any to any" 文字列を省略します。
-d リストするとき、静的な規則に加えて動的な規則を表示します。
-D リストするとき、動的な状態だけを表示します。削除するとき、動的な
状態だけを削除します。
-f 誤用されるなら、すなわち、flush、問題を起こるかもしれない、コマン
ドのための確認のためにプロンプトを出さずに実行します。プロセスに
関連する tty がないなら、これが、暗示されます。このフラグがある
delete コマンドは、起こり得るエラー、すなわち、存在しない規則番
号、を無視します。そして、バッチのコマンド実行のために、次のコマ
ンドを継続します。
-i テーブルをリストするとき、(検索テーブルに関する詳しい情報について
は、下記の「検索テーブル」セクションを参照) 形式は、IP アドレスと
して評価します。デフォルトで、値は、整数として表示されます。
-n 実際にカーネルにそれらを渡さずに、コマンド文字列の構文だけを
チェックします。
-N 出力のアドレスとサービス名を解決しようと試みます。
-q add, nat, zero, resetlog または flush コマンドを実行するとき、静
かにします。(-f の意味を含みます)。スクリプト (例えば、
`sh /etc/rc.firewall') で複数の ipfw コマンドを実行することによっ
て、またはリモートログインセッションに経由で多くの ipfw 規則があ
るファイルを処理することによって規則セットを更新するとき、これは
役に立ちます。また、(追加の場合) エントリが既に存在しているか、ま
たは (削除の場合) 存在していないならテーブルの追加または削除を停
止します。
このオプションが重要である理由は、ipfw がメッセージを印刷する、こ
れらのアクションのいくつかのためにです。アクションがリモートクラ
イアントへのトラフィックをブロックする結果となるなら、リモートロ
グインセッションは、クローズされ、規則セットの残りは、処理されま
せん。次に、コンソールへのアクセスが、回復するために必要とされま
す。
-S 規則をリストするとき、各規則が属しているセットを表示します。この
フラグが指定されないなら、無効の規則は、リストされません。
-s [field]
パイプをリストするとき、4 つのカウンタの 1 つにしたがってソートし
ます (合計または現在のパケットまたはバイト)。
-t リストするとき、ctime() で変換された最後に一致するタイムスタンプ
を表示します。
-T リストするとき、基準時点から秒として最後に一致するタイムスタンプ
を表示します。この形式は、スクリプトによって後処理により便利で
す。
規則と前処理のリスト
設定を容易にするために、規則は、最後の概要行に表示されるように ipfw を使
用して処理されるファイルに置くことができます。pathname は、絶対パスが使用
されなければなりません。ファイルは、各行ごとに読み込まれ、ipfw ユーティリ
ティの引数として適用されます。
オプションで、-p preproc を使用してプリプロセッサを指定することができま
す、ここで、pathname は、パイプに送られます。役に立つプリプロセッサは、
cpp(1) と m4(1) を含んでいます。preproc がその最初の文字としてスラッシュ
(`/') で始まらないなら、通常、PATH 名の検索が実行されます。ipfw が実行さ
れている時間によってすべてのファイルシステムが (まだ) マウントされている
環境で (例えば、それらが、NFS を越えてマウントされているとき) 注意してく
ださい。いったん -p が指定されると、あらゆる追加の引数は、解釈のためにプ
リプロセッサに渡されます。これは、IP アドレスのような頻繁に必要とされる引
数を集中化するために、柔軟な設定ファイル (ローカルなホスト名でそれらを条
件付けするような) とマクロの使用を可能にします。
トラフィックシェイパの設定
ipfw の pipe, queue と sched コマンドは、トラフィックシェイパとパケットス
ケジューラを設定するために使用されます。詳細については、下記の「トラ
フィックシェイパ (DUMMYNET) 設定」セクションを参照してください。
world と kernel が同期していないことが分かるなら、あらゆる規則を追加する
ことができることを妨げ、ipfw ABI は、壊れるかもしれません。これは、ブート
プロセスに悪影響を与えるかもしれません。利用者が問題を解決することを可能
にして、ネットワークへのアクセスを回復するためにファイアウォールを一時的
に無効にする ipfw disable firewall を使用することができます。
パケットフロー
パケットは、いくつかの sysctl 変数の管理下で、プロトコルスタックの複数の
場所で活発な規則セットと照合されます。これらの場所と変数は、以下に示さ
れ、正確な規則セットを設計することを考慮して、この図があることは重要で
す。
^ to upper layers V
| |
+----------->-----------+
^ V
[ip(6)_input] [ip(6)_output] net.inet(6).ip(6).fw.enable=1
| |
^ V
[ether_demux] [ether_output_frame] net.link.ether.ipfw=1
| |
+-->--[bdg_forward]-->--+ net.link.bridge.ipfw=1
^ V
| to devices |
同じパケットがファイアウォールを通り抜ける回数は、パケットの発信元と宛先
とシステム構成に依存している 0 から 4 までの間で変化するかもしれません。
パケットがスタックを通るように、ヘッダを取り除くかまたは追加することがで
きるので、それらは、検査のために利用可能であるかどうか分からないことに注
意してください。例えば、着信してくるパケットは、ipfw が ether_demux() か
ら呼び出されるとき、MAC ヘッダを含みますが、同じパケットは、ipfw は、
ip_input() または ip6_input() から呼び出されるとき、取り除かれた MAC ヘッ
ダがあります。
また、各パケットは、チェックが起こる場所、またはパケットの発信元にかかわ
りなく常に完全な規則セットに対してチェックされることに注意してください。
規則が、呼び出しの (例えば、ip_input または ip6_input 内の MAC ヘッダと一
致しようと試みること) 場所のために有効ではないいくつかの一致パターンまた
はアクションを含んでいるなら、照合パターンは、一致しませんが、そのような
パターンの前の not 演算子は、パターンをそれらのパケットで常に一致させま
す。したがって、それは、必要であるなら、可能な場所にそって区別するために
適切な規則セットを書くことはプログラマの責任です。skipto 規則は、次の例の
ように、ここで役に立つかもしれません:
# ether_demux または bdg_forward からのパケット
ipfw add 10 skipto 1000 all from any to any layer2 in
# ip_input からのパケット
ipfw add 10 skipto 2000 all from any to any not layer2 in
# ip_output からのパケット
ipfw add 10 skipto 3000 all from any to any not layer2 out
# ether_output_frame からのパケット
ipfw add 10 skipto 4000 all from any to any layer2 out
(はい、現在のところ ether_demux と bdg_forward を区別する方法はありませ
ん)。
また、アクション allow, deny, netgraph, ngtee と dummynet に関連すること
だけは、layer2 フレームとあたかも、それらが、そのようなフレームのために、
allow (許可) されるかのように、すべての他のアクションの振る舞いのために処
理されることに注意してください。アクションの完全な集合は、layer2 ヘッダの
みなしで IP パケットのためにサポートされます。例えば、divert アクション
は、layer2 フレームを迂回しません。
構文
文法一般的に、各キーワードまたは引数は、先導する空白、または後続する空白
なしで、個別のコマンド行引数として提供されなければなりません。キーワード
は、大文字と小文字を区別するのに対して、引数は、それらの性質に依存して、
大文字と小文字を区別するかもしれないし、しないかもしれません (例えば、uid
は、区別しますが、ホスト名は、区別しません)。
いくつかの引数 (例えば、ポートまたはアドレスのリスト) は、コンマで区切ら
れた値のリストです。この場合に、コンマ ',' の後の空白は、行をより読み易く
するために許可されます。また、利用者は、(フラグを含んで) 全体のコマンドを
単一の引数に入れることができます。例えば、次の形式は、同等です:
ipfw -q add deny src-ip 10.0.0.0/24,127.0.0.1/8
ipfw -q add deny src-ip 10.0.0.0/24, 127.0.0.1/8
ipfw "-q add deny src-ip 10.0.0.0/24, 127.0.0.1/8"
規則の形式
ファイアウォールの規則の形式は、次の通りです:
[rule_number] [set set_number] [prob match_probability] action
[log [logamount number]] [altq queue] [{tag | untag} number] body
規則の本体は、次の間に、情報がパケットをフィルタリングするために使用され
るものを指定するところ:
レイヤ 2 ヘッダフィールド 利用可能なとき。
IPv4 と IPv6 プロトコル SCTP, TCP, UDP, ICMP など。
発信元と宛先、アドレスとポート
方向 セクション「パケットフロー」を参
照してください。
送信と受信インタフェース 名前またはアドレスによって。
雑多、IP ヘッダフィールド バージョン、サービスタイプ、デー
タグラム長さ、識別子、フラグメン
テーションのフラグ、有効期間。
IP オプション
IPv6 拡張ヘッダ フラグメンテーション、中継点ごと
(Hop-by-Hop) のオプション、経路
制御ヘッダ、発信元経路制御
rthdr0、モバイル IPv6 rthdr2、
IPSec オプション。
IPv6 フロー ID
雑多、TCP ヘッダフィールド TCP フラグ (SYN, FIN, ACK, RST
など)、シーケンス番号、確認応答
番号、ウィンドウ。
TCP オプション
ICMP タイプ ICMP パケットのために。
ICMP6 タイプ ICMP6 パケットのために。
ユーザ/グループ ID ローカルソケットとパケットを関連
付けることができるとき。
divert 状態 パケットが divert ソケットから来
たかどうか (例えば、natd(8))。
Fib annotation state パケットが、将来の決定を進める特
定の FIB (経路表) を使用してタグ
付けをされるかどうか。
上記の情報のいくつか (例えば、発信元 MAC または IP アドレスと TCP/UDP
ポート) を容易に偽造することができるので、それらのフィールドだけのフィル
タリングは、望み通りの成果を保証できないことに注意してください。
rule_number
各規則は、default 規則のために予約された後者で、範囲 1..65535 の
rule_number と関連づけられています。規則は、規則番号によって連続
してチェックされます。複数の規則は、同じ番号を持つことができ、そ
の場合に、それらは、追加された順序にしたがってチェックされます
(そして、リストされます)。規則が指定している数値なしで入力される
なら、カーネルは、規則が default の規則の前の最後のものになる、そ
のような方法で 1 つを割り当てます。自動的な規則番号は、デフォルト
が 100 である、sysctl 変数 net.inet.ip.fw.autoinc_step の値によっ
て最後のデフォルトでない規則番号を増加することによって割り当てら
れます。これが可能でないなら (例えば、許可された規則番号の最大を
越えるので)、最後のデフォルトでない値は、代わりに使用されます。
set set_number
各規則は、範囲 0..31 の set_number に関連づけられています。セット
番号は、個別に無効にされ、有効にすることができるので、このパラ
メータは、不可分に ruleset 操作するために基本に重要です。また、規
則のグループの削除を単純化するために使用することができます。規則
が設定された数を指定せずに入力されるなら、セット番号 0 が使用され
ます。
セット番号 31 は、無効にすることができないという点で、特別です、
ipfw flush コマンドによって (しかし、利用者は、ipfw delete set 31
コマンドでそれらを削除することができます) セット番号 31 の規則
は、削除されません。また、セット番号 31 は、default 規則のために
使用されます。
prob match_probability
照合は、指定された確立でのみ宣言されます (0 と 1 の間の浮動小数点
数)。これは、ランダムなパケットの落下のような多くのアプリケーショ
ンか、または (dummynet とともに) 規則に反するパケットの配信にを引
き起こす、複数の経路の効果をシミュレーションに役に立つことができ
ます。
注: この条件は、副作用があるかもしれない keep-state または check-
state などのものを含んでいる、あらゆる他の条件の前にチェックされ
ます。
log [logamount number]
log キーワードに規則を照合するパケットは、2 つの方法でログ記録す
るために利用可能にします。sysctl 変数 net.inet.ip.fw.verbose が 0
(デフォルト) に設定されるなら、ipfw0 疑似インタフェースにアタッチ
された bpf(4) を使用することができます。次のコマンドを使用するこ
とによってシステムブートの後に手動でこの疑似インタフェースを作成
することができます:
# ifconfig ipfw0 create
または、rc.conf(5) ファイルに次の行を追加することによってブート時
に自動的に、この疑似インタフェースを作成することができます:
firewall_logif="YES"
bpf(4) が疑似インタフェースにアタッチされていないなら、オーバヘッ
ドは、0 です。
net.inet.ip.fw.verbose が 1 に設定されるなら、パケットは、最大
logamount パケットまで LOG_SECURITY 機能がある syslogd(8) にログ
記録されます。logamount が指定されていなければ、制限は、sysctl 変
数 net.inet.ip.fw.verbose_limit から参照されます。どちらの場合
も、0 の値は、制限のないログ記録を意味します。
いったん制限に到達すると、ログ記録は、そのエントリのためのログ記
録カウンタまたはパケットのカウンタをクリアすることによって再び有
効にすることができます、resetlog コマンドを参照してください。
注: ログ記録は、すべての他のパケット整合条件が成功して検証された
後に、そしてパケットで最後のアクション (受け付け、拒否など) を実
行する前に、行われます。
tag number
パケットが tag キーワードで規則と適合するとき、与えれた範囲 1 か
ら 65534 の number の数値タグは、パケットにアタッチされます。タグ
は、後でこれらのパケットを識別するために使用することができる内部
のマーカ (ケーブルを越えて外部に送信されない) の役割を果たしま
す。例えば、インタフェース間に信頼を提供し、ポリシベースのフィル
タリングを開始するために、使用することができます。パケットは、同
時に複数のタグを持つことができます。タグは、"スティッキ" です、こ
れは、いったんタグが適合する規則によってパケットに適用されると明
示的な削除まで存在することを意味します。タグは、カーネル内のいず
れの場所でもパケットで保持されますが、例えば、パケットをネット
ワークに転送するとき、またはパケットを divert(4) ソケットへ送信す
るときのように、パケットがカーネルから出るとき、タグは、失われま
す。
以前に適用されたタグをチェックするために、tagged (タグを付けされ
た) 規則オプションを使用します。以前に適用されたタグを削除するた
めに、untag (タグ付け解除) キーワードを使用します。
注: タグは、カーネル空間のいずれの場所でもパケットで保持されるの
で、単に、ipfw(4) tag と untag キーワードを用いるだけでなく、
(mbuf_tags(9) 機能を使用して) カーネルネットワークサブシステムの
どこでもそれらを設定して設定解除することができます。例えば、ファ
イアウォールでの検査の後のために、トラフィック分析とタグを付けを
行なう専門的な netgraph(4) ノードがあり得ます。
untag number
パケットが untag キーワードで規則に適合するとき、番号 number のタ
グは、このパケットにアタッチされたタグの中で検索され、見つかった
なら、タグを削除します。存在しているなら、他のタグがパケットにバ
インドされ、そのまま残されます。
altq queue
パケットが altq キーワードで規則と適合するとき、与えられた queue
(altq(4) 参照) のための ALTQ 識別子は、アタッチされます。この
ALTQ タグは、IPFW から送出される ("out") パケットのためだけに意
味があり、拒否されたり、divert ソケットに行くパケットには、意味が
ないことに注意してください。パケットが処理される時点で十分なメモ
リがないなら、タグ付けをされないので、これのために利用者の ALTQ "
デフォルト" キューポリシアカウントを作成することは賢明であること
に注意してください。複数の altq 規則が単一のパケットに適合するな
ら、最初のものだけに ALTQ 分類タグを追加します。そうすることで、
トラフィックは、規則セットの初期の分類のために count altq queue
規則を使用して形成され、その後にフィルタリング判定を適用します。
例えば、check-state と keep-state 規則は、後で来る、フォールバッ
ク ALTQ タグに加えて実際のフィルタリングの判定を提供します。
利用者は、IPFW が名前によってそれらを検索することができる前に、
キューを設定するために、pfctl(8) を実行しなければなりません、ALTQ
制御規則 (discipline) が、再調整されるなら、カーネルのキュー識別
子を含んでいる規則は、おそらく古くなり、再ロードされる必要があり
ます。古いキュー識別子は、たぶん、分類の誤りの結果となります。
すべてのシステム ALTQ 処理は、ipfw enable altq と ipfw disable
altq によってオンまたはオフに切り替えることができます。
net.inet.ip.fw.one_pass の使用法は、ALTQ タグを追加した後に常に実
際の規則アクションが続いているので、ALTQ トラフィック形成 (shap
ing) と無関係です。
規則アクション
パケットが規則の本体と一致しているとき、実行される、次のアクションの 1 つ
に規則を関連付けることができます。
allow | accept | pass | permit
規則と一致しているパケットを許可します。検索は、終了します。
check-state [:flowname | :any]
動的な規則セットに対してパケットをチェックします。一致が見つけら
れるなら、この動的な規則を生成した規則と関連するアクションを実行
します、そうでなければ、次の規則に移ります。
check-state 規則には、本体がありません。check-state 規則が見つけ
られないなら、動的な規則セットは、最初の keep-state たは limit
(制限) 規則でチェックされます。:flowname は、keep-state オペコー
ドによって動的規則に割り当てられたシンボリック名です。一致してい
るとき、状態を無視するために、特別な flowname :any を使用すること
ができます。:default キーワードは、古い規則セット (ruleset) との
互換性のために使用される特別な名前です。
count 規則と一致しているすべてのパケットのためのカウンタを更新します。
検索は、次の規則で続行されます。
deny | drop
この規則と一致しているパケットを破棄します。検索は、終了します。
divert port
ポート port にバインドされる divert(4) ソケットへのこの規則と一致
しているパケットを迂回します。検索は、終了します。
fwd | forward ipaddr | tablearg[,port]
一致しているパケットで次の中継点を、IP アドレスまたはホスト名であ
るかもしれない、ipaddr に変更します。また、明示的なアドレスの代わ
りに tablearg キーワードを使用することによってパケットを検索する
最後のテーブルによって、次の中継点を供給することができます。この
規則に一致するなら、検索は、終わります。
ipaddr がローカルなアドレスであるなら、一致しているパケットは、
ローカルマシンの port (または、規則で指定されないなら、パケットの
ポート番号) に転送されます。
ipaddr がローカルアドレスではないなら、(指定されるなら) ポート番
号は、無視され、パケットは、その IP のためのローカルな経路表で見
つかるような経路を使用して、リモートのアドレスに転送されます。
fwd 規則は、レイヤ 2 パケット (それらは、ether_input, ether_out
put または bridged で受信されます) と一致しません。
fwd アクションは、パケットの内容をまったく変更しません。特に、宛
先アドレスは、変更されないままとなるので、別のシステムに転送され
たパケットは、それらを捕らえるために、そのシステムで一致している
規則がないなら、通常、そのシステムによって拒否されます。ローカル
に転送されたパケットのために、ソケットのローカルアドレスは、パ
ケットのオリジナルの宛先アドレスに設定されます。これは、
netstat(1) エントリをどちらかといえば奇妙と見えるようにしますが、
透過的なプロキシサーバでの使用を対象としています。
nat nat_nr | tablearg
(ネットワークアドレス変換、アドレスリダイレクション、その他のため
に) パケットを nat インスタンスに渡します: さらなる詳細について
は、「ネットワークアドレス変換 (NETWORK ADDRESS TRANSLATION
(NAT))」セクションを参照してください。
nat64lsn name
(IPv6/IPv4 ネットワークアドレスとプロトコル変換のために) パケット
をステートフル NAT64 インスタンスに渡します: さらなる詳細について
は、「IPv6/IPv4 ネットワークアドレスとプロトコル変換」セクション
を参照してください。
nat64stl name
パケットをステートレスの NAT64 インスタンスを渡します (IPv6/IPv4
ネットワークアドレスとプロトコル変換のために): さらなる詳細につい
ては、「IPv6/IPv4 ネットワークアドレスとプロトコル変換」セクショ
ンを参照してください。
nat64clat name
パケットを CLAT NAT64 インスタンスに渡します (クライアント側の
IPv6/IPv4 ネットワークアドレスとプロトコル変換のために): さらなる
詳細については、「IPv6/IPv4 ネットワークアドレスとプロトコル変
換」セクションを参照してください。
nptv6 name
(IPv6 から IPv6 ネットワーク接頭辞変換のために) パケットを NPTv6
インスタンスに渡します: 詳細については、「IPv6 から IPv6 ネット
ワーク接頭辞変換 (NPTv6)」セクションを参照してください。
pipe pipe_nr
パケットを dummynet ``pipe'' (パイプ) に渡します (帯域幅の制限、
遅延、等のために)。さらなる詳細について、「トラフィックシェイパ
(DUMMYNET) の設定」セクションを参照してください。検索は、終了しま
す。しかしながら、パイプから終了するとき、sysctl(8) 変数
net.inet.ip.fw.one_pass が設定されないなら、パケットは、再び、次
の規則から始まるファイアウォールのコードに渡されます。
queue queue_nr
パケットを dummynet ``queue'' (キュー) に渡します (WF2Q+ を使用す
る帯域幅制限のために)。
reject (非推奨)。unreach host と同義語。
reset この規則と一致しているパケットを破棄し、パケットが TCP パケットで
あるなら、TCP リセット (RST) 通知を送信しようと試みます。検索は、
終了します。
reset6 この規則と一致しているパケットを下記し、パケットが TCP パケットで
あるなら、TCP リセット (RST) 通知を送信することを試みます。検索
は、終了します。
skipto number | tablearg
number より少なく番号を付けられるすべてのその後の規則をスキップし
ます。番号が付けられた number 以上の最初の規則で検索は、続きま
す。計算された skipto のために skipto がある tablearg キーワード
を使用することができます。skipto は、メモリの量および sysctl 変数
に依存する O(log(N)) またま O(1) のいずれかで動作します。より詳し
い情報については、「SYSCTL 変数」セクションを参照してください。
call number | tablearg
現在の規則番号は、内部スタックに保存され、規則セット処理は、
number 以上に番号付けされた最初の規則で継続します。return アク
ションがある後の規則に遭遇するなら、処理は、この call 規則と 1 以
上の数で最初の規則に戻ります (divert アクションの後で divert(4)
ソケットから戻るパケットのような同じ振る舞い)。これは、アセンブリ
言語 ``subroutine'' 呼び出しにやや似た、異なったインタフェースな
どの共通のチェックで規則付けを行うために使用されます。
任意の数がある規則は、skipto のように前方にただジャンプするのでは
なく、呼び出されます。それで、誤りの場合の永久ループを防ぐため
に、call と return アクションの両方は、メモリが割り付けできない
か、またはスタックがオーバフローするかアンダフローするなら、どん
なジャンプも行われず、単に次の規則に行きます。
内部的に、規則番号のためのスタックは、mbuf_tags(9) 機能を使用して
実装され、現在、16 エントリのサイズがあります。mbuf タグがパケッ
トがカーネルから出るとき、失われるように、divert は、永久ループと
他の望ましくない影響を避けるためにサブルーチンで使用されるべきで
はありません。
return 最後の call アクションによって内部のスタックに保存された規則番号
を取り、対応する call 規則の数より大きい数がある最初の規則に規則
セット処理を返します。その他の詳細については、call アクションの説
明を参照してください。
return 規則は、通常、``subroutine'' を終わらせて、その結果、無条
件ですが、ipfw コマンドラインユーティリティは、現在本体を所有する
ために check-state 以外のあらゆるアクションを必要とすることに注意
してください。いくつかのパケットでのみ戻るために時々役に立ちます
が、通常、読み易さのために単に ``return'' を印刷することを必要と
します。この回避方法は、次のように新しい構文と -c スイッチを使用
することです:
# 実際の本体なしで規則を追加します
ipfw add 2999 return via any
# "from any to any" 部分なしで規則をリストします
ipfw -c list
この表面的な問題は、将来のリリースで修正されるかもしれません。
tee port
この規則に一致するパケットのコピーを、ポート port にバインドされ
た divert(4) ソケットに送信します。検索は、次の規則を継続します。
unreach code
この規則と一致するパケットを廃棄し、コード code で ICMP 到達不可
能な通知を送信することを試みます、ここで、code は、0 から 255 ま
での数値、または、次の別名の 1 つです: net, host, protocol, port,
needfrag, srcfail, net-unknown, host-unknown, isolated, net-
prohib, host-prohib, tosnet, toshost, filter-prohib, host-
precedence または precedence-cutoff。検索は、終了します。
unreach6 code
この規則に一致するパケットを破棄し、コード code で ICMPv6 到達不
可能な通知を送信することを試みます、ここで、code は、0, 1, 3 また
は 4 の数値、または、次の別名の 1 つです: no-route, admin-prohib,
address または port。検索は、終了します。
netgraph cookie
与えられた cookie で netgraph にパケットを転送します。検索は、終
了します。パケットが後で netgraph から返されるなら、
net.inet.ip.fw.one_pass sysctl 変数によって、次の規則を受け付ける
か、または継続します。
ngtee cookie
パケットのコピーは、netgraph に、転送され、オリジナルのパケット
は、次の規則で継続します。netgraph と ngtee アクションの詳細につ
いては、ng_ipfw(4) を参照してください。
setfib fibnum | tablearg
パケットは、その後の決定を進める FIB (ルーティングテーブル, 経路
表) fibnum を使用するためにタグ付けをされます。現在の実装は、これ
は、値 0 から 15 に制限されます、setfib(2) を参照してください。処
理は、次の規則を続行します。setfib がある tablearg キーワードを使
用することは可能です。tablearg 値がコンパイルされた fib の範囲内
でないなら、パケットの fib な、0 に設定されます。
setdscp DSCP | number | tablearg
IPv4/IPv6 パケットのための指定された DiffServ codepoint を設定し
ます。処理は、次の規則で継続します。サポートされている値は、次の
通りです:
cs0 (000000), cs1 (001000), cs2 (010000), cs3 (011000), cs4
(100000), cs5 (101000), cs6 (110000), cs7 (111000), af11
(001010), af12 (001100), af13 (001110), af21 (010010), af22
(010100), af23 (010110), af31 (011010), af32 (011100), af33
(011110), af41 (100010), af42 (100100), af43 (100110), ef
(101110), be (000000)。さらに、数値 (0..63) によって DSCP 値を指
定することができます。また、setdscp がある tablearg キーワードを
使用することができます。tablearg 値が 0..63 の範囲内にないなら、
供給された下位 6 ビットが使用されます。
tcp-setmss mss
TCP セグメントの最大セグメントサイズ (Maximum Segment Size; MSS)
を値 mss に設定します。カーネルモジュール ipfw_pmod は、ロードさ
れるべきか、または、カーネルは、このアクションを使用することかで
きる options IPFIREWALL_PMOD があるべきです。このコマンドは、オリ
ジナルの MSS 値が指定された値より小さいなら、パケットを変更しませ
ん。TCP オーバ IPv4 と TCP オーバ IPv6 の両方がサポートされていま
す。一致しているパケットにかかわらず、または tcp-setmss 規則に
よってではなく、検索は、次の規則を続行します。
reass IPv4 フラグメントをキューに入れて、再構築します。パケットがフラグ
メント化されていないなら、カウンタは、更新され、処理は、次の規則
で続行します。パケットが最後の論理的なフラグメントであるなら、パ
ケットは、再構築され、net.inet.ip.fw.one_pass が 0 に設定されてい
るなら、処理は、次の規則で続行します。そうでなければ、パケット
は、渡すことが許可され、検索は、終了します。パケットがフラグメン
トの論理グループの中間のフラグメントであるなら、それは、消費さ
れ、処理は、直ちに停止します。
net.inet.ip.maxfragpackets と net.inet.ip.maxfragsperpacket を通
して、それぞれ、処理できるフラグメントの最大数 (デフォルト: 800)
とパケット毎のフラグメントの最大数 (デフォルト: 16) を制限する、
フラグメントの取り扱いを調整することができます。
注意: フラグメントがポート番号をを含んでいないので、それらを、
reass 規則で避けるべきです。もう一つの方法として、(in / out のよ
うな) 方向ベース (direction-based) と (via (経由) のような) ソー
スベース (source-based) の照合パターンは、フラグメントを選択する
ために使用することができます。
通常、次のような簡単な規則です:
# 着信フラグメントを再構築する
ipfw add reass all from any to any in
は、すべて、規則セットの始めに必要とします。
abort この規則と一致しているパケットを破棄します、パケットが SCTP パ
ケットであるなら、ABORT チャンクを含んでいる SCTP パケットを送信
することを試みます。検索は、終わます。
abort6 この規則と一致しているパケットを破棄します、パケットが SCTP パ
ケットであるなら、ABORT チャンクを含んでいる SCTP パケットを送信
することを試みます。検索は、終わます。
規則本体
規則の本体は、パケットが認識されるために一致しなければならない 0 個以上の
(特定の発信元、宛先アドレスまたはポート、プロトコルオプション、着信または
発信インタフェースなどのような) パターンを含んでいます。一般的に、パター
ンは、(暗黙で) and 演算子によって接続されます -- すなわち、一致する規則に
対してすべてが一致しなければなりません。個別のパターンは、次のように、一
致の結果を反転する not 演算子を前に付けることができます。
ipfw add 100 allow ip from not 1.2.3.4 to any
さらに、代替の照合パターン (またはブロック) の組は、括弧 () または大括弧
{ } の間で囲まれたリストにパターンを置き、次のような or 演算子を使用して
構築することができます:
ipfw add 100 allow ip from { x or not y or z } to any
括弧の 1 つのレベルだけが許可されます。ほとんどのシェルが、括弧または大括
弧に対して特別な意味があるので、そのような解釈を防止するために、それらの
前にバックスラッシュ \ を置くことが賢明であることに注意してください。
規則の本体は、一般的に発信元と宛先アドレスの指定子を含まなければなりませ
ん。必要なフィールドの内容が重要でないことを指定するために様々な場所で
キーワード any を使用することができます。
規則の本体は、次の形式があります:
[proto from src to dst] [options]
最初の部分 (proto from src to dst) は、FreeBSD の初期のバージョンとの後方
互換性のためです。最近の FreeBSD で、options セクションで、(MAC ヘッダ、
IP プロトコル、アドレスとポートを含んで) あらゆる照合パターンを指定するこ
とができます。
規則フィールドには、次の意味があります:
proto: protocol | { protocol or ... }
protocol: [not] protocol-name | protocol-number
数値または名前 (完全なリストについては、/etc/protocols を参照) に
よって指定された IP プロトコル、または次のキーワードの 1 つ:
ip4 | ipv4
IPv4 パケットに適合する。
ip6 | ipv6
IPv6 パケットに適合する。
ip | all
あらゆるパケットに適合する。
proto オプションの ipv6 は、内部のプロトコルとして扱われます。そ
して、ipv4 は、proto オプションで利用可能ではありません。
{ protocol or ... } 形式 (論理和 (OR) ブロック) は、便利さのため
だけに提供されていますが、その使用は、推奨されません。
src and dst: {addr | { addr or ... }} [[not] ports]
アドレス (またはリスト、下記を参照) は、オプションで ports 指定子
が続きます。
2 番目の形式 (複数のアドレスがある論理和 (OR) ブロック) は、便利
さのためだけに提供され、その使用は、抑制されています。
addr: [not] {any | me | me6 | table(name[,value]) | addr-list | addr-set}
any あらゆる IP アドレスと照合します。
me システムのインタフェースで設定されたあらゆる IP アドレス
と照合します。
me6 システムのインタフェースで設定されたあらゆる IPv6 アドレ
スと照合します。アドレスリストは、パケットが解析されるよ
きに評価されます。
table(name[,value])
検索テーブル number に存在するエントリのためのあらゆる
IPv4 または IPv6 アドレスに適合します。オプションの 32
ビット符号なし整数 value も指定されるなら、エントリは、そ
の値がある場合のみ一致します。検索テーブルに関する詳細に
ついては、下記の「検索テーブル」セクションを参照してくだ
さい。
addr-list: ip-addr[,addr-list]
ip-addr:
次の方法の 1 つで指定されたホストまたはサブネットのアドレス:
numeric-ip | hostname
ドット付き 4 つ組またはホスト名として指定される、単一の
IPv4 アドレスを照合します。ホスト名は、規則がファイア
ウォールリストに追加される時点で解決されます。
addr/masklen
(IP アドレス、ネットワーク番号、またはホスト名として指定
される) 基本の addr と masklen ビットの幅でマスクされる、
すべてのアドレスと照合します。例として、1.2.3.4/25 または
1.2.3.0/25 は、すべての IP 番号 1.2.3.0 から 1.2.3.127 ま
でと一致します。
addr:mask
(IP アドレス、ネットワーク番号、またはホスト名として指定
される) 基本の addr とドット付き 4 つ組として指定される
mask のマスクとすべてのアドレスと照合します。例として、
.2.3.4:255.0.255.0 または 1.0.3.0:255.0.255.0 は、1.*.3.*
と一致します。この形式は、連続していないマスクのためだけ
に推奨されます。それは、よりコンパクトで、間違えを起こし
にくい連続しているマスクのための addr/masklen 形式を使用
するのに良いことです。
addr-set: addr[/masklen]{list}
list: {num | num-num}[,list]
(IP アドレス、ネットワーク番号、またはホスト名として指定される)
基本の addr と最後のバイトが大括弧 { } の間のリストにある、すべて
のアドレスを照合します。大括弧と数値の間に空白があってはならない
(コンマの後の空白は、許されます) ことに注意してください単一のエン
トリまたは範囲としてリストの要素を指定することができます。masklen
フィールドは、一連のアドレスのサイズを制限するために使用され、24
から 32 までのあらゆる値を指定することができます。指定されないな
ら、24 と仮定されます。
この形式は、単一の規則内でまばらアドレスの組みを扱うために特に、
役に立ちます。照合は、ビットマスクを使用して生じるので、それは、
一定の時間かかり、規則セット (ruleset) の複雑さを劇的に減少しま
す。
例として、1.2.3.4/24{128,35-55,89} または
1.2.3.0/24{128,35-55,89} として指定されるアドレスは、次の IP アド
レスと照合します:
1.2.3.128, 1.2.3.35 から 1.2.3.55, 1.2.3.89。
addr6-list: ip6-addr[,addr6-list]
ip6-addr:
ホストまたはサブネットは、次の方法の 1 つを指定します:
numeric-ip | hostname
inet_pton(3) またはホスト名によって許可されるような単一の
IPv6 アドレスを照合します。ホスト名は、規則がファイア
ウォールリストに追加される時点で解決されます。
addr/masklen
(inet_pton(3) またはホスト名によって許可されるように指定
される) 基本の addr と masklen ビットの幅をマスクするすべ
ての IPv6 アドレスを照合します。
addr/mask
(inet_pton またはホスト名によって許可されるように指定され
る) 基本の addr があるすべての IPv6 アドレスと
inet_pton(3) によって許可されるように指定される mask のマ
スクと照合します。例として、
fe::640:0:0/ffff::ffff:ffff:0:0 は、fe:*:*:*:0:640:*:* と
一致します。この形式は、隣接していないマスクのためだけに
勧められます。それは、よりコンパクトで、間違えを起こしに
くい、隣接しているマスクのための addr/masklen 形式に頼る
のがより良いことです。
IPv6 アドレスは、通常、最初の接頭辞を通り過ぎるとランダムであるの
で、IPv6 アドレスのセットのためのサポートは、提供されません。
ports: {port | port-port}[,ports]
(SCTP、TCP、UDP のような) ポート番号をサポートするプロトコルにつ
いて、オプションの ports は、コンマによって区切られた 1 つ以上の
ポートまたはポートの範囲として指定されますが、空白とオプションの
not 演算子なしです。`-' 表記法は、(境界を含んで) ポートの範囲を指
定します。
/etc/services) からの) サービス名は、数値のポート値の代わりに使用
されます。ポートリストの長さは、30 ポートまたは範囲に制限されます
が、規則の options セクションで or-block (論理和 (OR) ブロック)
を使用することによってより大きな範囲を指定することができます。
サービス名のダッシュ (`-') 文字をエスケープするために、バックス
ラッシュ (`\') を使用することができます (シェルで、バックスラッ
シュは、シェル自体がそれをエスケープ文字と解釈していることを避け
るために、2 つタイプされなければなりません)。
ipfw add count tcp from any ftp\\-data-ftp to any
0 でないオフセットがある、断片化された (すなわち、最初の破片でな
い) パケットは、1 つ以上のポート指定がある規則と決して一致しませ
ん。断片化されたパケットとの照合に関する詳細については、frag オプ
ションを参照してください。
規則オプション (照合パターン)
規則内で追加の照合パターンを使用することができます。規則で、これらのいわ
ゆる options の 0 以上を存在することができ、オプションで、not オペランド
が前置され、可能であれば、論理和 (OR) ブロックにグループ化されます。
次の照合パターンを使用することができます (アルファベット順にリストされま
す):
// this is a comment.
規則のコメントとしての指定されたテキストを挿入します。// に続くす
べては、コメントと見なされ、規則に格納されます。利用者は、コメン
トが続いている count アクションがあるようにリストされる、コメント
のみの規則があります。
bridged
layer2 のための別名 (エイリアス)。
defer-immediate-action | defer-action
このオプションがある規則は、照合での通常のアクションを実行しませ
ん。このオプションは、動的な規則として record-state または keep-
state で使用することを意図され、作成されますが、照合で無視され、
目的通りに動作します。record-state と defer-immediate-action の両
方がある規則は、動的な規則を作成し、実際にこの規則のアクション部
分を実行せずに次の規則を続行します。規則が状態テーブルを通して後
で活性化されるとき、アクションは、いつものように実行されます。
diverted
divert ソケットによって生成されたパケットのみを照合します。
diverted-loopback
配信のための IP 入力スタックに戻る、divert ソケットから着信してく
るパケットのみを照合します。
diverted-output
配信のための IP スタックの外側に戻る divert ソケットから発信して
いるパケットのみを照合します。
dst-ip ip-address
宛先 IP が引数として指定された (複数の) アドレスの 1 つである
IPv4 パケットと照合します。
{dst-ip6 | dst-ipv6} ip6-address
宛先 IP が引数として指定された (複数の) アドレスの 1 つである
IPv6 パケットと照合します。
dst-port ports
宛先ポートが引数として指定された (複数の) ポートの 1 つである IP
パケットと照合します。
established
設定された RST または ACK ビットがある TCP パケットと照合します。
ext6hdr header
header によって与えられた拡張されたヘッダを含んでいる IPv6 パケッ
トと照合します。サポートされたヘッダは、次の通りです:
フラグメント (frag), Hop-to-hop オプション (hopopt), あらゆるタイ
プの経路制御ヘッダ (route), 指定経路制御経路制御ヘッダタイプ 0
(rthdr0), モバイル IPv6 経路制御ヘッダタイプ 2 (rthdr2), 宛先オプ
ション (dstopt), IPSec 認証ヘッダ (ah) と IPsec カプセル化セキュ
リティペイロードヘッダ (esp)。
fib fibnum
与えられた FIB (経路表) 番号を使用するタグ付けされたパケットを照
合します。
flow table(name[,value])
検索テーブル name の flow エントリを検索します。見つからないな
ら、適合は、失敗します。そうでなければ、適合は、成功し、tablearg
は、テーブルから抽出された値に設定されます。
このオプションは、特定のパケットフィールドに基づいたトラフィック
をす速くディスパッチするために役に立てることができます。検索テー
ブルに関する詳細については、下記の「検索テーブル」セクションを参
照してください。
flow-id labels
labels で与えられたフローラベルのいずれかを含んでいる IPv6 パケッ
トを照合します。labels は、数値のフローラベルのコンマで区切られた
リストです。
frag IP データグラムの最初のフラグメントではなく、フラグメントであるパ
ケットを照合します。これらのパケットには、次のプロトコルヘッダ
(例えば、TCP、UDP) がないので、これらのヘッダを検証するオプション
は、一致できないことに注意してください。
frag spec
ip_off フィールドが spec で指定された IPv4 フラグメンテーションオ
プションのコンマで区切られたリストが含まれている IPv4 パケットに
一致します。認識できるオプションは、次の通りです: df (フラグメン
ト化しない) mf (多くのフラグメント), rf (予約されたフラグメント
ビット) offset (0 ではないフラグメントのオフセット)。特定のオプ
ションがないことは、`!' で示されます。
空のオプションのリストは、デフォルトで、0 ではないフラグメントの
オフセットに一致します。そのような規則は、IPv4 と IPv6 の両方で、
最初のフラグメントのデータグラムではないすべてのデータグラムに一
致します。これは、古い規則セットとの後方互換性です。
gid group
group のために送信されるか、または受信されるすべての TCP または
UDP パケットを照合します。group は、名前または数値によって指定さ
れます。
jail jail
ID または名前が jail である、jail のために送信されるか、または受
信されるすべての TCP または UDP パケットと照合します。
icmptypes types
ICMP タイプがリスト types である ICMP パケットを照合します。リス
トは、コンマで区切られた個別のタイプ (数字) のあらゆる組み合わせ
として指定されます。範囲は、許されません。サポートされる ICMP タ
イプは、次の通りです:
エコー応答 (0), 宛先到達不能 (3), 送信元抑制 (4), リダイレクト
(5), エコー要求 (8), ルータ通知 (9), ルータ要請 (10), 有効期限超
過 (11), IP ヘッダ不正 (12), タイムスタンプ要求 (13), タイムスタ
ンプ応答 (14), 情報要求 (15), 情報応答 (16), アドレスマスク要求
(17) とアドレスマスク応答 (18)。
icmp6types types
ICMP6 タイプが types のリストにある ICMP6 パケットを照合します。
リストは、コンマによって区切られた個別のタイプ (数値) のあらゆる
組み合わせとして指定されます。範囲は、許可されません。
in | out
それぞれ着信してくるか、または発信するパケットを照合します。in と
out は、相互排他的です (実際に、out は、not in として実装されま
す)。
ipid id-list
ip_id フィールドは、単一の値、または ports と同じ方法で指定された
値または範囲のリストのいずれかである、id-list に含められている値
がある IPv4 パケットを照合します。
iplen len-list
ヘッダとデータを含んでいる、合計の長さは、単一の値、または ports
と同じ方法で指定された値または範囲のリストのいずれかである、集合
len-list にある、IP パケットを照合します。
ipoptions spec
IPv4 ヘッダが spec で指定されたオプションのコンマで区切られたリス
トを含んでいるパケットを照合します。サポートされる IP オプション
は、次の通りです:
ssrr (strict source route; 厳密な発信元経路)、lsrr (loose source
route; ゆるい発信元経路)、rr (record packet route; レコードパケッ
ト経路) と ts (timestamp; タイムスタンプ)。特定のオプションが存在
しないことは、`!' で示されます。
ipprecedence precedence
先行フィールドが precedence と等しい IPv4 パケットを照合します。
ipsec それらに関連する IPSEC ヒストリがあるパケットを照合します。(すな
わち、パケットは、IPSEC でカプセル化され、カーネルは、IPSEC サ
ポートがあり、それを正しくカプセル化を解除することができます)。
ipsec を指定することは、後者として proto ipsec を指定することが、
IPSEC カーネルサポートと IPSEC データの有効性に関係なく、特有の
IP プロトコルフィールドでのみ調べることと異なることに注意してくだ
さい。
さらに、このフラグは、IPSEC サポートなしのカーネルで静かに無視さ
れることに注意してください。それは、与えられるとき処理している規
則に影響せず、規則は、あたかも ipsec フラグなしのように処理されま
す。
iptos spec
tos フィールドが spec で指定されるサービスタイプのコンマで区切ら
れたリストを含んでいる IPv4 パケットを照合します。サービスのサ
ポートされる IP タイプは、次の通りです:
lowdelay (IPTOS_LOWDELAY), throughput (IPTOS_THROUGHPUT),
reliability (IPTOS_RELIABILITY), mincost (IPTOS_MINCOST),
congestion (IPTOS_ECN_CE)。特別のタイプが存在しないことは、`!' と
表示されます。
dscp spec[,spec]
DS フィールド値が spec マスクに含まれている IPv4/IPv6 パケットに
一致します。コンマで区切られたリストによって複数の値を指定するこ
とができます。値は、setdscp アクションまたは正確な数で使用される
キーワードの 1 つを指定できます。
ipttl ttl-list
有効期間が、単一の値、または ports と同じ方法で指定された値のリス
トまたは範囲のいずれかである、ttl-list に含まれる IPv4 パケットを
照合します。
ipversion ver
IP バージョンフィールドが ver である IP パケットを照合します。
keep-state [:flowname]
照合するとき、ファイアウォールは、デフォルトの振る舞いが、同じプ
ロトコルを使用して、発信元と宛先の IP/ポートの間の双方向のトラ
フィックと照合するための動的な規則を作成します。規則は、
(sysctl(8) 変数のセットによって制御される) 制限された存続期間があ
り、存続期間は、一致しているパケットが見つけられるたびに、リフ
レッシュされます。:flowname は、追加するアドレス、ポートとプロト
コルパラメータを動的規則に割り当てるために使用されます。それは、
check-state 規則によってより正確な一致のために使用することができ
ます。:default キーワードは、古い規則セット (ruleset) との互換性
のために使用される特別な名前です。
layer2 layer2 のパケット、すなわち、それらは、ether_demux() と
ether_output_frame() から ipfw に渡される layer2 のパケットのみを
照合します。
limit {src-addr | src-port | dst-addr | dst-port} N [:flowname]
ファイアウォールは、規則で指定されようにパラメータの同じセットと
N の接続のみを許可します。1 つ以上の発信元と宛先アドレスとポート
を指定することができます。
lookup {dst-ip | dst-port | src-ip | src-port | uid | jail} name
引数として指定されたフィールドと照合する検索テーブル name のエン
トリを検索します。見つからないなら、照合は、失敗します。そうでな
ければ、照合は、成功し、tablearg は、テーブルから抽出された値に設
定されます。
特定のパケットフィールドに基づいてトラフィックを迅速にディスパッ
チするために、このオプションを役に立てることができます。検索テー
ブルに関する詳細については、下記の「検索テーブル」セクションを参
照してください。
{ MAC | mac } dst-mac src-mac
(あらゆる MAC アドレスに一致している) any キーワードとして指定さ
れるか、またはコロンによって区切られた 16 進数の 6 つのグループ、
と最上位のビットを示すマスクがオプションで続いている、与えられた
dst-mac と src-mac アドレスがあるパケットを一致する照合します。マ
スクは、次の方法のいずれかを使用して指定されます:
1. 有効なビットの数が後続するスラッシュ (/)。例えば、33 の有
効なビットあるアドレスは、次のように指定されます:
MAC 10:20:30:40:50:60/33 any
2. コロンによって区切られた 16 進数の 6 つのグループとして指
定されたビットマスクが後続するアンパサンド (&)。例えば、
最後の 16 ビットが有効なアドレスは、次のように指定されま
す:
MAC 10:20:30:40:50:60&00:00:00:00:ff:ff any
アンパサンド文字は、多くのシェルで特別の意味があり、一般
的にエスケープされるべきであることに注意してください。
MAC アドレス (宛先は、最初、発信元は、2 番目) の順序は、接続され
たものと同じですが、 IP アドレスのために使用されるものと反対であ
ることに注意してください。
mac-type mac-type
イーサネットタイプのフィールドは、引数として指定されたそれらの 1
つに対応しているパケットを照合します。mac-type は、port numbers
(ポート番号) と同じ方法で指定されます (すなわち、1 つ以上のコンマ
で区切られた単一の値または範囲)。利用者は、vlan, ipv4, ipv6 のよ
うな既知の値のためのシンボリックな名前を使用することができます。
10 進数または (0x を前に付けられるなら) 16 進数として値を入力する
ことができ、(-N オプションが使用され、その場合に、シンボリックな
解決が試みられないなら) それらは、常に 16 進数として印刷 (表示)
されます。
proto protocol
対応する IP プロトコルがあるパケットを照合します。
record-state
照合で、ファイアウォールは、あたかも keep-state が指定されたかの
ように、動的な規則を作成します。しかしながら、このオプションは、
keep-state と対照的に暗黙の check-state を暗示しません。
recv | xmit | via {ifX | if* | table(name[,value]) | ipno | any}
それぞれ、受信された、転送された、または通過したパケット、正確な
名前 (ifX) によって、デバイス名 (if*) によって、IP アドレスによっ
て、またはいくつかのインタフェースを通して、指定されたインタ
フェースを照合します。テーブル name は、そのカーネルの ifindex に
よってインタフェースと一致するために使用されます。検索テーブルに
関する詳しい情報については、下記の「検索テーブル」セクションを参
照してください。
via キーワードによって、インタフェースは、常にチェックされます。
recv または xmit が via の代わりに使用されるなら、(それぞれ) 受信
インタフェース、または送信インタフェースのみがチェックされます。
両方を指定することによって、送信と受信インタフェースの両方に基づ
くパケットを一致することが可能です、例えば、次の通りです:
ipfw add deny ip from any to any out recv ed0 xmit ed1
着信してくるパケットまたは発信するパケットのいずれかで、recv イン
タフェースをテストすることができますが、一方、xmit インタフェース
は、発信するパケットでのみテストすることができます。したがって、
out は、xmit が使用されるときはいつでも、必要とされます (そして、
in は、無効とされます)。
パケットは、受信または送信インタフェースがないかもしれません:
ローカルホストから発生するパケットは、受信インタフェースがありま
せんが、一方ローカルホストに行くパケットには、送信インタフェース
がありません。
set-limit {src-addr | src-port | dst-addr | dst-port} N
limit のように動作しますが、それにアタッチされる暗黙の check-
state は、ありません。
setup SYN ビットがある一致する TCP パケットは、設定しますが、ACK ビット
がありません。これは、``tcpflags syn,!ack'' の短縮形です。
sockarg
ローカルなソケットに関連するパケットと SO_USER_COOKIE ソケットオ
プションが 0 でない値に設定されるに対して照合します。副作用とし
て、オプションの値は、skipto または pipe 番号として順番に使用する
ことができる、tablearg 値として利用可能にされます。
src-ip ip-address
発信元 IP が引数として指定された (複数の) アドレスの 1 つである
IPv4 パケットと照合します。
src-ip6 ip6-address
発信元 IP が引数として指定された (複数の) アドレスの 1 つである
IPv6 パケットと照合します。
src-port ports
発信元ポートが引数として指定された (複数の) ポートの 1 つである
IP パケットと照合します。
tagged tag-list
タグが単一の値、または ports と同じ方法で指定された値または範囲の
リストのいずれかである tag-list に含められているパケットと照合し
ます。tag 規則アクションのパラメータを使用してパケットにタグを適
用することができます (それがタグの詳細のための説明を参照してくだ
さい)。
tcpack ack
TCP パケットのみ。TCP ヘッダ確認応答番号フィールドが ack に設定さ
れるなら、一致します。
tcpdatalen tcpdatalen-list
TCP データの長さが単一の値、または ports と同じ方法で指定された値
または範囲のリストにいずれかである、tcpdatalen-list である TCP パ
ケットを照合します。
tcpflags spec
TCP パケットのみ。TCP ヘッダが、spec で指定されたフラグのコンマで
区切られたリストを含んでいるなら、一致します。サポートされている
TCP フラグは、次の通りです:
fin, syn, rst, psh, ack と urg。特定のフラグが存在しないことは、
`!' で示されます。tcpflags 指定を含んでいる規則は、決して、0 でな
いオフセットがあるフラグメント化されたパケットと一致しません。フ
ラグメント化されたパケットの照合に関する詳細については、frag オプ
ションを参照してください。
tcpmss tcpmss-list
MSS (最大のセグメントサイズ) 値が単一の値、または ports と同じ方
法で指定された値のリストまたは範囲のいずれかである tcpmss-list に
設定される TCP パケットと照合します。
tcpseq seq
TCP パケットのみです。TCP ヘッダのシーケンス番号のフィールドが
seq に設定されるなら、照合します。
tcpwin tcpwin-list
ヘッダのウィンドウフィールドが、単一の値または ports と同じ方法で
指定された値または範囲のリストのいずれかである、tcpwin-list に設
定される TCP パケットと一致します。
tcpoptions spec
TCP パケットのみ。TCP ヘッダが、spec で指定されたオプションのコン
マで区切られたリストを含んでいるなら、照合します。サポートされた
TCP オプションは、次の通りです:
mss (最大のセグメントサイズ)、window (tcp ウィンドウ通知)、sack
(選択的な ack)、ts (rfc1323 タイムスタンプ) と cc (rfc1644 t/tcp
接続カウント)。特定のオプションの不在は、`!' で示されます。
uid user
user のために送信されるか、または受信されるすべての TCP または
UDP パケットと照合します。user は、名前または識別番号と照合されま
す。
verrevpath
着信してくるパケットについて、経路表の検索は、パケットの発信元ア
ドレスで行なわれます。システムに入って来るパケットのインタフェー
スが、経路のための発信するインタフェースと一致しているなら、パ
ケットは、一致しています。インタフェースが照合されないなら、パ
ケットは、一致していない。すべての受信するパケットまたは着信して
くるインタフェースなしのパケットは、一致します。
オプションの名前と機能は、Cisco IOS コマンドと意図的に似ています:
ip verify unicast reverse-path
このインタフェースからでなく、送信元アドレスがあるすべてのパケッ
トを拒否するために、なりすましに対抗する (anti-spoofing) 規則を作
るために、このオプションを使用することができます。また、オプショ
ン antispoof を参照してください。
versrcreach
着信パケットのために、経路表の検索は、パケットの送信元アドレスで
行われます。送信元アドレスへの経路が存在しますが、デフォルト経路
でない、またはブラックホール/拒否された経路であるなら、パケット
は、一致します。そうでなければ、パケットは、一致しません。すべて
の発信パケットは、一致します。
オプションの名前と機能は、Cisco IOS コマンドに意図的に似せてあり
ます:
ip verify unicast source reachable-via any
このオプションは、送信元アドレスが到達可能でないすべてのパケット
を拒否するためにスプーフィング (なりすまし) 対策の規則を作るため
に使用することができます。
antispoof
着信してくるパケットのために、パケットの送信元アドレスは、直接接
続されたネットワークに属しているかどうか調べられます。ネットワー
クが直接接続されるなら、着信するパケットのインタフェースは、ネッ
トワークが接続されているインタフェースと比較されます。着信してく
るインタフェースと直接接続されたインタフェースが同じではないと
き、パケットは、一致しません。そうでなければ、パケットは、一致し
ます。すべての発信するパケットは、一致します。
直接接続されたネットワークからであるふりをする、すべてのパケット
を拒否するために、スプーフィング (なりすまし) 対策の規則を作成す
るために、このオプションを使用することができますが、そのインタ
フェースを通して着信しません。このオプションは、すべての送信元ア
ドレスの代わりに直接接続されたネットワークの送信元アドレスでパ
ケットでのみ関与するので、verrevpath と似ていますが、より制限され
ています。
検索テーブル
検索テーブルは、アドレスまたは他の検索キー (例えば、ポート、jail ID、イン
タフェース名) の大きなまばらなセットを扱うために役に立ちます。このセク
ションの残りで、私たちは、用語 ``キー'' を使用します。テーブル名は、次の
仕様と一致する必要があります: table-name。異なる sets で同じ名前がある
テーブルを作成することができます。しかしながら、規則は、デフォルトで set
0 のテーブルにリンクします。この振る舞いは、net.inet.ip.fw.tables_sets 変
数によって制御することができます。詳細については、「規則のセット」セク
ションを参照してください。65535 までの異なる検索テーブルがあります。
次のテーブルタイプがサポートされています:
table-type: addr | iface | number | flow
table-key: addr[/masklen] | iface-name | number | flow-spec
flow-spec: flow-field[,flow-spec]
flow-field: src-ip | proto | src-port | dst-ip | dst-port
addr IPv4 または IPv6 アドレスに一致します。各エントリは、
addr[/masklen] によって表わされ、(IPv4/IPv6 アドレスまたはホスト
名として指定された) ベースの addr と masklen ビットのマスク幅があ
るすべてのアドレスと一致します。masklen が指定されないなら、IPv4
のためのデフォルトは、32 で、IPv6 のためのデフォルトは、128 で
す。テーブルの IP アドレスを検索するとき、最も特有のエントリが一
致します。
iface インタフェース名と一致します。各エントリは、インタフェース名とし
て扱われる文字列によって表わされます。ワイルドカードは、サポート
されません。
number プロトコルポート、uid/gid または jail ID に一致します。各エントリ
は、32 ビットの符号なし整数によって表わされます。範囲は、サポート
されません。
flow テーブルエントリで flow タイプのサブオプションによって指定された
パケットフィールドに一致します。
テーブルは、使用の前の create によって明示的な生成を要求します。
次の生成オプションがサポートされます:
create-options: create-option | create-options
create-option: type table-type | valtype value-mask | algo algo-desc |
limit number | locked | missing | or-flush
type テーブルのキータイプ。
valtype
テーブルの値マスク。
algo 使用するテーブルアルゴリズム (下記を参照)。
limit テーブルに挿入されるかもしれない項目の最大数。
locked あらゆるテーブルの修正を制限します。
missing
テーブルが既に存在し、新しいものとして正確に同じオプションがある
なら、失敗しません。
or-flush
エラーを返す代わりに同じ名前で既存のテーブルをフラッシュします。
missing を意味しているので、既存のテーブルは、新しいものとの互換
性がなければなりません。
これらのオプションのいくつかは、modify キーワードによって後で修正されるか
もしれません。次のオプションを変更することができます:
modify-options: modify-option | modify-options
modify-option: limit number
limit テーブルに挿入されるかもしれない項目の最大数を変更します。
さらに、テーブルは、lock または unlock コマンドを使用して、ロックするか、
またはロックの解除をすることができます。
同じ type のテーブルは、swap name コマンドを使用して、互いに交換すること
ができます。交換は、テーブルの制限が設定され、データ交換が制限に達する結
果となるなら、失敗します。操作は、不可分に実行されます。
1 つ以上のエントリは、add コマンドを使用して、一気にテーブルに追加するこ
とができます、すべてのアイテムの追加は、不可分に実行されます。デフォルト
で、1 つのエントリの追加のエラーは、他のエントリの追加に影響しません。し
かしながら、その場合、0 でないエラーコードが、返されます。特別の atomic
キーワードは、add がすべてかなし (all-or-none) の add 要求を示す前に指定
されます。
1 つ以上のエントリは、delete コマンドを使用して、一気にテーブルから削除す
ることができます、デフォルトで、1 つのエントリの削除のエラーは、他のエン
トリの削除に影響しません。しかしながら、その場合、0 でないエラーコード
が、返されます。
エントリが lookup table-key コマンドを使用して、特別の table-key で何が見
つかるかチェックすることは可能です。この機能は、オプションで、いくつかの
アルゴリズムでサポートされないかもしれません。
次の操作は、1 つまたはすべてのテーブルで実行することができます:
list すべてのエントリをリストします。
flush すべてのエントリを削除します。
info 一般的なテーブル情報を表示します。
detail 一般的なテーブル情報と algo 特有のデータを表示します。
次の検索アルゴリズムがサポートされます:
algo-desc: algo-name | algo-name algo-data
algo-name: addr: radix | addr: hash | iface: array | number: array |
flow: hash
addr: radix
経路表 (route(4) を参照) と同じ方法の IPv4、と IPv6 のための個別
の Radix ツリー。addr タイプのためのデフォルトの選択。
addr:hash
IPv4 と IPv6 のための個別の自動成長 (auto-growing) ハッシュ。
addr:hash masks=/v4,/v6 アルゴリズム生成オプションによって最初に
指定される同じマスクの長さの受け付けエントリ。デフォルトで /32 と
/128 のマスクを仮定します。検索は、適切なハッシュの供給されたアド
レスとチェックの結果のキーから (マスクにしたがって) ホストビット
を削除します。/64 とバイト範囲の IPv6 マスクのためにほぼ最適化さ
れました。
iface:array
システムで存在しているエントリのためにソートされたインデックスを
格納する配列。非常に速い検索のために最適化されました。
number:array
ソートされた u32 番号を格納する配列。
flow:hash
flow エントリを格納する自動成長 (auto-growing) ハッシュ。検索は、
選択されたバケットのエントリと一致するための要求されるパケット
フィールドと検索でハッシュを計算します。
tablearg 機能は、規則のアクション、アクションのパラメータまたは規則のオプ
ションのための引数として、テーブルで検索される値を使用する能力を提供して
います。これは、いくつかの設定の規則の数を著しく減らすことができます。2
つのテーブルが規則で使用されるなら、2 番目 (宛先) の結果が使用されます。
各レコードは、value-mask にしたがって 1 つ以上の値を保持します。このマス
クは、valtype オプションによってテーブル作成で設定されます。次の値のタイ
プがサポートされています:
value-mask: value-type[,value-mask]
value-type: skipto | pipe | fib | nat | dscp | tag | divert |
netgraph | limit | ipv4
skipto ジャンプする規則数。
pipe 使用するパイプ番号。
fib 照合/設定する fib 番号。
nat ジャンプする nat 番号。
dscp 照合/設定する dscp 値。
tag 照合/設定する tag 番号。
divert トラフィックを迂回するポート番号。
netgraph
パケットを移動させるフック番号。
limit 接続の最大数。
ipv4 パケットを転送する IPv4 nexthop (次の中継点)。
ipv6 パケットを転送する IPv6 nexthop (次の中継点)。
tablearg 引数は、次のアクションで使用することができます: nat, pipe,
queue, divert, tee, netgraph, ngtee, fwd, skipto, setfib アクションパラ
メータ: tag, untag 規則オプション: limit, tagged。
skipto アクションとともに使用されるとき、ユーザは、コードが与えられた数と
等しい規則または越えるまで、規則セットを walk (歩き回る) することに注意す
るべきです。
テーブルと tablearg キーワードの使用法の例については、「使用例」セクショ
ンを参照してください。
規則のセット
各規則またはテーブルは、0 から 31 までの番号が付けられた、32 の異なるセッ
トの 1 つに属します。セット 31 は、デフォルトの規則のために予約されていま
す。
デフォルトで、規則またはテーブルは、利用者が新しい規則またはテーブルを追
加するとき、set N 属性を使用しないなら、セット 0 に入れられます。セット
は、個別に、そして不可分に有効にされるか、または無効にすることができるの
で、このメカニズムは、ファイアウォールの複数の設定を格納し、それらの間を
す速く (そして、不可分に) 切り替える容易な方法を許可します。
デフォルトで、セット 0 のテーブルは、規則セットにかかわらずテーブル
opcodes で規則を追加するとき、参照されます。この振る舞いは、
net.inet.ip.fw.tables_sets 変数を 1 に設定することによって変更することが
できます。次に、規則のセットは、テーブル参照のために使用されます。
セットを有効/無効にするコマンドは、次の通りです。
ipfw set [disable number ...] [enable number ...]
ここで、複数の enable または disable セクションを指定することができます。
コマンドの実行は、コマンドで指定されたすべてのセットで不可分です。デフォ
ルトで、すべてのセットは、有効にされます。
利用者がセットを無効にするとき、あたかもそれらが次のただ 1 つの例外で、
ファイアウォールの設定に存在しないかのように、その規則は、振る舞います:
それが無効にされる前に規則から作成された動的な規則は、それらが期限
切れになるまで、まだ、アクティブです。動的な規則を削除するために、
利用者は、それらを生成した親の規則を明示的に削除しなければなりませ
ん。
規則のセット番号は、コマンドで変更することができます。
ipfw set move {rule rule-number | old-set} to new-set
また、次のコマンドで 2 つの規則セットを不可分に切り替えることができます。
ipfw set swap first-set second-set
規則のセットのいくつかの可能な利用法については、「使用例」セクションを参
照してください。
ステートフルファイアウォール
ステートフル操作は、与えられたパターンと一致しているパケットが検出される
とき、特有のフローのための規則を動的に作成するファイアウォールのための方
法です。ステートフル操作のためのサポートは、rules の check-state, keep-
state, record-state, limit と set-limit オプションを提供します。
動的な規則は、すべて一致して、アドレスの src-ip/src-port dst-ip/dst-port
ペアの間の与えられたプロトコルがあるパケットのみの動的規則の作成を引き起
こして、パケットが、keep-state, record-state, limit または set-limit 規則
と一致するとき、作成されます (src と dst は、初期の一致するアドレスを示す
ためだけに、ここで使用されますが、それらは、その後に完全に等しくなりま
す)。keep-state オプションによって作成された規則は、それから取られる
:flowname もあります。この名前は、アドレス、ポートとプロトコルとともに照
合で使用されます。動的規則は、最初の check-state, keep-state または limit
の発生でチェックされ、一致で実行されるアクションは、親の規則と同じとなり
ます。
プロトコルと IP アドレスとポートと :flowname 以外の追加の属性は、動的規則
でチェックされないことに注意してください。
動的な規則の典型的な使用は、ファイアウォールの設定をクローズし続けること
ですが、内部のネットワークから最初の TCP SYN パケットをセッションに属して
いるパケットが、ファイアウォールを通して許可できるように、ストリームのた
めの動的な規則をインストールします:
ipfw add check-state :OUTBOUND
ipfw add allow tcp from my-subnet to any setup keep-state :OUTBOUND
ipfw add deny tcp from any to any
同様のアプローチは、UDP のために使用することができます、ここで、内部から
来る UDP パケットは、ファイアウォールを通して応答するために動的規則をイン
ストールします:
ipfw add check-state :OUTBOUND
ipfw add allow udp from my-subnet to any keep-state :OUTBOUND
ipfw add deny udp from any to any
動的な規則は、フローの状態といくつかの sysctl 変数の設定に依存して、しば
らくした後に期限切れになります。より詳しい情報については、セクション
「SYSCTL 変数」を参照してください。TCP セッションについて、まもなく期限切
れになるとき、規則の状態をリフレッシュするためにキープアライブ
(keepalive) パケットを周期的に送信するために、動的な規則を指示することが
できます。
どのように動的な規則を使用するかに関する多くの使用例については、セクショ
ン「使用例」を参照してください。
トラフィックシェイパ (DUMMYNET) の設定
また、ipfw は、dummynet トラフィックシェイパ (shaper)、パケットスケジュー
ラとネットワークエミュレータ、人工的にキューに入れられる、特定のネット
ワークリンクまたはキューに入れられるシステムの振る舞いをエミュレートして
いるパケットを遅延するか、または落とすサブシステムのためのユーザインタ
フェースです。
dummynet は、ipfw 規則で使用することができるあらゆる一致するパターンを使
用してパケットを選択するためにファイアウォールを最初に使用して動作しま
す。一致していパケットは、次にトラフィックの規則を実装する、2 つの異なっ
たオブジェクトのいずれかを渡されます:
pipe pipe は、プログラム可能なキューのサイズとパケット損失レートで
FIFO スケジューラと単一のキューによってドライブされ、与えられ
た帯域幅と伝播遅延を与えられる link リンクをエミュレートしま
す。パケットは、ipfw から出て来るようなキューに付け加えられ、
次に要求されたレートでリンクへの FIFO 順序に転送されます。
queue queue は、アルゴリズムをスケジューリングしているいくつかのパ
ケットの 1 つを使用してパケットのスケジューリングを実装するた
めに使用される抽象概念 (abstraction) です。queue に送られたパ
ケットは、最初に、5 の組みのマスクにしたがってフロー (flow)
にグループ化されます。次に、フローは、queue に関連するスケ
ジューラに渡され、各フローは、queue 自体で設定されるようにス
ケジューリングパラメータ (重みつけその他) を使用します。スケ
ジューラは、エミュレートされたリンクと順番に接続され、重み付
けにしたがって未処理のフローの間のリンクの帯域幅と使用中のス
ケジューリングアルゴリズムの機能を解決します。
実際のところ、どのように異なったフローが利用可能な帯域幅を共有するかを決
定するために、queues が使用できるかどうかに対して、フローが使用することが
できる帯域幅にハードな制限を設定するために pipes を使用することができま
す。
キュー、フロー、スケジューラとリンクの結合のグラフ表現は、下記の通りで
す。
(flow_mask|sched_mask) sched_mask
+---------+ weight Wx +-------------+
| |->-[flow]-->--| |-+
-->--| QUEUE x | ... | | |
| |->-[flow]-->--| SCHEDuler N | |
+---------+ | | |
... | +--[LINK N]-->--
+---------+ weight Wy | | +--[LINK N]-->--
| |->-[flow]-->--| | |
-->--| QUEUE y | ... | | |
| |->-[flow]-->--| | |
+---------+ +-------------+ |
+-------------+
コマンド
ipfw sched N config mask SCHED_MASK ...
と
ipfw queue X config mask FLOW_MASK ...
を通して設定される SCHED_MASK と FLOW_MASK の役割を理解することは重要で
す。
SCHED_MASK は、SCHED_MASK を適用した後のパケットの 5 つの組の値ごとに 1
つの値の、1 つ以上のスケジューラのインスタンスをフローに割り当てるために
使用されます。例として、``src-ip 0xffffff00'' を使用することは、/24 の宛
先のサブネットごとに 1 つのインスタンスを作成します。
SCHED_MASK とともに、FLOW_MASK は、パケットをフローに分割するために使用さ
れます。例として、前の SCHED_MASK とともに ``src-ip 0x000000ff'' を使用す
ることは、個別の送信元アドレスごとに 1 つのフローを作ります。順々、/24 サ
ブネットごとのフローは、同じスケジューラのインスタンスに送信されます。
上記のダイアグラムは、pipe が SCHED_MASK をサポートだけである唯一の制限が
ある、pipe の場合のためさえ保持され、FIFO スケジューラの使用を強制します
(これらは、後方互換性の理由のためです。実際のところ、内部的に、dummynet
のパイプは、上記のように正確に実装されます)。
dummynet 操作の 2 つのモードがあります: ``normal'' と ``fast''。
``normal'' モードは、実際のリンクをエミュレートしようと試みます: dummynet
スケジューラは、パケットが、与えられた帯域幅で実際のリンクより速いパイプ
を残さないことを保証しています。``fast'' モードによって、特定のパケット
は、(パケットフローがパイプの帯域幅を越えていないなら) dummynet スケ
ジューラをバイパス (迂回) することができます。これは、``fast'' モードが、
(平均で) パケットごとのより少ない CPU サイクルを必要とする理由で、パケッ
トの待ち時間は、同じ帯域幅がある実際のリンクと比べてかなり低いかもしれま
せん。デフォルトのモードは、``normal'' です。net.inet.ip.dummynet.io_fast
sysctl(8) を 0 以外の値に設定することによって、``fast'' モードを有効にす
ることができます。
パイプ、キューとスケジューラの設定
pipe, queue と scheduler の設定コマンドは、次の通りです:
pipe number config pipe-configuration
queue number config queue-configuration
sched number config sched-configuration
次のパラメータを、パイプのために設定することができます:
bw bandwidth | device
次で測定されるの帯域幅 [K|M|G]{bit/s|Byte/s}。
0 の値 (デフォルト)は、制限のない帯域幅を意味します。単位は、次の
ように直ちに数に続かなければなりません。
ipfw pipe 1 config bw 300Kbit/s
次のように、デバイス名が数値の代わりに指定されるなら、
ipfw pipe 1 config bw tun0
送信クロックは、指定されたデバイスによって供給されます。現在のと
ころ、ppp(8) と組み合わせて使用するために、tun(4) デバイスのみが
この機能をサポートしています。
delay ms-delay
ミリ秒単位で測定される、伝搬遅延。値は、クロックチック (clock
tick) の次の倍数に丸められます (通常 10ms ですが、精度を 1ms 以下
に減らすために ``options HZ=1000'' でカーネルを実行するのに良い実
践です)。デフォルト値は、0 であり、遅延なしを意味します。
burst size
送信されるデータがパイプの帯域幅の制限 (と、パイプは、以前にアイ
ドルであった) を越えているなら、データの size バイトまでは、
dummynet スケジューラを迂回することを許可され、許可された物理的な
リンクでできるだけ速く送信されます。あらゆる追加のデータは、pipe
の帯域幅によって指定されたレート (速度) で転送されます。バースト
(burst) サイズは、パイプがどれくらいながくアイドルであったかに依
拠しています。効果的なバースト (burst) サイズは、次のように計算さ
れます: MAX (size, bw * pipe_idle_time)
profile filename
リンクのパケットの転送で生じる追加のオーバヘッドを指定している
ファイル。
いくつかのリンクタイプは、パケットの転送で特別な遅延を導入しま
す、例えば、MAC レベルのフレーミング、チャネルの使用の競合、MAC
レベルの再転送など。我々の観点から、チャネルは、定数か、またはリ
ンクタイプに依存する、この特別な時間のために効果的に利用可能では
ありません。さらに、パケットは、この時間の後に、(例えば、あまりに
多くの再転送の後に、無線リンクで) 落とされます。我々は、その配布
を表している実験曲線で追加の遅延をモデル化できます。
累積確率
1.0 ^
|
L +-- loss-level x
| ******
| *
| *****
| *
| **
| *
+-------*------------------->
遅延
実験曲線には、垂直線と水平線があります。垂直線は、確率の範囲のた
めの一定の遅延を表します。水平線は、遅延分布の不連続に対応してい
ます: パイプは、与えられた確率のための最も大きな遅延を使用しま
す。
ファイル形式は、セパレータとして動作する空白類とコメントの始めを
示している '#' があり、次の通りです:
name identifier
("ipfw pipe show" によってリストされる) 遅延分布を識別す
るオプションの名前。
bw value
パイプのために使用される帯域幅。ここで指定されないなら、
それは、パイプのための設定パラメータとして明示的に存在し
なければなりません。
loss-level L
パケットが失われる上記の確率。(0.0 <= L <= 1.0, デフォル
ト 1.0、すなわち、損失なし)。
samples N
曲線の内部表現で使用されるサンプルの数 (2..1024; デフォル
ト 100)。
delay prob | prob delay
これらの 2 つの線の 1 つは、強制的で、データポイントで次
の線の形式を定義します。
XXX YYY
選択された形式にしたがって、最初の遅延または確率のいずれ
かの曲線の点で表される 2 つ以上の線。遅延のための単位は、
ミリ秒です。データポイントは、ソートされる必要はありませ
ん。また、実際の線の数は、"samples" パラメータの値と異な
るかもしれません: ipfw ユーティリティは、必要に応じて曲線
をソートして、補完します。
プロファイルのファイルの例は、次の通りです:
name bla_bla_bla
samples 100
loss-level 0.86
prob delay
0 200 # 最小のオーバヘッドは, 200ms です
0.5 200
0.5 300
0.8 1000
0.9 1300
1 1300
#設定ファイルの終わり
次のパラメータをキューのために設定することができます。
pipe pipe_nr
キューを指定されたパイプに接続します。複数キュー (同じまたは異
なった重みで) は、キューの集合のための集められたレートを指定す
る、同じパイプに接続することができます。
weight weight
このキューに一致しているフローのために使用される重みを指定しま
す。重みは、範囲 1..100 でなければなりません、デフォルトは、1 で
す。
次の大文字と小文字を区別しないパラメータをスケジューラのために設定するこ
とができます:
type {fifo | wf2q+ | rr | qfq | fq_codel | fq_pie}
は、使用するスケジューリングアルゴリズムを指定します。
fifo は、(すべてのパケットが、スケジューラに到着するのと同じ
キューに格納されるかを意味する) 単に FIFO スケジューラで
す。FIFO は、(2GHz のデスクトップマシンで 60-80 ナノ秒を
評価する) 非常に低い定数がある、パケットごとの O(1) の時
間の複雑さがありますが、サービス保証を与えません。
wf2q+ は、それらの重み付けにしたがって帯域幅を共有するフローを
許可する Weighted Fair Queueing アルゴリズムである、WF2Q+
アルゴリズムを実装しています。重み付けは、優先順序ではな
いことに注意してください。極めて小さい重み付けがあるフ
ローでさえ、決して渇望しません。WF2Q+ は、パケットごとに
O(log N) の処理コストがあります、ここで、N は、フローの数
であり、以前のバージョンの dummynet のキューによって使用
されたデフォルトのアルゴリズムです。
rr は、O(1) の処理コスト (おおよそ、パケットごとに、100-150
ナノ秒) があり、重み付けしたがって帯域幅の割り付けを許可
しますが、乏しいサービス保証がある、Deficit Round Robin
アルゴリズムを実装しています。
qfq は、同様のサービス保証と O(1) 処理コスト (おおよそ、パ
ケットごとに 200-250 ナノ秒) がある、WF2Q+ の非常に速い変
異型である QFQ アルゴリズムを実装しています。
fq_codel
軽量であるか、または短いバースト (burst) フローへの優先度
の短い期間を提供するためにサブキュー (古いサブキューと新
しいサブキュー) の 2 つのリストを管理するために、修正され
た Deficit ラウンドロビン (Round Robin) スケジューラを使
用する、FQ-CoDel (FlowQueue-CoDel) スケジューラ/AQM アル
ゴリズムを実装しています。デフォルトで、サブキューの合計
数は、1024 です。FQCoDel の内部の動的に作成されたサブ
キューは、CoDel AQM の個別のインスタンスによって制御され
ます。
fq_pie fq_codel に類似している、FQ-PIE (FlowQueue-PIE) スケ
ジューラ/AQM アルゴリズムを実装していますが、キューの遅れ
を制御するサブキュー PIE AQM のインスタンスごとに使用しま
す。
fq_codel は、codel (下記参照) から AQM パラメータとオプションを継
承し、fq_pie は、pie (下記参照) から AQM パラメータとオプションを
継承します。さらに、fq_codel と fq_pie の両方には、次の通りである
スケジューラのパラメータを共有しました:
quantum
m は、スケジューラの数量 (クレジット) を指定します。m
は、キューが古いキューのリストの末尾に移動されている前
に、役に立てることができるバイト数です。デフォルトは、
1514 バイトで、最大の受け付け可能な値は、9000 バイトで
す。
limit m は、スケジューラのインスタンスよって管理されるすべての
キューの (パケットの単位の) 難しいサイズ制限を指定しま
す。m のデフォルト値は、10240 パケットで、最大の受け付け
可能な値は、20480 パケットです。
flows m は、fq_* が作成して、管理するフローキューの (サブ
キュー) の合計数を指定します。デフォルトで、1024 のサブ
キューは、fq_{codel/pie} ケジューラのインスタンスが作成さ
れるとき、作成されます。最大の受け付け可能な値は、65536
です。
fq_codel または fq_pie の後のあらゆるトークンは、fq_{codel/pie}
のためのパラメータを考慮することに注意すべきです。それで、
fq_{codel/pie} に関連していないすべてのスケジューラ設定オプション
が fq_codel/fq_pie トークンの前に書き込まれることを確認します。
タイプに加えて、また、スケジューラのためにパイプのために許可されたすべて
のパラメータを指定することができます。
最後に、両方のパイプとキューに対して次のパラメータを設定することができま
す:
buckets hash-table-size
様々なキューを格納するために使用されるハッシュテーブルのサイズを指
定します。デフォルト値は、sysctl(8) 変数
net.inet.ip.dummynet.hash_size によって制御された 64 であり、許され
る範囲は、16 から 65536 までです。
mask mask-specifier
ipfw 規則によって与えられたパイプまたはキューに送信するパケットは、
複数のフローにさらに分類することができ、次に、そのそれぞれは、異な
る動的なパイプまたはキューに送信さられます。フロー識別子は、パイプ
またはキューの設定で mask オプションで指定されるように IP アドレ
ス、ポートとプロトコルタイプをマスクすることによって構成されます。
異なったフロー識別子ごとに、新しいパイプまたはキューは、オリジナル
のオブジェクトと同じパラメータで作成され、一致するパケットは、それ
に送信されます。
したがって、動的なパイプは、使用されるとき、各フローは、パイプに
よって定義されるように同じ帯域幅を取得し、動的なキューが使用される
ときであるのに対して、各フローは、同じキューによって生成された他の
フローで均等に親のパイプの帯域幅を共有します (異なった重みがある他
のキューが同じパイプと接続されることに注意してください)。
利用可能なマスク指定子は、次の 1 つ以上の組み合わせです:
dst-ip mask, dst-ip6 mask, src-ip mask, src-ip6 mask, dst-port
mask, src-port mask, flow-id mask, proto mask または all
ここで、後者は、すべてのフィールドのすべてのビットは、重要であるこ
とを意味します。
noerror
パケットが dummynet キューまたはパイプによって落とされるとき、エ
ラーは、通常、デバイスキューが満杯になるときそれが起こるのと同じ方
法で、カーネルの呼び出し側のルーチンに報告されます。このオプション
を設定することは、成功して配信されるようにパケットを報告し、利用者
がリモートのルータで損失または輻輳をシミュレートしたい、いくらかの
実験的な設定のために、必要とされます。
plr packet-loss-rate
パケットの損失率。引数 packet-loss-rate は、0 と 1 間の浮動小数点数
で、0 は、損失がないことを意味し、1 は、100% の損失を意味します。損
失率は、31 ビットで内部的に表現されます。
queue {slots | sizeKbytes}
slots または KBytes 単位のキューのサイズ。デフォルト値は、イーサ
ネットデバイスのための通常のキューのサイズである、50 のスロットで
す。低速のリンクについて、利用者は、キューのサイズを短くし続けるべ
きであるか、または利用者のトラフィックが重要なキューイングの遅延に
よって影響されるかもしれないことに注意してください。例えば、50 の最
大サイズのイーサネットパケット (1500 バイト) は、30Kbit/s のパイプ
でキューの 600Kbit または 20s を意味します。利用者がより大きな MTU
で、例えば、16KB のパケットがあるループバックインタフェース、インタ
フェースからパケットを取得するなら、さらに悪い影響の結果となるかも
しれません。sysctl(8) 変数 net.inet.ip.dummynet.pipe_byte_limit と
net.inet.ip.dummynet.pipe_slot_limit は、指定することができる最大の
長さを制御します。
red | gred w_q/min_th/max_th/max_p
[ecn] RED (Random Early Detection) キューの管理アルゴリズムを使用し
ます。w_q と max_p は、0 と 1 (両端を含める) の間の浮動小数点数で
が、min_th と max_th は、キューの管理のための閾値を指定している整数
です (閾値は、キューがバイト単位で定義されているなら、バイト単位で
計算され、そうでなければスロット単位で計算されます)。また、2 つのパ
ラメータは、必要であるなら、同じ値を指定できます。dummynet は、オプ
ションとして、gentle RED という変型 (gred) と ECN (Explicit Conges
tion Notification; 明示的な輻輳通知) もサポートします。RED の振る舞
いを制御するために、3 つの sysctl(8) 変数を使用することができます:
net.inet.ip.dummynet.red_lookup_depth
リンクがアイドルであるとき、平均的なキューの計算で精度を指
定します (デフォルトは、256 で、0 より大きくなければなりま
せん)
net.inet.ip.dummynet.red_avg_pkt_size
予期される平均的なパケットサイズを指定します (デフォルト
は、512 で、0 より大きくなければなりません)
net.inet.ip.dummynet.red_max_pkt_size
キューの閾値がバイト単位であるときのみ使用される、予期され
る最大のパケットサイズを指定します (デフォルトは、1500 で、
0 より大きくなければなりません)
codel [target time] [interval time] [ecn | noecn]
CoDel (制御された遅延) キューの管理アルゴリズムを使用します。time
は、デフォルトでミリ秒として解釈されますが、秒 (s)、ミリ秒 (ms) ま
たはマイクロ秒 (us) を代わりに指定することができます。CoDel は、
キューのパケットの滞在時間に依存して (ECN) パケットを落とすか、マー
クします。target time (デフォルトは、5ms) は、CoDel が許可する最小
の受け付け可能である持続的なキューの遅れです。CoDel は、パケットの
滞在時間が target time より長くなった後に直接パケットを落としません
が、落す前に、interval time (デフォルトは、100ms) 待ちます。
interval time は、すべての期待される接続のために最大 RTT に設定され
るべきです。ecn は、キューの遅れが長くなるとき、ECN の有効にされた
TCP フローのために (落す代わりに) パケットをマークして (デフォルト
で無効にされます) 有効にします。
codel の後のあらゆるトークンは、CoDel のためのパラメータと見なされ
ることに注意してください。それで、すべてのパイプ/キューの設定オプ
ションは、codel トークンの前に書き込まれることを確認します。
CoDel のデフォルトのパラメータを設定するために sysctl(8) 変数
net.inet.ip.dummynet.codel.target と
net.inet.ip.dummynet.codel.interval を使用することができます。
pie [target time] [tupdate time] [alpha n] [beta n] [max_burst time]
[max_ecnth n] [ecn | noecn] [capdrop | nocapdrop] [drand | nodrand]
[onoff] [dre | ts]
PIE (Proportional Integral controller Enhanced) キューの管理アルゴ
リズムを使用します。PIE は、キューの遅延を小さくし続ける間に、高い
スループットを達成する目的で、キュー化プロセスの間に計算された落下
確立に依存してパケットを落とすか、マークします。tupdate time (デ
フォルトは、15ms) の均一の時間間隔で、バックグラウンドプロセスは、
target time (デフォルトは、15ms) とキューの遅延傾向からのキューの遅
延偏差に基づく確立を (再) 計算します。PIE は、出発率の見積りの方法
を使用することによってまたは、(オプションで) CoDel に類似したパケッ
トのタイムスタンプ方法を使用することによって現在のキューの遅延を見
積ります。time は、デフォルトでミリ秒と解釈されますが、秒 (s)、ミリ
秒 (ms) またはマイクロ秒 (us) を代わりに指定することができます。他
の PIE パラメータとオプションは、次の通りです:
alpha n
n は、落下の確立の計算で使用されるキューの遅延偏差の重みを
指定する、0 と 7 の間の浮動小数点数です。デフォルトは、
0.125 です。
beta n n は、落下の確立の計算で使用されるキューの遅延の傾向の重み
を指定する、0 と 7 の間の浮動小数点数です。デフォルトは、
1.25 です。
max_burst time
PIE がパケットを落下/マークしない最大の期間。150ms は、デ
フォルトで、10s が、最大値です。
max_ecnth n
ECN が有効にされるときでさえ、PIE は、落下の確立が ECN 確立
の閾値 max_ecnth n より高くなるとき、それらをマークする代わ
りに、パケットを落とします、デフォルトは、0.1 (すなわち、
10%) です、1 は、最大値です。
ecn | noecn
ECN 有効にされた TCP フローのために ECN のマークを有効また
は無効にします。デフォルトは、無効です。
capdrop | nocapdrop
cap 落下調整を有効または無効にします。cap 落下調整は、デ
フォルトで有効にされます。
drand | nodrand
落下確立の非ランダム化を有効または無効にします。非ランダム
化は、あまりに近く、または、あまりに遠くにパケット落とす問
題を除外します。非ランダム化は、デフォルトで有効にされま
す。
onoff キューのロードに依存する PIE をオンとオフに切り替えることを
有効にします。このオプションが有効にされるなら、PIE は、
キューの 1/3 以上が満杯になるとき、オンに切り替えます。この
オプションは、デフォルトで無効にされます。
dre | ts
出発率の見積り dre またはタイムスタンプ ts を使用している
キューの遅延を計算します。dre が、デフォルトで使用されま
す。
pie の後のあらゆるトークンは、PIE のためのパラメータと見なされるこ
とに注意してください。それで、すべてのパイプ/キューの設定オプション
は、pie トークンの前に書き込まれることを確実にします。pie のデフォ
ルトのパラメータを制御するために sysctl(8) 変数を使用することができ
ます。詳細については、「SYSCTL 変数」セクションを参照してください。
IPv6 データで使用されるとき、dummynet には、現在いくつかの制限がありま
す。インタフェースへのリンクローカルパケットを経路制御するために必要な情
報は、dummynet によって処理した後に、利用可能ではないので、それらのパケッ
トは、出力経路で落されます。リンクローカルパケットが dummynet に渡されな
いことを保証するために、注意されなければなりません。
チェックリスト
ここで、利用者の規則を設計するとき、考慮するいくつかの重要な点を示します:
• 利用者が in と out に行く両方のパケットをフィルタリングすることを覚え
ておいてください。ほとんどの接続は、両方向に行くパケットを必要としま
す。
• 非常に注意深くテストすることを覚えておいてください。テストするとき、
コンソールに近いところにいることは、良い考えです。利用者がコンソール
に近いところにいることができないなら、
/usr/share/examples/ipfw/change_rules.sh の 1 つのような自動回復スク
リプトを使用します。
• ループバックインタフェースを忘れないでください。
洗練された要点
• フラグメント化されたデータグラムが無条件に落とされる状況があります。
TCP パケットは、それらが TCP ヘッダの少なくとも 20 バイトを含んでいな
いなら、落とされ、UDP パケットは、それらが完全な 8 バイトの UDP ヘッ
ダを含んでいないなら、落とされ、ICMP パケットは、それらが、ICMP タイ
プ、コードとチェックサムを指定するために十分な、ICMP ヘッダの 4 バイ
トを含んでいないなら、落とされます。これらのパケットは、意味のあるロ
グエントリを生成するために、パケットに十分なよいデータがないかもしれ
ないので、``pullup failed'' として単にログ記録されます。
• 別のタイプのパケットは、1 つのフラグメントのオフセットがある TCP パ
ケットが無条件に落とされます。これは、有効なパケットですが、それは、
ファイアウォールの裏をかくために、1 つの用途があるだけです。ログ記録
が有効にされるとき、これらのパケットは、規則 -1 によって落とされるよ
うに報告されます。
• 利用者がネットワークを越えてログインされるなら、ipfw の kld(4) バー
ジョンをロードすることは、利用者が考えるほど、たぶん簡単なことではあ
りません。次のコマンド行が推奨されます:
kldload ipfw && \
ipfw add 32000 allow ip from any to any
同じ行に沿って、同様の環境で
ipfw flush
を行うことは、良い考えではありません。
• ipfw フィルタリストは、システムのセキュリティレベルが 3 以上に設定さ
れるなら、修正されません (システムのセキュリティレベルに関する情報に
ついては、init(8) を参照)。
パケットの迂回
指定されたポートにバイドンされた divert(4) ソケットは、そのポートに迂回さ
れたすべてのパケットを受信します。ソケットが、宛先ポートにバインドされて
いないなら、または迂回モジュールがロードされないなら、または、カーネルが
迂回ソケットのサポートでコンパイルされていなかったなら、パケットは、落と
されます。
ネットワークアドレス変換 (NETWORK ADDRESS TRANSLATION; NAT)
ipfw は、libalias(3) のカーネルバージョンを使用してカーネル内 NAT をサ
ポートします。カーネルモジュール ipfw_nat は、ロードされるべきであるか、
または、カーネルは、NAT の使用を可能とするために options IPFIREWALL_NAT
があるべきです。
nat 設定コマンドは、次の通りです:
nat nat_number config nat-configuration
次のパラメータを設定することができます:
ip ip_address
エイリアシングのために使用する IP アドレスを定義します。
if nic NIC の IP アドレスが変更されるなら、それを動的に変更してエイリア
シングのための NIC の IP アドレスを使用します。
log この NAT インスタンスでログ記録を有効にします。
deny_in
外側からあらゆる着信してくる接続を拒否します。
same_ports
実際のローカルポート番号から変更されないエイリアス (別名) ポート
番号をそのままにしようとします。
unreg_only
RFC 1918 の未登録のアドレス空間から発生しないローカルネットワーク
のトラフィックは、無視されます。
unreg_cgn
unreg_only に似ていますが、RFC 6598 (Carrier Grade NAT) アドレス
範囲を含みます。
reset アドレスの変更でパケットのエイリアシングエンジンのテーブルをリ
セットします。
reverse
libalias がエイリアシングを扱う方法を逆にします。
proxy_only
透過的なプロキシ規則にだけに従い、パケットのエイリアシングは、実
行されません。
skip_global
グローバルな状態検索 (下記参照) の場合のインスタンスをスキップし
ます。
nat_number: の代わりにいくつかの特別な値を供給することができます:
global すべての設定された nat のインスタンスの変換状態を検索します。エン
トリが見つけられるなら、パケットは、そのエントリに従って、エイリ
アスされます。エントリがインスタンスのいずれにも見つけられないな
ら、パケットは、変更されずに渡され、新しいエントリは、作成されま
せん。詳しい情報については、natd(8) のセクション「複数のインスタ
ンス」を参照してください。
tablearg
検索テーブルで供給された引数を使用します。検索テーブルの詳しい情
報については、「検索テーブル」セクションを参照してください。
エイリアス/デエイリアスされた後にパケットが続くようにするには、sysctl 変
数 net.inet.ip.fw.one_pass を 0 に設定します。エイリアシングモードに関す
る詳しい情報については、libalias(3) を参照してください。nat の使用法に関
するいくつかの例についてはセクション「使用例」を参照してください。
IPFW のリダイレクションと LSNAT サポート
リダイレクトと LSNAT サポートは、natd(8) で使用される構文に厳密に従いま
す。リダイレクトと lsnat を行う方法のいくつかの例については、セクション
「使用例」を参照してください。
SCTP NAT サポート
ipfw コマンドラインツールを通して TCP と同様の方法で sctp nat を設定する
ことができます。主な違いは、sctp nat がポート変換しないということです。
ローカル側とグローバル側のポートが同じになるので、両方を指定する必要はあ
りません。ポートは、次のようにリダイレクトされます:
nat nat_number config if nic redirect_port sctp
ip_address [,addr_list] {[port | port-port] [,ports]}
sysctl(8) インタフェースを通して、リアルタイムに、ほとんどの sctp nat 設
定を行うことができます。すべて動的に変更されますが、hash_table サイズは、
新しい nat インスタンスのためにだけ変更します。詳しい情報については、
「SYSCTL 変数」を参照してください。
IPv6/IPv4 ネットワークアドレスとプロトコル変換
ステートフル変換
ipfw は、カーネル内の IPv6/IPv4 ネットワークアドレスとプロトコル変換をサ
ポートします。ステートフル NAT64 変換によって、IPv6 のみのクライアント
は、ユニキャスト TCP、UDP または ICMP プロトコルを使用して IPv4 サーバに
連絡することができます。ステートフル NAT64 トランスレータに割り当てられた
1 つ以上 IPv4 アドレスは、いくつかの IPv6 のみのクライアントの間で共有さ
れます。ステートフル NAT64 が DNS64 とともに使用されるとき、変更は、IPv6
クライアントまたは IPv4 サーバで通常要求されません。カーネルモジュール
ipfw_nat64 は、ロードされるべきであるか、または、カーネルは、ステートフル
NAT64 トランスレータを使用することができる options IPFIREWALL_NAT64 があ
るべきです。
ステートフル NAT64 は、オブジェクトのいくつかのタイプのためにたくさんのメ
モリを使用します。IPv6 クライアントが接続を開始するとき、NAT64 トランス
レータは、各ホストエントリは、あらかじめ割り付けられた IPv4 エイリアスエ
ントリを使用します。各エイリアスエントリは、要求に応じて割り付けられた多
くのポートグループエントリがあります。ポートグループエントリは、接続状態
エントリを含んでいます。これらのオブジェクトのための制限と存続期間を制御
するためのいくつかのオプションがあります。
NAT64 トランスレータは、ICMPv6/ICMP 変換を行うとき、RFC7915 に従い、サ
ポートされていないメッセージタイプは、静かに落とされます。IPv6 は、正しい
操作のために明示的に許可される、いくつかの ICMPv6 メッセージタイプを必要
とします。ND6 隣接要請 (ICMPv6 タイプ 135) と隣接通知 (ICMPv6 タイプ 136)
メッセージは、変換規則によって処理されないことを確かめます。
トランスレーションの後に、NAT64 トランスレータは、デフォルトで、パケット
を、netisr キューの対応を通して送信します。したがって、トランスレータのホ
ストは、IPv4 と IPv6 ルータとして設定されるべきです。また、これは、パケッ
トが、ファイアウォールによって 2 回処理されることを意味します。始めて、オ
リジナルのパケットは、トランスレータによって処理され、消費され、次に、そ
れは、再び、変換されたパケットとして処理されます。sysctl 変数
net.inet.ip.fw.nat64_direct_output によって、この振る舞いを変更することが
できます。また、tag 規則アクションを使用して変換されたパケットをタグを付
けすることができ、次にループと特別なオーバヘッドを避けるために、tagged
(タグを付けされた) オペコードによって照されます。
ステートフル NAT64 設定コマンドは、次の通りです:
nat64lsn name create create-options
次のパラメータを設定することができます:
prefix4 ipv4_prefix/plen
マスクがある IPv4 接頭辞は、変換の後に送信元アドレスとして使用さ
れる IPv4 アドレスのプールを定義します。ステートフル NAT64 モ
ジュールは、クライアントの IPv6 送信元アドレスをこのプールから 1
つの IPv4 アドレスに変換します。状態テーブルの対応している状態エ
ントリがない着信 IPv4 パケットは、トランスレータによって落とされ
ることに注意してください。変換規則が、設定された接頭辞に向いてい
るパケットを処理することを確かめます。
prefix6 ipv6_prefix/length
IPv6 接頭辞は、IPv4 アドレスを表すために変換プログラムによって使
用された IPv4 組み込み IPv6 アドレスを定義します。この IPv6 接頭
辞は、DNS64 で設定されるべきです。変換プログラムの実装は、RFC6052
に従い、次の 1 つの接頭辞の長さに制限します: 32、40、48、56、64
または 96。良く知られている IPv6 接頭辞 64:ff9b:: は、96 ビットの
長さでなければなりません。特別な ::/length 接頭辞は、1 つの NAT64
インスタンスでいくつかの IPv6 接頭辞を処理するために使用すること
ができます。NAT64 インスタンスは、接頭辞 length から宛先の IPv4
アドレスを決定します。
states_chunks number
単一のポートグループの状態チャンクの数。デフォルトで各ポートグ
ループは、単一のチャンクに 64 の状態のエントリを保持することがで
きます。上記の値は、単一の IPv4 エイリアスアドレスとポートと関連
することができる状態の最大の数に影響します。値は、2 の冪乗から
128 まででなければなりません。
host_del_age seconds
IPv6 クライアントのためのホストエントリが削除され、すべてのそのリ
ソースが不活発さのために解放されるまでの秒数。デフォルト値は、
3600 です。
pg_del_age seconds
未使用の状態エントリがあるポートグループが、解放されるまでの秒
数。デフォルト値は、900 です。
tcp_syn_age seconds
SYN のみがある TCP 接続のための状態エントリが保持される間の秒数。
TCP 接続の構築が終了されないなら、状態エントリは、削除されます。
デフォルト値は、10 です。
tcp_est_age seconds
後置された TCP 接続のための状態エントリが保持される間の秒数。デ
フォルト値は、7200 です。
tcp_close_age seconds
クローズされた TCP 接続のための状態エントリが保持される間の秒数。
IPv4 サーバは、通常、数分 TIME_WAIT 状態でクローズされた接続を保
持するので、クローズされた接続のための状態エントリを保持すること
は、必要です。トランスレータの IPv4 アドレスは、すべての IPv6 ク
ライアントの間で共有されるので、同じアドレスとポートからの新しい
接続は、これらの接続は、まだ TIME_WAIT 状態であるので、サーバに
よって拒否されます。それらのトランスレータの状態テーブルを保持す
ることは、そのような拒否から保護します。デフォルト値は、180 で
す。
udp_age seconds
UDP データグラムを送信する応答のためのウェートでトランスレータ
が、状態エントリを保持する間の秒数。デフォルト値は、120 です。
icmp_age seconds
ICMP データグラムを送信する応答のためのウェートでトランスレータ
が、状態エントリを保持する間の秒数。デフォルト値は、60 です。
log ipfwlog0 インタフェースを通して BPF によってすべての処理されたパ
ケットのログ記録をオンにします。ipfwlog0 は、疑似インタフェースで
あり、ifconfig コマンドで手動でのブートの後に作成することができま
す。ipfw0 インタフェースより、異なる目的があることに注意してくだ
さい。トランスレータは、各パケットで追加の情報を BPF に送信しま
す。tcpdump で、利用者は、変換の前と後で各処理されたパケットを見
ることができます。
-log BPF によってすべての処理されたパケットのログ記録をオフにします。
allow_private
プライベート IPv4 アドレスの処理をオンにします。デフォルトで、
RFC1918 によって定義されたプライベートアドレスの範囲にマップされ
た宛先がある IPv6 パケットは、処理されません。
-allow_private
nat64 インスタスで扱われるプライベートアドレスをオフにします。
ステートフル NAT64 の状態テーブルを検査するために、次のコマンドを使用する
ことができます:
nat64lsn name show states
ステートレスの NAT64 トランスレータは、変換のための状態テーブルを使用せ
ず、IPv4 アドレスを IPv6 に変換し、逆もまた同様に、設定された検索テーブル
から取られたマッピングだけを基準にします。状態テーブルは、ステートレスの
トランスレータによって使用されないので、それは、IPv4 クライアントを IPv6
のみのサーバに渡すために設定することができます。
ステートレス NAT64 設定コマンドは、次の通りです:
nat64stl name create create-options
次のパラメータを設定することができます:
prefix6 ipv6_prefix/length
IPv6 接頭辞は、IPv4 アドレスを表す変換プログラムによって使用され
る IPv4 組み込みの IPv6 アドレスを定義します。この IPv6 接頭辞
は、DNS64 で設定されるべきです。
table4 table46
検索テーブル table46 は、IPv4 アドレスが、どのように IPv6 アドレ
スに変換されるべきかのマッピングを含みます。
table6 table64
検索テーブル table64 は、IPv6 アドレスが、どのように IPv4 アドレ
スに変換されるべきかのマッピングを含みます。
log ipfwlog0 インタフェースを通して BPF によってすべての処理されたパ
ケットのログ記録をオンにします。
-log BPF によってすべての処理されたパケットのログ記録をオフにします。
allow_private
プライベート IPv4 アドレスの処理をオンにします。デフォルトで、
RFC1918 によって定義されたプライベートアドレスの範囲をマップする
宛先がある IPv6 パケットは、処理されません。
-allow_private
nat64 インスタンスで扱われるプライベートアドレスをオフにします。
一致していないパケットに関してステートレスのトランスレータの振る舞いは、
ステートフルのトランスレータと異なることに注意してください。対応している
アドレスが検索テーブルに見つからなかったなら、パケットは、落とされず、検
索は、継続します。
XLAT464 CLAT 変換
XLAT464 CLAT NAT64 変換は、RFC6877 で定義されるようにクライアント側のス
テートレス変換を実装し、ステートレス NAT64 変換プログラムの上記に説明にた
いへん似ています。検索テーブルの代わりに、それは、設定された接頭辞を使用
して IPv4 と IPv6 アドレスの間の 1 対 1 のマッピングを使用します。それら
がリモートの NAT64 変換プログラムのヘルプで IPv6 のみのネットワークを越え
て IPv4 のみのインターネットにアクセスすることを可能にして、(例えば、
VoIP) 使用していないアプリケーションのための DNS64 サービスの置換として、
このモードを使用することができます。
CLAT NAT64 設定コマンドは、次の通りです:
nat64clat name create create-options
次のパラメータを設定することができま:
clat_prefix ipv6_prefix/length
IPv6 接頭辞は、発信元の IPv4 アドレスを表す変換プログラムによって
使用された IPv4 の組み込み IPv6 アドレスを定義します。
plat_prefix ipv6_prefix/length
IPv6 接頭辞は、宛先 IPv4 アドレスを表す変換プログラムによって使用
された IPv4 の組み込み IPv6 アドレスを定義します。この IPv6 接頭
辞は、リモート NAT64 変換プログラムで設定されるべきです。
log BPF から ipfwlog0 インタフェースを通してすべての処理されたパケッ
トのログ記録をオンにします。
-log BPF を通してすべての処理されたパケットのログ記録をオフにします。
allow_private
プライベート IPv4 アドレスの処理をオンにします。デフォルトで、
nat64clat インスタンスは、RFC1918 で定義されるようにプライベート
な範囲から宛先アドレスで IPv4 パケットを処理しません。
-allow_private
nat64clat インスタンスで扱われるプライベートアドレスをオフにしま
す。
一致していないパケットに関する CLAT 変換プログラムの振る舞いがテートフル
な変換プログラムと異なることに注意してください。対応するアドレスが、設定
された接頭辞と一致しなかったなら、パケットは、落とされず、検索は、継続し
ます。
IPv6 から IPv6 ネットワーク接頭辞変換 (NPTv6)
ipfw は、RFC6296 で説明されるようなカーネル中の IPv6 から IPv6 ネットワー
ク接頭辞変換をサポートします。カーネルモジュール ipfw_nptv6 は、ロードさ
れるべきか、またはカーネルは、NPTv6 変換を使用することができるように
options IPFIREWALL_NPTV6 があるべきです。
NPTv6 設定コマンドは、次の通りです:
nptv6 name create create-options
次のパラメータを設定することができます:
int_prefix ipv6_prefix
内部のネットワークで使用される IPv6 接頭辞。NPTv6 モジュールは、
それが、この接頭辞と一致するとき、送信元アドレスを変換します。
ext_prefix ipv6_prefix
外部のネットワークで使用される IPv6 接頭辞。NPTv6 モジュールは、
それが、この接頭辞と一致するとき、宛先アドレスを変換します。
ext_if nic
NPTv6 モジュールは、外部の接頭辞としてインタフェース nic から最初
グローバルな IPv6 アドレスを使用します。外部のネットワークの IPv6
接頭辞が動的に取得されるとき、役に立てることができます。
ext_prefix と ext_if オプションは、相互に排他的です。
prefixlen length
指定された IPv6 接頭辞の長さ。それは、8 から 64 までの範囲でなけ
ればなりません。
接頭辞変換の規則は、IPv6 パケットの転送が無効にされるとき、静かに無視され
ることに注意してください。パケットの転送を有効にするためには、sysctl 変数
net.inet6.ip6.forwarding を 1 に設定します。
パケットを、変換された後に続かせるためには、sysctl 変数
net.inet.ip.fw.one_pass を 0 に設定します。
ローダ調整変数
ipfw モジュールがロードされる前に、loader(8) プロンプトで、loader.conf(5)
で、または kenv(1) で調整変数を設定することができます。
net.inet.ip.fw.default_to_accept: 0
ipfw の最後の規則の振る舞いを定義します。この値は、カーネル設定
ファイルの options IPFW_DEFAULT_TO_(ACCEPT|DENY) を上書きします。
net.inet.ip.fw.tables_max: 128
ipfw の利用可能なテーブルの数を定義します。数は、65534 を越えるこ
とができません。
SYSCTL 変数
ひとそろいの sysctl(8) 変数は、ファイアウォールと関連するモジュール
(dummynet, bridge, sctp nat) の振る舞いを制御します。これらは、それらのデ
フォルト値 (しかし、sysctl(8) コマンドで、どの値が実際に使用されているか
を常にチェックします) と意味とともに以下に表示されます:
net.inet.ip.alias.sctp.accept_global_ootb_addip: 0
nat がグローバル OOTB ASCONF-AddIP の受信にどのように応答するかを
定義します:
0 応答なし (部分的に一致しているアソシエーションが存在して
いないなら - ポートと vtags は、一致しますが、グローバル
アドレスは、一致しない)
1 nat は、すべての OOTB グローバル AddIP メッセージを受け付
けて処理します。
オプション 1 は、これがセキュリティリスクを形成するように、決して
選択されるべきではありません。攻撃者は、メッセージを AddIP に送信
することによって、複数の偽のアソシエーションを設立できます。
net.inet.ip.alias.sctp.chunk_proc_limit: 5
既存のアソシエーションに一致するパケットのために解析される SCTP
パケットのチャンクの最大数を定義します。この値は、
net.inet.ip.alias.sctp.initialising_chunk_proc_limit 以上に強制さ
れます。大きな値は、DoS のリスクがありますが、小さな値を設定する
ことは、パケット中の重要な制御チャンクが位置付けられられず、解析
されない結果となります。
net.inet.ip.alias.sctp.error_on_ootb: 1
nat が、ErrorM パケットで任意の Out-of-the-Blue (OOTB) パケットに
応答するとき、定義します。OOTB パケットは、nat で登録された存在し
ない関連付けで到着するパケットであり、INIT または ASCONF-AddIP パ
ケットではありません:
0 ErrorM は、OOTB パケットに応答して決して送信されません。
1 ErrorM は、ローカル側で受信された OOTB パケットに送信され
るだけです。
2 ErrorM は、ローカル側に送信され、グローバル側では、部分的
な一致がある場合のみ (ポートと vtags は、一致しますが、発
信元のグローバルな IP は、一致しません)、送信されます。こ
の値は、nat がグローバル IP アドレスを追跡している場合に
だけ、役に立ちます。
3 ErrorM は、ローカル側とグローバル側の両方で (DoS のリス
ク) すべての OOTB パケットに応答して送信されます。
ErrorM パケットは、ほとんどの SCTP スタックによってまだサポートさ
れていないので、現在のところ、デフォルトは 0 です。それがサポート
されるとき、グローバルなアドレスを追跡しないなら、マルチホームの
ローカルホストが nat で機能できるようにするために、この値を 1 に
設定することを勧めます。グローバルなアドレスを追跡するために、グ
ローバルなホストが、ASCONF-AddIP を (再) 送信する必要があるとき、
それらを、通知できるように、この値を 2 に設定することを勧めます。
nat がすべての OOTB のグローバルなパケット (DoS のリスク) に応答
するように、値 3 は、(デバッグのため以外に) 決して選択されるべき
ではありません。
net.inet.ip.alias.sctp.hashtable_size: 2003
nat 検索 (100 < prime_number > 1000001) のために使用されるハッ
シュテーブルのサイズ。この値は、将来に作成される nat インスタンス
のための hash table (ハッシュテーブル) サイズを設定します、した
がって、nat インスタンスを作成する前に、設定されなければなりませ
ん。テーブルサイズは、特定の必要性に適合するように変更されるかも
しれません。並列アソシエーションがわずかしかなく、メモリが十分で
ないなら、利用者は、これらをより小さくすることができます。数千
(または、数百万) の並列アソシエーションがあるなら、利用者は、これ
らをより大きくするべきです。テーブルサイズのためにいは、素数が、
最も良いです。sysctl 更新関数は、次の最も大きな素数に入力値を調整
します。
net.inet.ip.alias.sctp.holddown_time: 0
SHUTDOWN-COMPLETE を受信した後に、この何秒のためのテーブルのアソ
シエーションを保持します。これによって、終点は、shutdown_complete
が失われ、再伝送が必要であるなら、素直にシャットダウンを修正でき
ます。
net.inet.ip.alias.sctp.init_timer: 15
(INIT-ACK|AddIP-ACK) を待つ間のタイムアウト値。この値は、0 であっ
てはなりません。
net.inet.ip.alias.sctp.initialising_chunk_proc_limit: 2
そのパケットに一致しない既存のアソシエーションが存在しないとき、
解析される SCTP パケットのチャンクの最大数を定義します。理想的に
は、このパケットは、ちょうど INIT または ASCONF-AddIP パケットに
なるはずです。より大きな値は、不正な形式のパケットが処理のリソー
スを消費できるので、DoS のリスクになるかもしれません。
net.inet.ip.alias.sctp.param_proc_limit: 25
パケットで解析されるチャンク内のパラメータの最大数を定義します。
他の sysctl 変数と同様に、大きい値は、DoS のリスクを引き起こしま
す。
net.inet.ip.alias.sctp.log_level: 0
システムログメッセージの詳細のレベル (0 - 最小量、1 - イベント、2
- 情報、3 - 詳細、4 - デバッグ、5 - 最大デバッグ)。高い損失の環境
において役に立つオプションです。
net.inet.ip.alias.sctp.shutdown_time: 15
SHUTDOWN-COMPLETE を待つ間のタイムアウト値。この値は、0 であって
はなりません。
net.inet.ip.alias.sctp.track_global_addresses: 0
nat 内で追跡されるグローバル IP アドレスを、有効/無効にし、各アソ
シエーションのために追跡されるアドレスの数の上限を設けます。
0 グローバルな追跡は、無効にされています。
>1 追跡、各アソシエーションがこの値に制限されるための追跡さ
れたアドレスの最大数を有効にします。
この変数は、完全に動的で、新しい値は、すべての新たに到着するアソ
シエーションに採用され、既存のアソシエーションは、以前のように取
り扱われます。グローバルな追跡は、増強された処理負荷、メモリの使
用量、複雑さ、と複数の nat で複合ネットワークで、あり得る nat の
状態の問題のコストにおいて、nat 内の衝突の数を減少させます。グ
ローバル IP アドレスを追跡しないことをお勧めします、これはまた、
完全に機能的な nat の結果となります。
net.inet.ip.alias.sctp.up_timer: 300
トラフィックなしのアソシエーションを維持するタイムアウト値。この
値は、0 であってはなりません。
net.inet.ip.dummynet.codel.interval: 100000
マイクロ秒単位のデフォルトの codel インターバル。値は、範囲
1..5000000 でなければなりません。
net.inet.ip.dummynet.codel.target: 5000
マイクロ秒単位のデフォルトの codel AQM ターゲットの遅延 (最小の受
け付け可能な持続的なキューの遅延)。値は、範囲 1..5000000 でなけれ
ばなりません。
net.inet.ip.dummynet.expire: 1
いったん動的なパイプ/キューに保留中のトラフィックがないと、ゆっく
りそれらを削除します。利用者は、変数を 0 に設定することによってこ
れを無効にすることができ、その場合に、パイプ/キューは、閾値に到着
するときのみ削除されます。
net.inet.ip.dummynet.fqcodel.flows: 1024
fq_codel が作成して、管理するフローキュー (サブキュー) のデフォル
トの合計数を定義します。値は、範囲 1..65536 でなければなりませ
ん。
net.inet.ip.dummynet.fqcodel.interval: 100000
マイクロ秒単位のデフォルトの fq_codel スケジューラ/AQM インターバ
ル。値は、範囲 1..5000000 でなければなりません。
net.inet.ip.dummynet.fqcodel.limit: 10240
fq_codel スケジューラのインスタンスによって管理されたすべての
キューのデフォルトの (パケットの単位の) ハードサイズの制限。値
は、範囲 1..20480 でなければなりません。
net.inet.ip.dummynet.fqcodel.quantum: 1514
バイトの単位の fq_codel のデフォルト量 (クレジット)。値は、範囲
1..9000 でなければなりません。
net.inet.ip.dummynet.fqcodel.target: 5000
マイクロ秒単位のデフォルトの fq_codel スケジューラ/AQM ターゲット
の遅延時間 (最小の受け付け可能な持続的なキューの遅延)。値は、範囲
1..5000000 でなければなりません。
net.inet.ip.dummynet.fqpie.alpha: 125
fq_pie スケジューラ/AQM のためのデフォルト alpha パラメータ (1000
によって基準にされる)。値は、範囲 1..7000 でなければなりません。
net.inet.ip.dummynet.fqpie.beta: 1250
fq_pie スケジューラ/AQM のためのデフォルトの beta パラメータ
(1000 によって基準にされる)。値は、範囲 1..7000 でなければなりま
せん。
net.inet.ip.dummynet.fqpie.flows: 1024
fq_pie が作成し、管理するフローキューの (サブキュー) のデフォルト
の合計数を定義します。値は、範囲 1..65536 でなければなりません。
net.inet.ip.dummynet.fqpie.limit: 10240
fq_pie スケジューラのインスタンスによって管理されたすべてのキュー
のデフォルトの (パケットの単位の) ハードサイズの制限。値は、範囲
1..20480 でなければなりません。
net.inet.ip.dummynet.fqpie.max_burst: 150000
fq_pie スケジューラ/AQM が、パケットを落す/マークするマイクロ秒単
位のデフォルトの最大期間。値は、範囲 1..10000000 でなければなりま
せん。
net.inet.ip.dummynet.fqpie.max_ecnth: 99
fq_pie スケジューラ/AQM のためのデフォルトの (1000 によって基準と
される) 最大 ECN 可能性のしきい値。値は、範囲 1..7000 でなければ
なりません。
net.inet.ip.dummynet.fqpie.quantum: 1514
バイトの単位の fq_pie のデフォルトの量 (クレジット)。値は、範囲
1..9000 でなければなりません。
net.inet.ip.dummynet.fqpie.target: 15000
マイクロ秒の単位の fq_pie のデフォルト target の遅延。値は、範囲
1..5000000 でなければなりません。
net.inet.ip.dummynet.fqpie.tupdate: 15000
マイクロ秒の単位の fq_pie のデフォルトの tupdate。値は、範囲
1..5000000 でなければなりません。
net.inet.ip.dummynet.hash_size: 64
動的なパイプ/キューのために使用されるハッシュテーブルのデフォルト
のサイズ。この値は、パイプ/キューを設定するとき、buckets オプショ
ンが指定されないとき、使用されます。
net.inet.ip.dummynet.io_fast: 0
0 以外に設定されるなら、dummynet 操作 (上記参照) の ``fast'' モー
ドは、有効にされます。
net.inet.ip.dummynet.io_pkt
dummynet に渡されるパケットの数。
net.inet.ip.dummynet.io_pkt_drop
dummynet によって落されたパケットの数。
net.inet.ip.dummynet.io_pkt_fast
dummynet スケジューラによってバイパス (迂回) させたパケットの数。
net.inet.ip.dummynet.max_chain_len: 16
ハッシュバケット (hash bucket) のパイプ/キューの最大の数のための
ターゲット値。積 max_chain_len*hash_size は、空のパイプ/キューが
net.inet.ip.dummynet.expire=0 のときさえ期限切れになる閾値を決定
するために使用されます。
net.inet.ip.dummynet.red_lookup_depth: 256
net.inet.ip.dummynet.red_avg_pkt_size: 512
net.inet.ip.dummynet.red_max_pkt_size: 1500
RED アルゴリズムのために落される確立の計算で使用されるパラメー
タ。
net.inet.ip.dummynet.pie.alpha: 125
pie AQM のためのデフォルトの alpha パラメータ (1000 単位の測定)。
値は、範囲 1..7000 でなければなりません。
net.inet.ip.dummynet.pie.beta: 1250
pie AQM のためのデフォルトの beta パラメータ (1000 単位の測定)。
値は、範囲 1..7000 でなければなりません。
net.inet.ip.dummynet.pie.max_burst: 150000
pie AQM がパケットを落さない/マークしない、マイクロ秒のデフォルト
最大期間。値は、範囲 1..10000000 でなければなりません。
net.inet.ip.dummynet.pie.max_ecnth: 99
pie AQM のためのデフォルト最大の ECN の可能性のある閾値 (1000 単
位の測定)。値は、範囲 1..7000 でなければなりません。
net.inet.ip.dummynet.pie.target: 15000
マイクロ秒の単位の pie AQM のデフォルトの target の遅延。値は、範
囲 1..5000000 でなければなりません。
net.inet.ip.dummynet.pie.tupdate: 15000
マイクロ秒の単位の pie AQM のデフォルトの tupdate。値は、範囲
1..5000000 でなければなりません。
net.inet.ip.dummynet.pipe_byte_limit: 1048576
net.inet.ip.dummynet.pipe_slot_limit: 100
バイト単位またはパケット数で指定できる最大のキューサイズ。これら
の制限は、mbufs のようなリソースの偶然の枯渇を防ぎます。これらの
制限を上げるなら、十分なリソースが利用可能とできるように、システ
ムが設定されることを確実にするべきでです。
net.inet.ip.fw.autoinc_step: 100
それらを自動生成するときの規則番号の間のデルタ。値は、範囲
1..1000 でなければなりません。
net.inet.ip.fw.curr_dyn_buckets: net.inet.ip.fw.dyn_buckets
動的な規則のためのハッシュテーブルのバケット現在の数 (読み込み専
用)。
net.inet.ip.fw.debug: 1
ipfw によって生成されるデバッグメッセージを制御します。
net.inet.ip.fw.default_rule: 65535
デフォルトの規則番号 (読み込み専用)。ipfw の設計によって、デフォ
ルトの規則は、最後のものであるので、規則に許された最も大きい番号
として、その番号を使用することができます。
net.inet.ip.fw.dyn_buckets: 256
動的な規則のためのハッシュテーブルのバケットの数。最大 65536 まで
の、2 の冪乗でなければなりません。すべての動的な規則が期限切れに
なったときにみ、効果が生じるだけであるので、利用者は、ハッシュ
テーブルがリサイズされることを確かめるために、flush コマンドを使
用するようにアドバイスされます。
net.inet.ip.fw.dyn_count: 3
動的な規則の現在の数 (読み込み専用)。
net.inet.ip.fw.dyn_keepalive: 1
TCP セッションで keep-state 規則のためのキープアライブ
(keepalive) パケットの生成を有効にします。キープアライブ
(keepalive) は、規則の存続期間の最後の 20 秒に対して 5 秒ごとに接
続の両側に生成されます。
net.inet.ip.fw.dyn_max: 8192
動的規則の最大数。利用者が、この制限に達するとき、古いものが期限
切れになるまで、これ以上動的な規則をインストールすることはできま
せん。
net.inet.ip.fw.dyn_ack_lifetime: 300
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_fin_lifetime: 1
net.inet.ip.fw.dyn_rst_lifetime: 1
net.inet.ip.fw.dyn_udp_lifetime: 5
net.inet.ip.fw.dyn_short_lifetime: 30
これらの変数は、秒単位で動的な規則の存続期間を制御します。初期の
SYN 交換で、存続期間が短くされ、次に両方の SYN が見られる後に増加
され、次に最終の FIN 交換の間に、または RST が受信されるとき、再
び減少されます。dyn_fin_lifetime と dyn_rst_lifetime の両方は、
キープアライブの反復の期間に、厳密に 5 秒より短くなければなりませ
ん。ファイアウォールは、それを強制します。
net.inet.ip.fw.dyn_keep_states: 0
規則/セットの削除で動的な状態を維持します。状態は、デフォルトの規
則に再リンクされます (65535)。これは、再ロードされた規則セットの
ために手軽です。デフォルトでオフにされます。
net.inet.ip.fw.enable: 1
ファイアウォールを有効にします。この変数を 0 に設定することによっ
て、たとえコンパイルされていたとしても、ファイアウォールのない利
用者のマシンで実行します。
net.inet6.ip6.fw.enable: 1
IPv6 の場合について、上記と同じ機能性を提供します。
net.inet.ip.fw.one_pass: 1
設定されるとき、dummynet のパイプから、または ng_ipfw(4) ノードか
ら出ているパケットは、再び、ファイアウォールを通過しません。そう
でなければ、アクションの後に、パケットは、次の規則でファイア
ウォールに再注入されます。
net.inet.ip.fw.tables_max: 128
テーブルの最大数。
net.inet.ip.fw.verbose: 1
冗長なメッセージを有効にします。
net.inet.ip.fw.verbose_limit: 0
冗長なファイアウォールによって生成されるメッセージの数を制限しま
す。
net.inet6.ip6.fw.deny_unknown_exthdrs: 1
有効にされるなら、未知の IPv6 拡張ヘッダがあるパケットが、拒否さ
れます。
net.link.ether.ipfw: 0
レイヤ 2 のパケットが、ipfw に渡されるかどうかを制御します。デ
フォルトは、no です。
net.link.bridge.ipfw: 0
ブリッジされたパケットが ipfw に渡されるかどうかを制御します。デ
フォルトは、no です。
net.inet.ip.fw.nat64_debug: 0
ipfw_nat64 モジュールによって生成されるデバッグメッセージを制御し
ます。
net.inet.ip.fw.nat64_direct_output: 0
ipfw_nat64 モジュールによって使用された出力方法を制御します:
0 パケットは、ipfw によって 2 度処理されます。最初に、オリ
ジナルのパケットは、ipfw によって処理され、ipfw_nat64 ト
ランスレータによって消費されます。次に、変換されたパケッ
トは、再び処理されている入力への netisr を通してキューに
入れられます。
1 パケットは、ipfw によってただ 1 度だけ処理され、変換の後
に、それは、発信するインタフェースに直接プッシュされま
す。
内部診断
カーネルモジュールの内部の特定のサブシステムの現在の状態を理解するために
役に立ついくつかのコマンドがあります。これらのコマンドは、予告なしに変更
するるかもしれないデバッグ出力を提供しています。
現在、次のコマンドは、internal サブオプションとして利用可能です:
iflist それらのカーネル内状態で ipfw によって現在追跡されるすべてのイン
タフェースをリストします。
talist 現在利用可能なすべてのテーブル検索アルゴリズムをすべてリストしま
す。
使用例
ipfw のあまりにも多くの可能な使用法があるので、このセクションは、使用例の
小さいセットだけを与えます。
基本的なパケットのフィルタリング
次のコマンドは、cracker.evil.org からホストによって転送されることから、
wolf.tambov.su の telnet ポートへのすべての tcp パケットを拒否するエント
リを追加します:
ipfw add deny tcp from cracker.evil.org to wolf.tambov.su telnet
これは、すべてのクラッカーのネットワークから my ホストへのあらゆる接続を
許可しません:
ipfw add deny ip from 123.45.67.0/24 to my.host.org
最初に、(動的規則を使用せずに) アクセスを制限する効率的な方法は、次の規則
を使用することです:
ipfw add allow tcp from any to any established
ipfw add allow tcp from net1 portlist1 to net2 portlist2 setup
ipfw add allow tcp from net3 portlist3 to net3 portlist3 setup
...
ipfw add deny tcp from any to any
最初の規則は、通常の TCP パケットのために素早く一致しますが、それは、選択
された発信元/宛先のペアのためだけに setup 規則によって一致される、初期の
SYN パケットと一致しません。すべての他の SYN パケットは、最終的な deny
(拒否) 規則によって拒絶されます。
1 つ以上のサブネットの管理者であるなら、アドレスセットと論理和 (OR) ブ
ロックをうまく利用し、下記のように、クライアントのブロックへのサービスを
選択的に有効にする非常にコンパクトな規則セットを記述することができます。
goodguys="{ 10.1.2.0/24{20,35,66,18} or 10.2.3.0/28{6,3,11} }"
badguys="10.1.2.0/24{8,38,60}"
ipfw add allow ip from ${goodguys} to any
ipfw add deny ip from ${badguys} to any
... normal policies ...
規則セットの先頭に次を追加することによって、自動的な抗なりすまし (anti
spoofing) を行うために verrevpath オプションを使用することができます:
ipfw add deny ip from any to any not verrevpath in
この規則は、誤ったインタフェースのシステムに来るように思える着信パケット
をすべて落とします。例えば、保護された内部のネットワークのホストに属して
いる発信元アドレスがあるパケットは、外部のインタフェースからシステムに入
ろうと試みるなら、落とされます。
antispoof オプションは、同様に行いますが、規則セットの先頭に続いて追加す
ることによってスプーフィングに対抗する (anti-spoofing) ことをより制限する
ために使用されるかもしれません:
ipfw add deny ip from any to any not antispoof in
この規則は、間違ったインタフェースを除いて、別の直接接続しているシステム
から、来ているように見えるすべての着信パケットを落とします。例えば、fxp1
で着信するけれども、fxp0 で設定された 192.168.0.0/24 のソースアドレスがあ
るパケットは、落とされます。
規則セットの適切な場所に次を追加することによって、ユーザのトラフィックを
(再)マークするために setdscp オプションを使用できるかもしれません:
ipfw add setdscp be ip from any to any dscp af11,af21
選択的なミラーリング
利用者のネットワークに専門のインタフェースを通して利用者のホストと直接接
続されるか、または RSPAN vlan を通してリモートに接続されたネットワークト
ラフィックアナライザ (analyzer) があるなら、利用者は、アナライザにいくつ
かのイーサット layer2 フレームを選択的にミラーリングすることができます。
最初に、利用者のファイアウォールが既に設定され、実行することを確かめま
す。次に、すでに有効でなかったなら、layer2 処理を有効にします:
sysctl net.link.ether.ipfw=1
次に、追加のカーネルモジュールを必要とするロードは、次の通りです:
kldload ng_ether ng_ipfw
オプションで、システムがスタートアップで、これらのモジュールを自動的に
ロードするようにします:
sysrc kld_list+="ng_ether ng_ipfw"
次に、vlan900 インタフェースを通して layer2 フレームのミラーリングされて
いるコピーを転送するために、ng_ipfw(4) カーネルモジュールを設定します:
ngctl connect ipfw: vlan900: 1 lower
"ミラーリングインスタンスインデックス (mirroring instance index)" と
vlan900 現在で、ここの "1" の考えは、その宛先です。利用者は、インスタンス
の任意の数を持つことができます。詳細については、ng_ipfw(4) を参照してくだ
さい。
最後に、実際、選択されたフレームのミラーリングが "インスタンス 1" を使用
して開始します。em0 インタフェースからの着信してくるフレームについては:
ipfw add ngtee 1 ip from any to 192.168.0.1 layer2 in recv em0
em0 インタフェースへの発信するフレームについては:
ipfw add ngtee 1 ip from any to 192.168.0.1 layer2 out xmit em0
em0 を通して流れる間に、着信してくるフレームと発信するフレームの両方につ
いては:
ipfw add ngtee 1 ip from any to 192.168.0.1 layer2 via em0
利用者が、すでに複写されたフレームのためのミラーリングを実行しないか、ま
たは安全なネットがないのでカーネルがハングアップするかもしれないことを確
かめてください。
動的規則
偽造の TCP パケットを含んでいるフラッド攻撃 (flood attack) からサイトを保
護するために、次の動的規則を使用することがより安全です:
ipfw add check-state
ipfw add deny tcp from any to any established
ipfw add allow tcp from my-net to any setup keep-state
これは、ネットワークの内側から来る通常の SYN パケットで始まる、それらの接
続のためだけに動的規則をファイアウォールにインストールさせます。動的規則
は、check-state, keep-state または limit 規則の最初の発生に遭遇したときに
チェックされます。check-state 規則は、通常、規則セットをスキャンしている
仕事の量を最小にするために、規則セットの最初の近くに置かれるべきです。利
用者のマイレージは、変わるかもしれません。訳注: 意味不明。
動的な規則がある複雑なシナリオのために、作成と動的な規則のチェックを正確
に制御するために、record-state と defer-action を使用することができます。
これらのオプションの使用法の例は、「ネットワークアドレス変換 (NETWORK
ADDRESS TRANSLATION (NAT))」セクションで提供されています。
ユーザがオープンすることができる接続の数を制限するために、利用者は、次の
規則のタイプを使用することができます:
ipfw add allow tcp from my-net/24 to any setup limit src-addr 10
ipfw add allow tcp from any to me setup limit src-addr 4
前者 (ゲートウェイで実行することを仮定します) は、多くても 10 回の TCP 接
続をオープンする /24 ネットワークの各ホストを許可します。単一のクライアン
トが 4 回を超える同時の接続を使用しないことを確かめるために、サーバに後者
を置くことができます。
警戒: 動的な規則の莫大な数をオープンする SYN-flood によるサービス拒否
(denial-of-service) 攻撃に、ステートフル規則を受けることができます。ファ
イアウォールの操作を制御する sysctl(8) 変数の設定で動作している、そのよう
な攻撃の効果を部分的に制限することができます。
ここで、アカウントの記録とタイムスタンプ情報を見るための list コマンドの
よい使用例を示します:
ipfw -at list
または、要するに、タイムスタンプなしは、次の通りです:
ipfw -a list
これは、次のものと同等です:
ipfw show
次の規則は、ポート 5000 に迂回するために 192.168.2.0/24 からすべての着信
パケットを迂回します:
ipfw divert 5000 ip from 192.168.2.0/24 to any in
トラフィックの状態
次の規則は、シミュレーションと同類のもののために ipfw と dummynet のアプ
リケーションのいくつかを表示します。
この規則は、5% の確立でランダムな着信パケットを落とします:
ipfw add prob 0.05 deny ip from any to any in
dummynet パイプを使用することで、同様な効果を達成することができます:
ipfw add pipe 10 ip from any to any
ipfw pipe 10 config plr 0.05
帯域幅を人工的に制限するためにパイプを使用することができます、例えば、
ルータとして動作しているマシンで、192.168.2.0/24 のローカルなクライアント
からトラフィックを制限したいなら、次のように行います:
ipfw add pipe 1 ip from 192.168.2.0/24 to any out
ipfw pipe 1 config bw 300Kbit/s queue 50KBytes
規則が 2 度使用できないように、out 修飾子を使用することに注意してくださ
い。実際に ipfw 規則は、着信と発信パケットの両方をチェックされることを覚
えていてください。
バンド幅の制限がある双方向リンクをシミュレートするなら、正確な方法は、次
の通りです:
ipfw add pipe 1 ip from any to any out
ipfw add pipe 2 ip from any to any in
ipfw pipe 1 config bw 64Kbit/s queue 10Kbytes
ipfw pipe 2 config bw 64Kbit/s queue 10Kbytes
例えば、利用者が、装飾的な Web ページが、遅いリンクだけを通して接続されて
いる在宅のユーザがどのように検索するかを確かめたいたいなら、上記は、非常
に役に立つかもしれません。利用者は、半二重のメディア (例えば、AppleTalk、
イーサネット、IRDA) をシミュレートしたくないなら、両方の方向のためだけに
1 つのパイプを使用するべきではありません。両方のパイプが同じ設定である必
要がないので、非対称なリンクもシミュレートすることができます。
RED キュー管理アルゴリズムでネットワーク性能を検証するならば、次の通りで
す:
ipfw add pipe 1 ip from any to any
ipfw pipe 1 config bw 500Kbit/s queue 100 red 0.002/30/80/0.1
トラフィックシェイパの別の典型的なアプリケーションは、通信でいくらかの遅
延を導入することです。これは、接続の往復時間がしばしばバンド幅をはるかに
越えている制限ファクタとなるところで、多くのリモートプロシージャコール
(Remote Procedure Calls) を行なうアプリケーションにかなり影響するかもしれ
ませんい
ipfw add pipe 1 ip from any to any out
ipfw add pipe 2 ip from any to any in
ipfw pipe 1 config delay 250ms bw 1Mbit/s
ipfw pipe 2 config delay 250ms bw 1Mbit/s
フローごとのキューは、さまざまな目的のために役に立つことができます。非常
に簡単なものは、次のトラフィックをカウントしています:
ipfw add pipe 1 tcp from any to any
ipfw add pipe 1 udp from any to any
ipfw add pipe 1 ip from any to any
ipfw pipe 1 config mask all
上記の規則のセットは、すべてのトラフィックに対してキューを作成し (統計を
収集し) ます。パイプには制限がないので、唯一の効果は、統計を収集すること
です。ipfw が IP パケットを照合することを試みるとき、ポートを考慮しないの
で、違うものとして個別のポートでの接続と見なさないので、まさに最後の規則
ではなく、3 つの規則が必要であることに注意してください。
より洗練された例は、ネットワークごとの制限ではなく、ホストごとの制限があ
るネットで外向きのトラフィックを制限しています:
ipfw add pipe 1 ip from 192.168.2.0/24 to any out
ipfw add pipe 2 ip from any to 192.168.2.0/24 in
ipfw pipe 1 config mask src-ip 0x000000ff bw 200Kbit/s queue
20Kbytes
ipfw pipe 2 config mask dst-ip 0x000000ff bw 200Kbit/s queue
20Kbytes
検索テーブル
次の例では、いくつかのトラフィック帯域幅のクラスを作成する必要があり、異
なったホスト/ネットワークを異なったクラスにする必要があります。各クラスご
とに 1 つのパイプを作成し、それぞれそれらを設定します。次に、1 つのテーブ
ルを作成し、IP サブネットとアドレスをそれに書き込みます。各サブネット/ホ
ストのために、それが使用するべきであるパイプの数と同じ数の引数を設定しま
す。次に、1 つの規則を使用してトラフィックを分類します:
ipfw pipe 1 config bw 1000Kbyte/s
ipfw pipe 4 config bw 4000Kbyte/s
...
ipfw table T1 create type addr
ipfw table T1 add 192.168.2.0/24 1
ipfw table T1 add 192.168.0.0/27 4
ipfw table T1 add 192.168.0.2 1
...
ipfw add pipe tablearg ip from 'table(T1)' to any
fwd アクションを使用して、テーブルエントリは、ホスト名と IP アドレスを含
むことができます。
ipfw table T2 create type addr ftype ip
ipfw table T2 add 192.168.2.0/24 10.23.2.1
ipfw table T21 add 192.168.0.0/27 router1.dmz
...
ipfw add 100 fwd tablearg ip from any to table(1)
次の例で、インタフェースごとのファイアウォールが作成されます:
ipfw table IN create type iface valtype skipto,fib
ipfw table IN add vlan20 12000,12
ipfw table IN add vlan30 13000,13
ipfw table OUT create type iface valtype skipto
ipfw table OUT add vlan20 22000
ipfw table OUT add vlan30 23000
..
ipfw add 100 setfib tablearg ip from any to any recv 'table(IN)' in
ipfw add 200 skipto tablearg ip from any to any recv 'table(IN)' in
ipfw add 300 skipto tablearg ip from any to any xmit 'table(OUT)'
out
次の例は、flow テーブルの使用法を説明しています:
ipfw table fl create type flow:src-ip,proto,dst-ip,dst-port
ipfw table fl add 2a02:6b8:77::88,tcp,2a02:6b8:77::99,80 11
ipfw table fl add 10.0.0.1,udp,10.0.0.2,53 12
..
ipfw add 100 allow ip from any to any flow 'table(fl,11)' recv ix0
規則セット
規則セットを不可分に追加するためには、次の通りです、例えば、セット 18:
ipfw set disable 18
ipfw add NN set 18 ... # 必要に応じて繰り返す
ipfw set enable 18
規則セットを不可分に削除するためには、コマンドは、単に次の通りです: To
delete a set of rules atomically the command is simply:
ipfw delete set 18
規則セットをテストし、それを無効にし、何かうまく行かない場合に、制御を回
復するためには、次の通りです:
ipfw set disable 18
ipfw add NN set 18 ... # 必要に応じて繰り返す
ipfw set enable 18; echo done; sleep 30 && ipfw set disable 18
ここで、すべてがうまくいくなら、利用者は、"sleep" が終了する前に、con
trol-C を押し、利用者の規則セットは、アクティブなままとなります。そうでけ
れば、例えば、利用者が利用者のボックスにアクセスできないなら、規則セット
は、スリープが終了した後に無効にされ、したがって、以前の状況を復元しま
す。
特定のセットの規則を表示するためには:
ipfw set 18 show
無効にされた規則を表示するためには:
ipfw -S set 18 show
特定のセットの特定の規則のカウンタをクリアするためには:
ipfw set 18 zero NN
特定のセットの特定の規則を削除するためには:
ipfw set 18 delete NN
NAT, リダイレクトと LSNAT
最初に、nat インスタンス 123 へのすべてのトラフィックをリダイレクトしま
す:
ipfw add nat 123 all from any to any
次に、IP 192.168.0.123 ですべての発信トラフィックをエイリアスするために
nat インスタンス 123 を設定するためには、次のように、すべての着信接続をブ
ロックし、両側の同じポートを保持することを試み、アドレスの変更でエイリア
シングテーブルをクリアして、トラフィック/リンク統計のログを保持します。
ipfw nat 123 config ip 192.168.0.123 log deny_in reset same_ports
または、インスタンス 123 のアドレスを変更するるためには、エイリアシング
テーブルを、クリアします (リセットオプションを参照):
ipfw nat 123 config ip 10.0.0.1
nat インスタンス 123 の設定を見るためには:
ipfw nat 123 show config
範囲 111-999 のすべてのインスタンスのログを表示するためには:
ipfw nat 111-999 show
すべてのインスタンスの設定を見るためには:
ipfw nat show config
または、mixed モードでリダイレクトの規則は、次のようになるでしょう:
ipfw nat 123 config redirect_addr 10.0.0.1 10.0.0.66
redirect_port tcp 192.168.0.1:80 500
redirect_proto udp 192.168.1.43 192.168.1.1
redirect_addr 192.168.0.10,192.168.0.11
10.0.0.100 # LSNAT
redirect_port tcp 192.168.0.1:80,192.168.0.10:22
500 # LSNAT
または、次のように分割することができるでしょう:
ipfw nat 1 config redirect_addr 10.0.0.1 10.0.0.66
ipfw nat 2 config redirect_port tcp 192.168.0.1:80 500
ipfw nat 3 config redirect_proto udp 192.168.1.43 192.168.1.1
ipfw nat 4 config redirect_addr 192.168.0.10,192.168.0.11,192.168.0.12
10.0.0.100
ipfw nat 5 config redirect_port tcp
192.168.0.1:80,192.168.0.10:22,192.168.0.20:25 500
時々、利用者は、NAT と動的な規則を混ぜたいかもしれません。それは, record-
state と defer-action オプションでアーカイブされるかもしれません。問題
は、利用者が、NAT の前に動的な規則を作成する必要があり、一貫したアドレス
とポートがある NAT アクション (または逆もまた同様) の後に、それをチェック
します。keep-state オプションがある規則は、既存の動的な状態の活性化を引き
起こし、そのような規則のアクションは、規則が一致するとすぐに実行されま
す。NAT の場合に、allow 規則パケットが NAT に渡される必要があり、すぐに許
可されないことがあり得ます。
これをアーカイブする規則のセットの例があります。これは、例であり、それ
は、それ自体によってまさに訳に立たないことを覚えておいてください。
すべてのチェックが次の規則を置いた後に、出て行きます:
ipfw add allow record-state skip-action
ipfw add nat 1
そして、そこの方法で、つぎのような何かであるべきです:
ipfw add nat 1
ipfw add check-state
出て行く最初の規則は、パケットを許可せず、既存の動的な規則を実行しないこ
とに注意してください。それを行なう全ては、それが allow アクションで新しい
動的な規則を作成します。後で、この動的な規則は、途中で check-state 規則に
よって使用されます。
CODEL, PIE, FQ-CODEL と FQ-PIE AQM の設定
dummynet の pipe または queue のために codel と pie AQM を設定することが
できます。
192.168.0.0/24 と 1Mbits/s のレート (速度) 制限からトラフィックのためのデ
フォルト設定を使用して codel AQM で pipe を設定するためには、次のように行
ないます:
ipfw pipe 1 config bw 1mbits/s codel
ipfw add 100 pipe 1 ip from 192.168.0.0/24 to any
192.168.0.0/24 と 1Mbits/s のレート (速度) 制限からトラフィックのための異
なる設定パラメータを使用して codel AQM で queue を設定するためには、次の
ように行ないます:
ipfw pipe 1 config bw 1mbits/s
ipfw queue 1 config pipe 1 codel target 8ms interval 160ms ecn
ipfw add 100 queue 1 ip from 192.168.0.0/24 to any
192.168.0.0/24 と 1Mbits/s のレート (速度) 制限からトラフィックのためのデ
フォルトの設定を使用して pie AQM で pipe を設定するためには、次のように行
ないます:
ipfw pipe 1 config bw 1mbits/s pie
ipfw add 100 pipe 1 ip from 192.168.0.0/24 to any
192.168.0.0/24 と 1Mbits/s のレート (速度) 制限からトラフィックのための異
なる設定パラメータを使用して pie AQM で queue を設定するためには、次のよ
うに行ないます:
ipfw pipe 1 config bw 1mbits/s
ipfw queue 1 config pipe 1 pie target 20ms tupdate 30ms ecn
ipfw add 100 queue 1 ip from 192.168.0.0/24 to any
dummynet スケジューラのために fq_codel と fq_pie AQM を設定することができ
ます。
192.168.0.0/24 と 1Mbits/s のレート (速度) 制限からトラフィックのための異
なる設定パラメータを使用して fq_codel スケジューラを設定するためには、次
のように行ないます:
ipfw pipe 1 config bw 1mbits/s
ipfw sched 1 config pipe 1 type fq_codel
ipfw queue 1 config sched 1
ipfw add 100 queue 1 ip from 192.168.0.0/24 to any
無効の ECN と target を 10ms に変更するためのように、sched のための
fq_codel のデフォルトの設定を変更するためには、次のように行ないます:
ipfw sched 1 config pipe 1 type fq_codel target 10ms noecn
192.168.0.0/24 と 1Mbits/s のレート (速度) 制限からトラフィックのための異
なる設定パラメータを使用して fq_codel と似ている、fq_pie スケジューラを設
定するためには、次のように行ないます:
ipfw pipe 1 config bw 1mbits/s
ipfw sched 1 config pipe 1 type fq_pie
ipfw queue 1 config sched 1
ipfw add 100 queue 1 ip from 192.168.0.0/24 to any
fq_codel について同じ方法で fq_pie sched の設定を変更することができます。
関連項目
cpp(1), m4(1), altq(4), divert(4), dummynet(4), if_bridge(4), ip(4),
ipfirewall(4), ng_ether(4), ng_ipfw(4), protocols(5), services(5),
init(8), kldload(8), reboot(8), sysctl(8), syslogd(8), sysrc(8)
歴史
ipfw は、FreeBSD 2.0 ではじめて登場しました。dummynet は、FreeBSD 2.2.8
で導入されました。ステートフル拡張は、FreeBSD 4.0 で導入されました。ipfw2
は、2002 年夏に導入されました。
作者
Ugen J. S. Antsilevich,
Poul-Henning Kamp,
Alex Nash,
Archie Cobbs,
Luigi Rizzo,
Rasool Al-Saadi.
API は、BSDI のために Daniel Boulet によって書かれたコードに基づいていま
す。
dummynet は、1997-1998 年に Luigi Rizzo によって導入されました。
Akamba Corp によってサポートされた dummynet トラフィックシェイパでいくら
かの初期の作業 (1999-2000)。
ipfw コア (ipfw2) は、2002 年夏に Luigi Rizzo によって完全に再設計され、
再実装されました。更なるアクションとオプションは、数年間様々な開発者に
よって追加されました。
カーネル内 NAT サポートは、Summer of Code 2005 プロジェクトの一環として
Paolo Pisati <piso@FreeBSD.org> によって書かれました。
SCTP nat のサポートは、The Centre for Advanced Internet Architectures
(CAIA) <http://www.caia.swin.edu.au> によって開発されました。主要な開発者
とメンテナは、David Hayes and Jason But です。詳細については、次を訪問し
てください: <http://www.caia.swin.edu.au/urp/SONATA>
遅延のプロファイルは、Projects Onelab と Onelab2 内の European Commission
によってサポートされ、Alessandro Cerri と Luigi Rizzo によって開発されま
した。
dummynet のための CoDel, PIE, FQ-CoDel と FQ-PIE AQM は、The Comcast
Innovation Fund によってサポートされた 2016 年の The Centre for Advanced
Internet Architectures (CAIA) (高度インターネットアーキテクチャのためのセ
ンタ) によって実装されました。主要な開発者は、Rasool Al-Saadi です。
バグ
構文は、年月を重ねるにつれて成長しています、ときどき混乱させられるかもし
れません。残念ながら、後方互換性のために、構文の定義で行われた誤りを訂正
することができません。
!!! 警告 !!!
ファイアウォールを誤設定することは、利用者のコンピュータを使用できない状
態にして、シャットダウンしているネットワークサービスの可能性があり、その
制御を取り戻すためにコンソールアクセスを必要とします。
divert によって迂回される着信してくるパケットのフラグメントは、ソケットに
配信される前に再構成されます。それらのパケットで使用されるアクションは、
パケットの最初のフラグメントと一致している規則からのものです。
ユーザランドに向けられ、次に、ユーザランドのプロセスによって再び差し込ま
れるパケットは、様々なパケット属性を失うかもしれません。パケットの発信元
のインタフェース名は、8 バイト未満であり、ユーザランドのプロセスが、sock
addr_in を保存し、再利用するなら、(natd(8) として) 保存されます。そうでな
ければ、それは、失われるかもしれません。パケットがこの方法で再び差し込ま
れるなら、後の規則は、間違って適用され、規則のシーケンスで divert 規則の
順序を非常に重要なものとします。
dummynet は、IPv6 リンクローカルアドレスがあるすべてのパケットを落としま
す。
uid または gid を使用する規則は、予期するように振る舞いません。特に、着信
してくる SYN パケットは、それらがまだ TCP 接続に属していないので、それら
に関連する uid または gid がなく、パケットと関連した uid/gid は、関連する
プロセスが setuid(2) または同様なシステムコールを呼び出すなら、予想どうり
になりません。
規則構文は、コマンドライン環境に制約されており、いくつかのパターンは、
バックスラッシュ文字でエスケープされるか、または適切にクォートされる必要
があります。
libalias(3) のアーキテクチャのために、ipfw nat は、tcp セグメンテーション
オフローディング (tcp segmentation offloading (TSO)) と互換性がありませ
ん。したがって、利用者のネットワークトラフィックを確実に nat するために
は、ifconfig(8) を使用して NIC の TSO を無効にしてください。
ICMP エラーメッセージは、それぞれの通信のための動的な規則によって暗黙に照
合されません。ネットワークエラー検出とパス MTU 検索の失敗を避けるために、
ICMP エラーメッセージは、静的な規則を通して明白に許可される必要がありま
す。
call と return アクションを使用する規則は、規則セットに誤りがあるなら、混
乱した振る舞いを導くかもしれません、そして/または、他のサブシステム
(netgraph、dummynet など) との相互作用が、使用されます。これのための 1 つ
のあり得る事例は、後で最初に対になっていない return に遭遇する出力の間
に、入力パスでサブルーチンの ipfw から出るパケットです。呼び出しスタック
が入力パスの後にそのまま保持されるように、パケットは、出力パスでなく、入
力パスで使用される規則番号に突然戻ります。処理の順序は、そのような誤りを
避けるために注意深くチェックされるべきです。
FreeBSD 13.0 August 21, 2020 FreeBSD 13.0