はい、変更できるパラメータはとてもたくさんあります。 ここではそれらすべてをリストしたいと考えています。 一部は Documentation/ip-sysctl.txt でも説明されています。
カーネルのコンパイル時に 'Configure as router and not host' に 'Yes' と答えていると、これらの設定のデフォルトが、 ここに示すものとは異なっているかもしれません。
Oskar Andreasson も、これらのフラグに関するページを公開しています。 ここのものより良いように思えますので、 彼のページ もチェックしてみてください。
訳注: この部分の訳出にあたっては、 2.2 カーネル付属文書 proc.txt の翻訳 を参考にさせていただきました。
一般的な注意ですが、ほとんどの速度制限機能は loopback に対しては効きません。 ですので、ローカルでのテストはしないでください。 制限は 'jiffies' 単位で与えられ、先に紹介したトークンバケツフィルタによって 適用されています。
カーネル内部の時計は、1 秒あたり 'HZ' 刻み (あるいは 'jiffies') で動作します。 Intel では 'HZ' は大抵の場合 100 です。よって *_rate ファイルを、 例えば 50 と設定すると、一秒当たり 2 パケットを許可することになります。 トークンバケツフィルタは、十分なトークンが溜まった場合、 最大 6 パケットまでのバーストを許すような設定になっています。
以下のリストの一部は、Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> と Andi Kleen <ak@muc.de> による /usr/src/linux/Documentation/networking/ip-sysctl.txt からコピーしてきたものです。
カーネルは、パケットを配送できないと判断すると、そのパケットを破棄します。 そしてそのパケットの発信元に、ICMP メッセージをこの速度で送ります。
echo パケットに一切反応しません。 これはデフォルトでは設定しないでください。 しかし DoS 攻撃の中継に利用されてしまった場合には有用です。
ネットワークのブロードキャストアドレスに ping すると、 すべてのホストが反応することになっています。 これを使うと洒落た利用不能攻撃ツールになります。 ので、これは 1 にして、このようなブロードキャストメッセージは無視してください。
ある 1 つの目的地に対する echo リプライの送信速度。
これを設定すると、 ネットワーク上のホストが、 ブロードキャストアドレス向けとみなしたフレームに対して不正に反応したために発した ICMP error を無視します。
あまり知られていない ICMP メッセージですが、 IP ないし TCP ヘッダが壊れている、不正なパケットに対する返信として送られます。 このファイルを用いると、このメッセージの送信速度を制御できます。
これは traceroute における「Solaris の真ん中の *」の原因として有名です。 ICMP Time Exceeded メッセージの送信速度を制限します。
このホストで待ち受けする igmp (マルチキャスト) ソケットの最大数。 FIXME: 正しいか?
FIXME: inet peer storage について少々説明を追加? ガベージコレクションを行う最大間隔。この間隔は、プール上の メモリ負荷が低い (あるいは無い) 場合に効力を持ちます。 jiffies 単位です。
ガベージコレクションを行う最小間隔。この間隔は、プール上の メモリ負荷が高い場合に効力を持ちます。 jiffies 単位です。
エントリの time-to-live の最大値。 使われなかったエントリは、プールにメモリ負荷がない場合 (つまりプールのエントリ数が非常に小さい場合)、 この期間がすぎると期限切れとなります。 jiffies 単位です。
エントリの time-to-live の最小値。 パケットの再構成を行う側では、 フラグメントの time-to-live をカバーできる十分な大きさにしなければなりません。 この time-to-live の最小値は、プールのサイズが inet_peer_threshold より小さい場合に保証されます。 jiffies 単位です。
INET peer storage の概算サイズです。 この閾値を越えると、エントリは積極的に削除され始めます。 この閾値は、エントリの time-to-live と、 ガベージコレクションの間隔にも影響します。 エントリが多くなると、time-to-live は短くなり、GC の間隔も短くなります。
このホストが IP 設定を RARP, BOOTP, DHCP などの機構で取得した場合、 このファイルの内容は 1 になります。そうでなければ 0 です。
パケットの Time To Live 値です。 64 にしておけば安全でしょう。巨大なネットワークでは増やしてください。 ただし興味だけでそうしないように。 経路のループがあった場合の被害が大きくなります。 場合によっては減らすことを考えてもよいでしょう。
インターフェースアドレスが動的に決まるダイヤルオンデマンドを用いている場合は これを設定しておく必要があります。オンデマンドのインターフェースが起動すると、 返信を見ていなかったローカルの TCP ソケットが、 正しいアドレスにバインドしなおします。 これによってインターフェースを起動させた接続が動作しないが、 二番目からは大丈夫になる、という問題が解決します。
カーネルにパケットのフォワードをさせたいかどうか。 デフォルトでは無効になっています。
外に向かう接続における、ローカルポートの範囲。 実際のデフォルトは極めて小さく、1024 から 4999 です。
Path MTU discovery を無効にしたければこれを設定してください。 これは経路の Maximum Transfer Unit の最大値を決定する方法です。 クックブック の章における Path MTU discovery の節もご覧ください。
IP フラグメントを再構成する際に用いる最大メモリ。 ipfrag_high_thresh バイトのメモリがこの目的に割り当てられると、 フラグメントハンドラは ipfrag_low_thresh になるまでパケットを投げ込みます。
アプリケーションを自分のシステムには属していないデバイスにバインドさせたければ、 これを設定してください。 これはマシンの接続が永続的でない (あるいは動的な) 場合、 接続が切れたときにもサービスが起動して特定のアドレスに バインドできるようにするのに便利です。
IP フラグメントの再構成に用いられるメモリの最小値。
IP フラグメントをメモリに保持する時間 (秒単位)。
ブール値のフラグで、接続要求がたくさん来たときの動作を制御します。 有効になっていると、サービスが過負荷になったとき、 カーネルは積極的に RST パケットを送るようになります。
ソケットをこちら側からクローズしたときに、FIN-WAIT-2 状態に保つ時間。 通信先が壊れていると、先方でのクローズをずっと行わなかったり、 あるいは予期しない形で死んでしまうかもしれません。 デフォルトの値は 60 秒です。2.2 で用いられていた通常の値は 180 秒で、 こちらにすることもできますが、 マシンが (必ずしも負荷が高くなくても) WEB サーバだったりすると、 膨大な FIN-WAIT-2 ソケットのせいでメモリが溢れる危険もあります。 FIN-WAIT-2 ソケットは 1.5K のメモリしか食わないので FIN-WAIT-1 ほど危険ではありませんが、しかし長く生きる傾向があります。 参照: tcp_max_orphans
keepalive が有効になっているとき、 TCP が keepalive メッセージを送る頻度。デフォルトは 2 時間です。
プローブに対する確認が返信されなかったときにプローブを再送する頻度。 デフォルトは 75 秒です。
TCP が keepalive プローブを送る数。この数に達すると、 その接続が壊れたとみなします。デフォルトの値は 9 です。 この値に tcp_keepalive_intvl をかけると、 ある keepalive が送られた後に許される無反応時間が得られます。
システムが、どのユーザファイルハンドルにもアタッチしていない TCP ソケットを保有できる最大数。この数を越えると、 みなしごの接続は直ちにリセットされ、警告が表示されます。 この制限は単純な DoS 攻撃を防ぐためにあります。 この機能に頼りすぎたり、わざと制限を小さくしたりしてはいけません。 ネットワークの状況によって必要な場合は、 (できればメモリを追加してから) デフォルトより増やすのはかまいません。 また、ぐずぐずするネットワークサービスを調整して、 そのような状態を積極的に殺すようにしてください。 再度強調しておきますが、みなしごの接続は、 それぞれスワップ不可能なメモリを最大 64K 消費するのです。
こちら側からクローズした TCP コネクションを終了する前の再送回数。 デフォルト値は 7 で、これは RTO によりますが、50 秒から 16 分です。 マシンで WEB サーバを動作している場合、 このようなソケットはリソースを著しく消費するかもしれないので、 この値を低くすることを考えてください。 参照: tcp_max_orphans
送信した接続要求のうち、 まだ接続先から ACK を受け取っていないものを記憶しておく最大数です。 デフォルト値は、128Mb 以上のメモリを搭載しているマシンで 1024、 メモリの少ないマシンでは 128 です。 サーバが過負荷に苦しんでいる場合は、この数を増加させてみてください。 警告! 1024 以上にする場合は、 include/net/tcp.h の TCP_SYNQ_HSIZE を変更して TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog が満足されるようにし、 カーネルを再コンパイルした方がいいでしょう。
システムが同時に保持する time-wait ソケットの最大数。 この数を越えると、time-wait ソケットは直ちに破棄され、警告が表示されます。 この制限は単純な DoS 攻撃を防ぐためにあります。 わざと制限を小さくしてはいけません。 ネットワークの状況によって必要な場合は、 (できればメモリを追加してから) デフォルトより増やすのはかまいません。
問題のあるプリンタのバグ-バグ互換性を保つためのもの。 特定の TCP スタックのバグに対処するため、 再送時に大きなパケットを送ります。
再送回数で、この数を越えると何か問題があると判断し、 その疑いをネットワーク層に報告する必要があります。 RFC での最小値は 3 で、これがデフォルトです。 RTO によりますが、3 秒から 8 分に相当します。
接続中の TCP セッションを殺すまえに再送を試みる回数。 RFC 1122 によれば、この時間は 100 秒以上にならなければいけません。 これは実際には短すぎる。 デフォルト値は 15 で、RTO の値によりますが 13-30 分に相当します。
このブール値は RFC1337 で説明されている 'time-wait assassination hazards in tcp' の修正です。有効になっていると、 カーネルは time-wait 状態にあるソケットへの RST パケットを破棄します。
Selective ACK を用います。特定のパケットが失われているかを調査でき、 よって回復が速やかになります。
TCP urg ポインタフィールドを、Host requirements に従って解釈します。 多くのホストは古い BSD の解釈を使っているので、 Linux でこれをセットすると正しく通信ができないかもしれません。 既定値: FALSE
新しい接続を開始するとき、カーネルはこの回数 SYN パケットを送っても駄目ならばあきらめます。
接続を受付側としてオープンするとき、 カーネルは SYN に ACK を詰め込んで送り、先に受けとった SYN を確認します。 これは 3 方向ハンドシェークの 2 番目の部分です。 この設定は、カーネルが接続をあきらめるまでに送る、 SYN+ACK パケットの再送数を指定します。
タイムスタンプは、特に、シーケンス番号の重なりを防ぐために使用されます。 1 ギガビットの接続では、おそらく順序通りでない、 古いシーケンス番号に出くわすことがあります (前の世代の番号であるため)。 タイムスタンプを用いると、これを「昔のパケット」と認識できます。 シークエンス番号がオーバーフローして、また0から始まることを言ってる? -->
TIME-WAIT ソケットを高速にリサイクルできるようにします。 デフォルト値は 1 です。 これは専門技術者のアドバイスか要求がなければ、変更すべきではありません。
通常 TCP/IP では、最大 65535 バイトのウィンドウが可能です。 本当に高速なネットワークでは、これでは十分でないかもしれません。 ウィンドウ拡大オプションを用いると、 ほぼギガバイトのウィンドウが利用できます。 これはバンド幅と遅延時間の積が大きいような製品に適しています。
DEV は実際のインターフェースか、あるいは 'all' または 'default' を表します。 default は、まだ作成されていないインターフェースの設定にも影響します。
ルータは、自分が間違った目的で利用されている (つまり受けとったパケットを同じインターフェースに再送しなければならない) と判断すると、そのパケットの発信元に ICMP Redirect を送信します。 しかしこれは少々セキュリティ上の問題があるので、 この受信を拒否したり、あるいは安全なリダイレクトを利用できます。
もうあまり用いられません。以前はパケットに、 途中で訪れるべき IP アドレスのリストを与えることが可能でした。 Linux はこの IP オプションを尊重するような動作が可能です。
発信元アドレスが 0.b.c.d で、 送信先がこのホストでないパケットを、ローカルなパケットとして許可します。 これは BOOTP リレーデーモンが、 そのようなパケットを受信・フォワードしているのだと考えられます。
この機能はまだ (カーネルバージョン 2.2.12 では) 実装されていないので、デフォルトは 0 です。
このインターフェースでの IP フォワーディングを有効/無効にします。
戻り経路フィルタ (Reverse Path Filtering) の節を見てください。
このインターフェースでマルチキャストフォワーディングを行うかどうかです。
これを 1 にすると、このインターフェースは カーネルが経路を知っているアドレスに対する ARP 要求に返信します。 「疑似 ip ブリッジ」を構築するのに非常に便利に使えます。 これを有効にする前には、ネットマスクが本当に正しいかをしっかり確認してください! また rp_filter (別のところで紹介しています) が、 ARP 問い合わせに対して動作することも覚えておいてください!
戻り経路フィルタ (Reverse Path Filtering) の節を見てください。
ICMP redirect メッセージを、デフォルトゲートウェイにリストされている ゲートウェイに対してのみ許可します。デフォルトで有効です。
このホストが上述の redirect を送信するかどうかです。
設定されていないと、カーネルはこのデバイスにつながっている 別々のサブネットは、直接通信できないとみなします。 デフォルトの設定は 'yes' です。
FIXME: ここを埋めてください。
DEV は実際のインターフェースか、あるいは 'all' または 'default' を表します。 default は、まだ作成されていないインターフェースの設定にも影響します。
近隣確認メッセージへの返答のランダム遅延の最大値 (jiffies [1/100 秒] 単位)。 まだ実装されていません (Linux はまだ anycast をサポートしていません)。
ユーザレベルの ARP デーモンに送るリクエストの数を定義します。 無効にするには 0 にします。
RFC2461 で規定されているランダム到達可能時間の計算のベースになる値です。
近隣が到達可能かどうかのプローブを最初に行うまでの遅延時間です (gc_stale_time を参照)。
古い ARP エントリをどの程度の頻度でチェックするかを決めます。 古くなった ARP エントリは再び解決されます (これは IP アドレスが他のマシンへ移る時に役に立ちます)。 ucast_solicit が 0 より大きければ、 まず既知のホストに直接 ARP パケットを送信します。 これが失敗したら、mcast_solicit が 0 より大きければ ARP 要求をブロードキャストします。
ARP/近隣エントリは、最低でも locktime だけ経過しないと 新しいものと置き換えできません。 これは ARP キャッシュのスラッシングを防ぎます。
マルチキャスト確認の最大再試行回数です。
代理 ARP エントリを持っている場合に、 その ARP 要求に答えるまでの最大時間です。 実際の時間は 0 以上 proxy_delay 以下の乱数になります。 ある場合には、これはネットワークの溢れを防ぐために使用されます。
遅延した代理 ARP タイマのキューの最大長です (proxy_delay を参照)。
近隣確認メッセージを再送信するまでの時間 (単位は jiffy = 1/100 秒) です。 アドレスを解決したり、近隣が到着不能かどうかを確認したりする際に使用します。
ユニキャスト確認の最大再試行回数です。
待ち状態の ARP 要求を保持するキューの最大長です。 ARP アドレスが解決されている最中に、 他の層からの要求パケットを受け入れる数です。
このパラメータと次の error_cost はルーティングのコードから カーネルのログに書き出される警告メッセージの制限に使用されます。 error_costを大きくすると書き出されるメッセージは少なくなります。 error_burst はメッセージを捨てる際の制御を行います。 デフォルトでは警告メッセージを 5 秒間に一回までに制限しています。
/proc/sys/net/ipv4/route/error_burst の項を参照してください。
このファイルに書き込むとルーティングキャッシュをフラッシュします。
ルーティングキャッシュのガベージコレクションの頻度と動作を決める値です。 これはフェイルオーバー動作で重要となります。 ある経路が死んだとき、Linux が別の経路に移るまでには、 最低 gc_timeout 秒が経過しなければなりません。 デフォルトでは 300 に設定してありますが、 フェイルオーバーを早く行いたければ、もっと小さい値にすると良いでしょう。
Ard van Breemen の この投稿 も参照してください。
/proc/sys/net/ipv4/route/gc_elasticity の項をご覧ください。
/proc/sys/net/ipv4/route/gc_elasticity の項をご覧ください。
/proc/sys/net/ipv4/route/gc_elasticity の項をご覧ください。
/proc/sys/net/ipv4/route/gc_elasticity の項をご覧ください。
ルーティングキャッシュがフラッシュされるまでの最大時間です。
ルーティングキャッシュの最大サイズです。 キャッシュがこのサイズに達すると、古いエントリは破棄されます。
FIXME: ここを埋めてください。
ルーティングキャッシュがフラッシュされるまでの最小時間です。
FIXME: ここを埋めてください。
FIXME: ここを埋めてください。
特定のホストに対して ICMP リダイレクトをより多く送るべきかを決定するための因子です。 負荷がここで指定した数に達した場合には、 それ以上のリダイレクトは送信されません。
/proc/sys/net/ipv4/route/redirect_load の項目を参照してください。 こちらはリダイレクト数の制限です。
リダイレクトの時間切れ。 負荷やリダイレクト数が制限に達してリダイレクトが停止されていた場合でも、 この期間が過ぎるとリダイレクトを再び送り始めます。