日本語 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
ipfw [-cfnNqS] [-p preproc [preproc-flags]] pathname
ステートフル 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]
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 ユーティリティは、ipfw(4) ファイアウォール、dummynet(4) トラフィック
シェイパ/パケットスケジューラとカーネル内 NAT サービスを制御するための
ユーザインタフェースです。
ファイアウォールの設定、または規則セットは、1 から 65535 までの番号が付け
られた規則のリストでできています。パケットは、プロトコルスタック中の多く
の異なった場所からファイアウォールに渡されます (パケットの発信元と宛先に
よっては、ファイアウォールが同じパケットで複数回起動される可能性がありま
す)。ファイアウォールに渡されたパケットは、規則番号の順序で、規則セット中
のそれぞれの規則に対して比較されます (同じ数がある複数の規則が許可されま
す、その場合、それらは、挿入された順序で処理されます)。マッチしたとき、
マッチする規則に対応するアクションが実行されます。
アクションと特定のシステム設定によって、さらなる処理に対して一致するもの
の後に、いくつかの規則でファイアウォールにパケットを再投入することができ
ます。
規則セットは、修正または削除することができず、すべてのパケットと一致する
(65535 と番号が付けられる) デフォルトの規則を常に含んでいます。デフォルト
の規則に関連したアクションは、カーネルがどのように設定されるかに依存して
deny または allow のいずれかを指定できます。
規則セットが keep-state または limit オプションがある 1 つ以上の規則を含
んでいるなら、ファイアウォールには、ステートフル (状態依存型) の振る舞い
があります、すなわち、マッチにおいて動的規則を作成します、すなわち、それ
らの作成を引き起こしたパケットとして同じ 5 つの組 (プロトコル、発信元と宛
先アドレスおよびポート) があるパケットとマッチする規則。生存時間が有限で
ある動的規則は、check-state, keep-state または limit 規則の最初に生じた時
点でチェックされ、正当なトラフィックのみをオンデマンドで、ファイアウォー
ルをオープンするために通常使用されます。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 リストするとき、静的な規則に加えて動的な規則を表示します。
-e リストして、-d 指定されるとき、期限切れの動的な規則も表示します。
-f 御用されるとき、すなわち、flush、問題を起こすかもしれないコマンド
に対して確認を問い合わせません、プロセスに関連する tty がないな
ら、これは、暗黙に意味されます。
-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 回の範囲で変動します。
パケットがスタックを通過するにつれヘッダが削除 / 追加される可能性があり、
ヘッダがチェックに使えたり使えなかったりすることに注意して下さい。例え
ば、外から入ってくるパケットは、ether_demux() から ipfw が実行されるとき
には、MAC ヘッダを含んでいるはずですが、その同じパケットが、ip_input() ま
たは ip6_input() から ipfw が実行されたときには、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 とを区別する方法はありま
せん)。
文法
一般に、各キーワードもしくは引数は、別々のコマンド行引数として与えられ、
その前や後には空白は付きません。キーワードは、大文字小文字を区別します
が、引数は、その性質に依存し、大文字小文字を区別するかもしれませんし、し
ないかもしれません (例えば uid は、区別しますが、hostname は、しません)。
いくつかの引数 (例えば、ポートまたはアドレスのリスト) は、コンマで区切ら
れた値のリストです。この場合は、コンマ ',' の後の空白は、行をより読み易く
することができます。また、コマンド全体 (フラグを含む) を、単一引数に入れ
られます。例えば、次の書式は、等価です:
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 ヘッダフィールド バージョン、サービスタイプ、デー
タグラム長、識別子、フラグメント
フラグ (0 でない 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
各規則は、1 から 65535 の範囲の rule_number に関連づけられてお
り、後者は、デフォルト規則のために予約されています。規則は、規則
番号の順にチェックされます。複数の規則が同一の番号を持つことが可
能で、その場合は、追加された順序でチェックされます (表示する場合
も同様です)。番号の指定なしで規則が入力された場合、カーネルは、そ
の規則が、デフォルト規則より前にある規則の中で最後になるように割
り当てます。自動的につけられる規則番号は、デフォルトを除いた中で
最後となる規則番号を、sysctl 変数 net.inet.ip.fw.autoinc_step の
値だけ増加させて割り当てられます。この変数のデフォルトは、100 で
す。もし、この操作が (例えば許可された最大規則番号を越えるといっ
た理由で) 不可能であれば、最後のデフォルトでない値が代わりに使用
されます。
set set_number
各規則は、0 から 31 の範囲の set_number に関連づけられています。
セットは、個別に無効化したり有効化したりすることができます。した
がって、このパラメータは、不可分な規則セット操作を行うために必要
不可欠なものです。このパラメータを使うことで、規則をまとめて削除
することを単純にすることもできます。セット番号を指定せずに規則を
入力した場合、セット 0 が使用されます。
セット 31 は、特別であり、無効化できませんし、この中の規則は、
ipfw flush コマンドで削除できません (しかし、ipfw delete set 31
コマンドで削除するこはできます)。セット 31 は、また、デフォルト規
則としても使用されます。
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) が疑似インタフェースにアタッチされていなら、オーバヘッド
は、ありません。
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 トラフィック形成と無関係
です。
規則アクション
規則は、次に示すアクションの 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
(IPv6/IPv4 ネットワークアドレスとプロトコル変換のために) パケット
をステートレス NAT64 インスタンスに渡します: さらなる詳細について
は、「IPv6/IPv4 ネットワークアドレスとプロトコル変換」セクション
を参照してください。
nptv6 name
(IPv6 から IPv6 ネットワーク接頭辞変換のために) パケットを NPTv6
ンスタンスに渡します: 詳細については、「IPv6 から IPv6 ネットワー
ク接頭辞変換 (NPTv6)」セクションを参照してください。
pipe pipe_nr
パケットを dummynet ``パイプ'' (バンド幅制限、遅延などに使用され
ます) へ渡します。詳しい情報については、「トラフィックシェイパ
(DUMMYNET) 設定」セクションを参照してください。検索は、終了しま
す。しかし、パイプから抜けたときに sysctl(8) 変数
net.inet.ip.fw.one_pass がセットされていない場合、パケットは、す
ぐ次の規則から始まるファイアウォールコードへ再度渡されます。
queue queue_nr
パケットを dummynet ``キュー'' (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..64) によって DSCP 値を指
定することができます。また、setdscp がある tablearg キーワードを
使用することができます。tablearg 値が 0..64 の範囲内にないなら、
供給された下位 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 またはホスト名によって許可されるように指定され
る) 基本の addr と masklen ビットの幅をマスクするすべての
IPv6 アドレスを照合します。
addr/mask
(inet_pton またはホスト名によって許可されるように指定され
る) 基本の addr があるすべての IPv6 アドレスと inet_pton
によって許可されるように指定される 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) ブ
ロックを使用することにより、より広い範囲を指定することができま
す。
バックスラッシュ (`\') を使用することにより、サービス名中のダッ
シュ (`-') 文字をエスケープ可能です (シェルから入力するとき、シェ
ル自身がバックスラッシュをエスケープ文字として解釈するのをさける
ために、バックスラッシュを 2 回タイプしなければなりません)。
ipfw add count tcp from any ftp\\-data-ftp to any
0 でないオフセットがある、断片化された (すなわち、最初の破片でな
い) パケットは、1 つ以上のポート指定がある規則と決して一致しませ
ん。断片化されたパケットとの照合に関する詳細については、frag オプ
ションを参照してください。
規則オプション (適合パターン)
規則内で追加の適合パターンを使用することができます。これらは、規則内に 0
個以上置けるのでオプションと呼ばれており、オプションで not オペランドを前
置することができ、論理和 (OR) ブロックとしてグループ化することが可能で
す。
以下の適合パターンが使用できます (アルファベット順に並べています)。
// this is a comment.
指定したテキストを、規則中にコメントとして挿入します。// に続くす
べてがコメントとして扱われ、規則中に格納されます。コメントのみの
規則を持つことも可能であり、それは、count アクションに続いてコメ
ントが表示されます。
bridged
layer2 の別名です。
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), ルーティングヘッダタイプ 2 のモバイル
IPv6 (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) を持たないので、これらのヘッダを調べるオプショ
ンは、適合することができないことに注意して下さい。
gid group
group によって送信された、またはそれに対して受信された全ての TCP
もしくは UDP パケットに適合します。group は、名前か数値で指定する
ことができます。
jail prisonID
prison ID が prisonID である jail によって送信された、またはそれ
に対して受信された全ての TCP もしくは UDP パケットに適合します。
icmptypes types
types で指定したリスト中に存在する ICMP タイプを持つ 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 フィールドが id-list に含まれる IPv4 パケットに適合します。
id-list は、単一の値か、ports と同等の方法で指定される、値のリス
トか範囲です。
iplen len-list
ヘッダとデータを含んだ全体の長さが len-list に含まれる IP パケッ
トに適合します。len-list は、単一の値か、ports と同等の方法で指定
される、値のリストか範囲です。
ipoptions spec
spec で指定したコンマ区切りリストオプションを含む IPv4 ヘッダを持
つパケットに適合します。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
生存時間が ttl-list に含まれる IPv4 パケットに適合します。ttl-
list は、単一の値か、ports と同等の方法で指定される、値のリストか
範囲です。
ipversion ver
IP バージョンフィールドが ver である IP パケットに適合します。
keep-state [:flowname]
適合する際に、ファイアウォールは、動的規則を作成します。作成され
る規則は、デフォルトでは、同じプロトコルを使用している発信元と宛
先 IP/ポート間での双方向のトラフィックに適合するような動作となり
ます。この規則には、有限の生存時間 (sysctl(8) 変数の集合により制
御されます) があり、生存時間は、適合するパケットが見つかるたびに
リフレッシュされます。:flowname は、追加するアドレス、ポートとプ
ロトコルパラメータを動的規則に割り当てるために使用されます。それ
は、check-state 規則によってより正確な一致のために使用することが
できます。:default キーワードは、古い規則セット (ruleset) との互
換性のために使用される特別な名前です。
layer2 レイヤ 2 のパケット、つまり、ether_demux() と ether_out
put_frame() から ipfw へ渡されるパケットのみに適合します。
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 進数か 16 進数 (0x が頭に
つく場合) で入力することができ、常に 16 進数で出力されます (これ
は、-N オプションが使用されていない場合です。-N オプションが使用
されるとシンボル名称の解決が試みられます)。
proto protocol
対応する IP のプロトコルを持つパケットが適合します。
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 インタフェースは、送出パケットのみに
ついて検査することができます。したがって xmit を使用する場合に
は、out は、必須です (そして in は、無効となります)。
パケットが受信インタフェースや送信インタフェースを持たないかもし
れません: ローカルホストから発生したパケットは、受信インタフェー
スを持ちませんし、ローカルホストに到着する予定のパケットは、送信
インタフェースを持ちません。
setup SYN ビットがセットされているが ACK ビットを持たない TCP パケット
に適合します。これは、``tcpflags syn,!ack'' の短縮形です。
sockarg
ローカルのソケットに関連づけられたパケットと SO_USER_COOKIE ソ
ケットオプションが 0 以外の値に設定されたことに対しマッチします。
副作用として、オプションの値は、skipto または pipe 番号として順番
に使用できる、tablearg 値として利用可能にします。
src-ip ip-address
引数で指定したアドレスの 1 個を発信元 IP として持つ IPv4 パケット
が適合します。
src-ip6 ip6-address
引数で指定したアドレスの 1 個を発信元 IP として持つ IPv6 パケット
が適合します。
src-port ports
引数で指定したポートの 1 個を発信元ポートとして持つ IP パケットが
適合します。
tagged tag-list
単一の値、値のリストまたは、ports と同様に指定された範囲である、
tag-list に含まれているタグがあるパケットに適合します。tag 規則ア
クションパラメータを使用して、タグをパケットに適用することができ
ます (タグに関する詳細のための説明を参照してください)。
tcpack ack
TCP パケットのみです。TCP ヘッダの確認応答番号フィールドが ack に
設定されていれば適合します。
tcpdatalen tcpdatalen-list
TCP データの長さが tcpdatalen-list である TCP パケットに適合しま
す。単一の値、値のリスト、または ports と同様の形式の範囲、のどれ
かを指定します。
tcpflags spec
TCP パケットのみです。TCP ヘッダが spec で指定したコンマ区切りの
フラグのリストを含んでいれば適合します。サポートされている TCP フ
ラグは、次の通りです:
fin, syn, rst, psh, ack と urg。特定のフラグが存在しないことは、
`!' で示されます。tcpflags 指定を含んでいる規則は、決して、0 でな
いオフセットがあるフラグメント化されたパケットと一致しません。フ
ラグメント化されたパケットの照合に関する詳細については、frag オプ
ションを参照してください。
tcpseq seq
TCP パケットのみです。TCP ヘッダのシーケンス番号のフィールドが
seq に設定されるなら、照合します。
tcpwin tcpwin-list
ヘッダのウィンドウフィールドが、単一の値または ports と同じ方法で
指定された値または範囲のリストのいずれかである、tcpwin-list に設
定される TCP パケットと一致します。
tcpoptions spec
TCP パケットのみです。spec で指定したコンマ区切りのオプションのリ
ストが TCP ヘッダに含まれていれば適合します。サポートされている
TCP オプションは、次の通りです。
mss (最大セグメントサイズ), window (TCP ウィンドウ広告), sack (選
択的 ACK), ts (RFC1323 タイムスタンプ), cc (RFC1644 T/TCP コネク
ションカウント)。`!' を置くことで特定のオプションが存在しないとい
う記述ができます。
uid user
user が送信したまたは受信する、すべての TCP パケットと UDP パケッ
トに適合します。user は、名前でも ID 番号でも適合します。
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
type テーブルのキータイプ。
valtype
テーブルの値マスク。
algo 使用するテーブルアルゴリズム (下記を参照)。
limit テーブルに挿入されるかもしれない項目の最大数。
locked あらゆるテーブルの修正を制限します。
これらのオプションのいくつかは、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
規則のセットの使い方のいくつかは、「使用例」セクションを参照してくださ
い。
ステートフルファイアウォール
ステートフルオペレーションは、与えられたパターンに適合するパケットが検出
されたときに、ファイアウォールが特定のフローについての規則を動的に作成す
るための方法です。ステートフルオペレーションに対するサポートは、規則の
check-state, keep-state と limit オプションを通じて提供されます。
動的規則が生成されるのは、パケットが keep-state や limit 規則に適合したと
きで、その結果、与えられた protocol を持ち、src-ip/src-port dst-ip/dst-
port のアドレスの組の間のパケット全てのみに適合する動的規則が生成されます
(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 トラフィックシェイパ、パケットスケジューラとネッ
トワークエミュレータ、人工的にキューに入れることができるサブシステム、特
定のネットワークリンクの振る舞いをエミュレートするパケットを遅延させる
か、または落す、またはキューに入れるシステムのためのユーザインタフェース
です。
dummynet は、最初に ipfw 規則で使用することができる任意のマッチパターンを
使用してパケットを選択するためにファイアウォールを使用して動作します。次
に、パケットをマッチングすることは、トラフィックの調整を実装する 2 つの異
なったオブジェクトのいずれかに渡されます:
pipe パイプ (pipe) は、与えられた帯域幅と伝播遅延、FIFO スケジュー
ラによってドライブされ、プログラマブルキューとパケット損失率
がある単一のキューでリンク (link) をエミュレートします。パ
ケットは、ipfw から外へ出るので、キューの後ろに追加され、次
に、FIFO の順序で希望の速度でリンクに転送されます。
queue キュー (queue) は、いくつかのパケットスケジューリングアルゴリ
ズムの 1 つを使用してパケットスケジューリングを実装するために
使用される抽象化 (abstraction) です。キューに送られたパケット
は、最初に、5 つの組のマスクに従ってフロー (flow) にグループ
化されます。次に、フローは、キューに関連づけられたスケジュー
ラに渡され、各流れは、キュー自体で設定されるとしてのスケ
ジューリングパラメータ (重み付けなど) を使用します。スケ
ジューラは、順番に、エミュレートされたリンクに接続され、重み
付け (weight) と使用中のスケジューリングアルゴリズムの特徴に
従ってバックログされたフローの中でリンクの帯域幅を調停しま
す。
実際には、フローが使用できる帯域幅への強固な制限を設定するために pipes を
使用することがきますが、一方、異なったフローがどのように利用可能帯域幅を
共有するかを決定するために queue を使用することができます。
キュー、フロー、スケジューラとリンクの結合のグラフ表現は、下記の通りで
す。
(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 は、1 つ以上のスケジューラのインスタンス (SCHED_MASK を適用し
た後のパケットの 5 つの組の各値毎に 1 つの) へのフローを割り当てるために
使用されます。例として、``src-ip 0xffffff00'' を使用すると、/24 の宛先の
サブネット毎に 1 つのインスタンスが作成されます。
FLOW_MASK は、フローへのパケット分けるために SCHED_MASK と共に使用されま
す。例として、前の SCHED_MASK と共に ``src-ip 0x000000ff'' を使用すると、
それぞれ個別の発信元アドレスのためにフローを作ります。順番に、各 /24 サブ
ネットのためのフローは、同じスケジューラのインスタンスに送信されます。
上記のダイヤグラムは、パイプが SCHED_MASK をサポートするだけであり、FIFO
スケジューラの使用を強制するという唯一の制限がある、パイプの場合のためさ
え保持します (これらは後方の互換性のためにあり、事実上、内部的に dummynet
のパイプは、正確に上記のように実装されます)。
dummynet 操作の 2 つのモードがあります: ``normal'' と ``fast'' です。
``normal'' モードは、実際のリンクをエミュレートしようとします: dummynet
スケジューラは、パケットが与えられた帯域幅で実際のリンクより速くパイプを
残さないことを確実にします。``fast'' モードによって、特定パケットは、(パ
ケットフローがパイプの帯域幅を超えていないなら) dummynet スケジューラをバ
イパス (迂回) することができます。これは、(平均で) より少ないパケット毎の
CPU サイクルを ``fast'' モードが必要とする理由です、そしてパケットレイテ
ンシ (待ち時間) は、同じ帯域幅がある実際のリンクの比較でかなり低くなるか
もしれません。デフォルトモードは、``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 ですが、カーネルを
``options HZ=1000'' で動作させて精度を 1ms かそれ以下にすると良い
ことが経験的に知られています) に丸められます。デフォルト値は、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}
は、使用するスケジューリングアルゴリズムを指定します。
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 アルゴリズムを実装しています。
タイプに加えて、スケジューラのためにパイプのために許可されたすべてのパラ
メータもまた指定することできます。
最後に、次のパラメータをパイプやキューに対して設定できます。
buckets hash-table-size
様々なキューを格納するハッシュ表のサイズを指定します。デフォルト
は、64 で、sysctl(8) 変数 net.inet.ip.dummynet.hash_size によって制
御されます。指定可能な範囲は、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 スロットで、これは、イーサネットデバイスにおける典型的な
キューのサイズです。低速リンクのためにキューのサイズを小さいままに
しておくことが推奨されます。そうしないとキューの遅延がトラフィック
に及ぼす影響が著しくなるかもしれません。例えば、最大サイズのイーサ
ネットパケット (1500 バイト) が 50 個のとき、600Kbit、つまり
30Kbit/秒のパイプで 20 秒ということになります。それよりもずっと大き
な 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 Congestion 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
より大きい必要があります)
IPv6 データと共に使用した場合、dummynet には現在いくつかの制限がありま
す。インタフェースへのリンクローカルパケットを経路変更するために必要な情
報は、dummynet によって処理した後に利用可能でないので、それらのパケット
は、出力経路 (path) で落とされます。リンクローカルパケットを dummynet に
渡さないことを保証するよう心がけるべきです。
チェックリスト
規則を構成する際に考慮すべき重要な点をいくつか述べます。
• in (着信) と out (発信) するパケットの両方をフィルタリングすることを
覚えておいてください。ほとんどの接続は、両方向に行くパケットを必要と
します。
• テストは、細心の注意を払って行ないます。テストの際にはコンソールの近
くにいるのがよいでしょう。コンソールに近寄れない場合、
/usr/share/examples/ipfw/change_rules.sh にあるような自動回復スクリプ
トを使用してください。
• ループバックインタフェースのことを忘れてはなりません。
細かい事柄
• フラグメント化されたデータグラムが無条件で破棄される状況があります。
TCP パケットは、最低 20 バイトの TCP ヘッダを含まない場合、破棄されま
す。UDP パケットは、完全な 8 バイトの UDP ヘッダを含まない場合、破棄
されます。ICMP パケットは、4 バイトの ICMP ヘッダ、すなわち ICMP タイ
プとコードとチェックサムを含まない場合、破棄されます。これらのパケッ
トは、単に ``pullup failed'' としてログされます。何故なら、パケット中
に有意なログエントリを生成するだけの有用なデータが含まれないかもしれ
ないためです。
• 無条件で破棄されるもう 1 種類のパケットは、フラグメントオフセットが 1
の TCP パケットフラグメントです。これは、パケットとしては有効なもので
すが、利用目的は、ファイアウォールをかいくぐることしかありません。ロ
グが有効な場合、これらのパケットは、規則 -1 により破棄されたと報告さ
れます。
• ネットワーク越しにログインしている場合、kld(4) バージョンの ipfw を
ロードすることはそれほど単純なことではありません。次のコマンド行を奨
めます:
kldload ipfw && \
ipfw add 32000 allow ip from any to any
同じ行に沿って、同様の環境で
ipfw flush
を行うことは、良い考えではありません。
• システムセキュリティレベルが 3 以上に設定されている場合、ipfw フィル
タリストを変更できません (システムセキュリティレベルについては、
init(8) を参照してください)。
パケットの行き先変更
指定されたポートにバインドされた divert(4) ソケットは、そのポートへ行き先
変更されたパケットを、全部受けとります。宛先ポートにバインドされたソケッ
トがない場合や、パケットの行き先変更ソケットモジュールがロードされていな
い場合、または、カーネルがパケットの行き先変更ソケットをサポートするよう
にコンパイルされていない場合は、パケットは、破棄されます。
ネットワークアドレス変換 (NETWORK ADDRESS TRANSLATION (NAT))
ipfw は、libalias(3) のカーネルバージョンを使用するカーネル内 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
登録されていないアドレス空間を起源としないローカルネットワークの
トラフィックは、無視されます。
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 トランス
レータは、状態テーブルのホストのエントリを作成します。各ホストのエントリ
は、要求に応じて割り付けられた多くのポートグループエントリがあります。
ポートグループエントリは、接続状態エントリを含んでいます。これらのオブ
ジェクトのための制限と存続期間を制御するためのいくつかのオプションがあり
ます。
NAT64 トランスレータは、ICMPv6/ICMP 変換を行うとき、RFC7915 に従い、サ
ポートされていないメッセージタイプは、静かに落とされます。IPv6 は、正しい
操作のために明示的に許可される、いくつかの ICMPv6 メッセージタイプを必要
とします。ND6 隣接要請 (ICMPv6 タイプ 135) と隣接通知 (ICMPv6 タイプ 136)
メッセージは、変換規則によって処理されないことを確かめます。
変換の後に、NAT64 トランスレータは、対応する netisr キュー通してパケット
を送信します。したがって、トランスレータのホストは、IPv4 と IPv6 ルータと
して設定されるべきです。
現在、ステートフルとステートレス NAT64 トランスレータは、IPv6 アドレスの
IPv4 アドレスを表すために、よく知られている IPv6 接頭辞 64:ff9b::/96 を使
用します。したがって、DNS64 サービスと経路制御は、よく知られている IPv6
接頭辞を使用するために設定されるべきです。
ステートフル NAT64 設定コマンドは、次の通りです:
nat64lsn name create create-options
次のパラメータを設定することができます:
prefix4 ipv4_prefix/mask
マスクがある IPv4 接頭辞は、変換の後に送信元アドレスとして使用さ
れる IPv4 アドレスのプールを定義します。ステートフル NAT64 モ
ジュールは、クライアントの IPv6 送信元アドレスをこのプールから 1
つの IPv4 アドレスに変換します。状態テーブルの対応している状態エ
ントリがない着信 IPv4 パケットは、トランスレータによって落とされ
ることに注意してください。変換規則が、設定された接頭辞に向いてい
るパケットを処理することを確かめます。
max_ports number
1 つの IPv6 クライアントへの上部レベルのプロトコルのために予約さ
れたポートの最大数。すべての予約されたポートは、サポートされたプ
ロトコルの間のチャンク (塊) に分割されます。1 つの IPv6 クライア
ントからの接続の数は、このオプションによって制限されます。クロー
ズされた TCP 接続は、tcp_close_age 間隔が期限切れになるまで、まだ
接続リストに残ることに注意してください。デフォルト値は、2048 で
す。
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 によってすべての処理されたパケットのログ記録をオフにします。
ステートフル NAT64 の状態テーブルを検査するために、次のコマンドを使用する
ことができます:
nat64lsn name show states
ステートレスの NAT64 トランスレータは、変換のための状態テーブルを使用せ
ず、IPv4 アドレスを IPv6 に変換し、逆もまた同様に、設定された検索テーブル
から取られたマッピングだけを基準にします。状態テーブルは、ステートレスの
トランスレータによって使用されないので、それは、IPv4 クライアントを IPv6
のみのサーバに渡すために設定することができます。
ステートレス NAT64 設定コマンドは、次の通りです:
nat64stl name create create-options
次のパラメータを設定することができます:
table4 table46
検索テーブル table46 は、IPv4 アドレスが、どのように IPv6 アドレ
スに変換されるべきかのマッピングを含みます。
table6 table64
検索テーブル table64 は、IPv6 アドレスが、どのように IPv4 アドレ
スに変換されるべきかのマッピングを含みます。
log ipfwlog0 インタフェースを通して BPF によってすべての処理されたパ
ケットのログ記録をオンにします。
-log BPF によってすべての処理されたパケットのログ記録をオフにします。
一致していないパケットに関してステートレスのトランスレータの振る舞いは、
ステートフルのトランスレータと異なることに注意してください。対応している
アドレスが検索テーブルに見つからなかったなら、パケットは、落とされず、検
索は、継続します。
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 モジュールは、
それが、この接頭辞と一致するとき、宛先アドレスを変換します。
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.expire: 1
いったん動的なパイプ/キューに保留中のトラフィックがないと、ゆっく
りそれらを削除します。利用者は、変数を 0 に設定することによってこ
れを無効にすることができ、その場合に、パイプ/キューは、閾値に到着
するときのみ削除されます。
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.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
動的規則で使用されるハッシュ表に含まれるバケットの個数です。2 の
累乗でなければならず、上限は、65536 です。全ての動的規則が期限切
れとなったときにのみ効果が現れるので、確実にハッシュ表のサイズが
変更されるようにするには、flush コマンドを使用するべきでしょう。
net.inet.ip.fw.dyn_count: 3
現在の動的規則の数です (読み込み専用)。
net.inet.ip.fw.dyn_keepalive: 1
TCP セッションにおいて keep-state 規則のためのキープアライブパ
ケットを生成するようにします。キープアライブパケットは、規則の生
存時間が残り 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
ipfw がレイヤ 2 パケットを通すかどうかを制御します。デフォルト
は、no です。
net.link.bridge.ipfw: 0
ipfw がブリッジされたパケットを通すかどうかを制御します。デフォル
トは、no です。
内部診断
カーネルモジュールの内部の特定のサブシステムの現在の状態を理解するために
役に立ついくつかのコマンドがあります。これらのコマンドは、予告なしに変更
するるかもしれないデバッグ出力を提供しています。
現在、次のコマンドは、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
動的規則
偽造の 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 規則は、通常、規則セットをスキャンしている
仕事の量を最小にするために、規則セットの最初の近くに置かれるべきです。利
用者のマイレージは、変わるかもしれません。訳注: 意味不明。
ユーザがオープンすることができる接続の数を制限するために、利用者は、次の
規則のタイプを使用することができます:
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
前者 (ゲートウェイ上で動作することを仮定) は、/24 ネット上の各ホストが最
大 10 個の TCP 接続を開くことを許します。後者は、サーバ上に設定可能であ
り、単一のクライアントが同時に 4 個を越える接続を使用できないようにしま
す。
注意: ステートフルな規則は、怒涛の SYN 攻撃により極めて大量の動的規則を
作ってしまい、サービス不能攻撃を受けることになる可能性があります。ファイ
アウォールの動作をコントロールする 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 ipfw setfib tablearg ip from any to any recv
'table(IN)' in
ipfw add 200 ipfw skipto tablearg ip from any to any recv
'table(IN)' in
ipfw add 300 ipfw skipto tablearg ip from any to any xmit
'table(OUT)' out
次の例は、flow テーブルの使用法を説明しています:
ipfw table fl create type flow: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
関連項目
cpp(1), m4(1), altq(4), divert(4), dummynet(4), if_bridge(4), ip(4),
ipfirewall(4), ng_ipfw(4), protocols(5), services(5), init(8),
kldload(8), reboot(8), sysctl(8), syslogd(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.
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 によって開発されま
した。
バグ
構文は、年月を重ねるにつれて成長しています、ときどき混乱させられるかもし
れません。残念ながら、後方互換性のために、構文の定義で行われた誤りを訂正
することができません。
!!! 警告 !!!
ファイアウォールを誤って設定するとコンピュータが使用不能な状態になり、こ
とによると、ネットワークサービスを停止させてしまい、制御を回復するために
コンソールアクセスが必要となってしまう可能性があります。
divert によって行き先を変更された入力パケットの断片 (フラグメント) は、ソ
ケットに配送される前に再構成されます。これらのパケットで使用されるアク
ションは、パケットの最初のフラグメントに適合した規則のものです。
ユーザランドへ向けられ、ユーザランドのプロセスによって再投入されるパケッ
トは、パケットの発信元インタフェースを含むパケット属性のいろいろを失って
います。パケットの始点インタフェース名は、8 バイト未満であって、ユーザラ
ンドのプロセスが保存しこれを sockaddr_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 11.2 March 19, 2018 FreeBSD 11.2