核心有很多参数可以调节﹐以适用于不同的状况。通常﹐ 99% 的安装﹐使用预设参数就可以了﹐不过﹐与其这样的话﹐此称为 Advanced 的 HOWTO 就浪得虚名了﹗
有空请看看 /proc/sys/net﹐或有意外收获哦。只是﹐刚开始的时候﹐并非所有东西都会写在这里﹐我们尽力而为就是了。
预设情况下﹐router 会路由所有东西﹐就算该封包?显然'不属于贵网路的。常见的例子﹐莫过于将私有 IP 泄漏到 internet 上去。假如您有一个界面﹐其上设定的路由为 195.96.96.0/24﹐那您不会预期来自 212.64.94.1 的封包会到达这里。
许多人都想关闭此一功能﹐因此核心设计者也打开了方便之门。在 /proc 里面有些文档﹐透过它们您可以让核心为您做到这点。此方法被称为 "逆向路径过滤(Reverse Path Filtering)"。基本上﹐假如对此封包作出的回应﹐不是循其进入的界面送出去﹐那它就被视之为一个 bogus 封包﹐而被置之不理。
# for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
{ echo 2 > $i
} done
我们用上面的例子来看看﹐如果一个封包从 eth1 到达 Linux router﹐自称来自 Office+ISP 这个 subnet﹐那它就会被丢弃。同样地﹐如果封包来自 Office 这个 subnet﹐却自称来自防火墙外部﹐那它也同样会被丢弃。
上面是完全(full) 逆向路径过滤。预设是只根据直接相连网路的 IP 进行过滤﹐这时因为完全过滤会打断所谓的非对称路(asymmetric routing)情形 (也就是﹐封包从一端进入﹐而从另一端出去﹐例如卫星流量传送﹐或是您的网路使用动态 (bgp﹑ospf﹑rip)路由。资料从卫星接受碟下传进来﹐而回应则从正常的专线送回去)。
假如您属于这种例外(您应该心中有数)﹐那您可以简单的在卫星数据进入的界面上关闭 rp_filter。如果您想要看看封包是否真的会被丢弃﹐那可以透过同一目录的 log_martians 文档﹐告诉核心将之记录到 syslog 上面去。
# echo 1 >/proc/sys/net/ipv4/conf/<interfacename>/log_martians
FIXME: 不清楚设定 conf/{default,all}/* 下面的文档是否足够﹖ --- martijn
嗯﹐太多参数其实都可以修改啦。我们会试著将它们尽数罗列出来﹐而且(部份)会写在Documentation/ip-sysctl.txt 中。
其中有些设定的预设值会有不同﹐看您在编译核心的时候﹐是否以 'Yes' 来回答 'Configure as router and not host' 啰。
请留意﹐大多数的速率(rate)限制功能都不适用于 loopback 之上﹐所以请勿在本机上进行测试。这个限制受制于所谓的 'jiffies' ﹐且它们硬性的只能使用前述的 token bucket filter。
核心有一个内部时钟﹐每秒跑 'HZ' 跳(或曰 'jiffies' )。在 intel 上面﹐'HZ' 大概为 100 (译者注﹕我猜这里指所谓的 '内频' 而言吧﹖新的主机板大都支持 133 这个速度)。比方说﹐设定一个 *_rate 文档为 50 好了﹐则可每秒处理 2 个封包。而 token bucket filter 也可以被设定为﹐如果有足够的 tokens 存储的话﹐能让每一个 burst (瞬增流量)可达 6 个封包。
如下列表中的一些项目﹐拷贝自 /usr/src/linux/Documentation/networking/ip-sysctl.txt﹐由 Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> and Andi Kleen <ak@muc.de> 所撰写。
如果核心认为它不能传送某一封包﹐则将之丢弃﹐同时向封包来源送出一个 ICMP 告知其结果。
对所有封包均不作出 echo 。请勿将预设值设为启动﹐除非您被利用为一个 DoS 工具的跳站﹐那或许有用。
如果您 ping 网路的广播位址﹐那所有主机都会做出回应﹐这将是一个非常便利的 dinal-of-servie 工具。将这里设定为 1 则会忽略这些广播信息。
送出 echo 回应至任意目的端之速率
设定它会忽略因网路主机对哪些送至理解为广播位址之框包作出抵抗而引起的 ICMP 错误。
一个相对未知的 ICMP 信息﹐其发送是因损毁的 IP 或 TCP 标头封包而引发的。透过这个档﹐您可以控制其发送的速率。
这可以成为导致 traceroute 出现 '星星(* * *)' 的主因。这里限制送出 ICMP Time Exceeded 信息的数目。
主机上所倾听的最大 igmp (multicast) socket 数量。
FIXME: 不知道是否真的?
FIXME: 增加一个关于 inet peer storage 之简短说明?
废物收集(garbage collection)通过的最长间隔。这个间隔会影响到 pool 中内存的低位(或缺少)压力(pressure )。 以 jiffies 测量。
废物收集(GC)通过的最短间隔。这个间隔会影响到 pool 中内存的高位压力。 以 jiffies 测量。
(译者注﹕不清楚上面两个解释是否正确﹐因为原文中﹐作者均解释为"Minimum interval between garbage collection passes"﹐我这里私自将第一个改为“最长间隔”。)
最高存活期项目。在此期限到达之后﹐如果没有在 pool 上构成内存压力的话(例如﹐pool 中的项目数目非常少)﹐不使用的项目将会逾时。以 jiffies 测量。
最低存活期项目。在重组端必须要有足够的碎片(fragment)存活期。这个最低存活期必须保证 pool 体积是否少于 inet_peer_threshold。以 jiffies 测量。
INET peer storage 的适当体积。由此出发点开始的项目都会被强制抛弃。此出发点还判定项目的存活期﹐以及废物收集通过的时间间隔。项目越多﹐存活期越低﹐GC 间隔越短。
如果主机透过 RARP﹑BOOTP﹑DHCP﹑或类似方式获得其 IP 设定﹐这档会设为 1﹐否则为 0。
封包的存活期。设为 64 应是安全的。如果您的网路超大的﹐那就提升此值。千万不要随便乱玩 --- 如遇到路由回圈(routing loop)将导致更严重的灾难。在某些情形之下﹐您甚至会降低此值。
假如您要用动态界面位址做 dial-on-demand ﹐那就设定它。一旦您的请求界面起来之后﹐所有看不到回应的本地 TCP socket 都会重新捆绑(rebound)﹐以获得正确的位址。假如遇到启动界面的连线自己不工作﹐但再试一次却又可以的情形﹐设定这个可解决这个问题。
是否要核心传送封包。预设是关闭的。
对外连线时所使用的本地埠口范围。预设值事实上蛮小的﹕1024 到 4999。
如果您要关闭 Path MTU discovery --- 一种在路径上判定可接受的最大传送单位(Maximum Transfer Unit)数值的技术﹐那就设定这里。
IP 碎片重组所需的最大内存。当内存的 ipfrag_high_thresh bytes 因此目的获得分配之后﹐碎片处理程序会搁置封包﹐直到达到 ipfrag_low_thresh 为止。
如果您想让应用程序能够捆绑到一个不属于该系统的位址﹐就需要设定这里。当机器使用非固定(或是动态)线路的时候﹐这功能就很有用了﹐因而﹐当您的线路断掉之后﹐您的服务仍可启动而且捆绑到特定的位址之上。
IP 碎片重组所需的最小内存。
IP 碎片保留在内存中的秒数。
一个 boolean 旗标﹐处于大量进入连线的时候控制其行为特性。当打开之后﹐会让核心在服务出现超载的时候主动送出 RST 封包。
如果 socket 是有我们这端结束的﹐socket 保持 FIN-WAIT-2 状态的时间。连线端或会挂断且不会从它那端结束﹐或是甚至意外终结(died)。预设值为 60 秒。过去在 2.2 核心中是 180 秒﹐您可以复原它﹐但请记住﹐如果您的机器为一台盈负载(underloaded) 网页伺服器﹐您可能要冒著内存被大量死亡封包填满的风险﹐FIN-WAIT-2 sockets 的危险性低于 FIN-WAIT-1 ﹐因为它们最多只吃 1.5K 的内存﹐但是它们存在时间更长。另外参考 tcp_max_orphans。
当 keepalive 打开之后﹐TCP 要多久送出 keepalive 信息。
预设为 2 小时。
当一个探测(probe)没有获得确认之后﹐隔多久要被重送。
预设是 75 秒。
在决定挂断连线之前﹐要送出多少个 keepalive 探测。
预设值为﹕9 。
再乘上 tcp_keepalive_intvl﹐就是在一条线路在送出 keepalive 之后﹐所允许的不回应时间。
对于哪些没有附属于任何使用者文档 handle 的 TCP sockets﹐系统所能处理的最大数量。假如超过这个数量﹐那么这些无人看管的连线将会被立即重设(reset)﹐并同时显示警告信息。之所以要设定这个限制﹐纯粹为了抵御哪些简单的 DoS 攻击﹐千万不要依赖这个或是人为的降低这个限制﹐不过﹐如果网路条件需要比预设值更多﹐而且调整网路服务获得拖延并强制性砍掉这类状态﹐则可以提高它(或许还要增加内存)。再提醒一次﹕每一个这样的 orphan 都会吃掉 64K 不能置换的内存。
在我们这端砍掉 TCP 连线之前﹐要进行多少次重试。预设是 7 个﹐相当于 50秒 - 16分钟﹐视 RTO 而定。如果您机器为负载(loaded)网页伺服器﹐您或许会打算降低这个数值﹐这类 sockets 可能会耗费大量的资源。另外参考 tcp_max_orphans 。
对于哪些依然还未获得客户端确认的连线请求﹐需要记忆的最大数目。对于超过 128Mb 内存的系统﹐预设值是 1024 ﹐低于 128Mb 的则为 128。如果伺服器经常出现过载﹐可以尝试增加这个数字。警告﹗假如您将此值设为大于 1024﹐最好修改 include/net/tcp.h 里面的 TCP_SYNQ_HSIZE ﹐以保持 TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog ﹐并且编进核心之内。
系统在同一时间内所处理的最大 timewait sockets 数目。如果超过此数字的话﹐time-wait socket 会被立即砍除并且显示警告信息。之所以要设定这个限制﹐纯粹为了抵御哪些简单的 DoS 攻击﹐千万不要人为的降低这个限制﹐不过﹐如果网路条件需要比预设值更多﹐则可以提高它(或许还要增加内存)。
针对某些损坏印表机的 bug-to-bug 兼容性。于重传上尝试送出更大的封包﹐以解决特定 TCP 堆叠中的臭虫。
当某些事情不对劲而必须向网路层报告这个可疑状况之前﹐需要进行多少次重试。最低的 RFC 数值是 3 ﹐这也是预设值﹐相当于 3秒 - 8分钟﹐视 RTO 而定。
在砍掉存活 TCP 连线之前﹐需要进行多少次重试。RFC1122 里面说﹐这个限制必须大于 100秒。此数字非常小。预设值为 15 ﹐相当于 13-30分钟﹐视 RTO 而定。
这个 boolean 会启动关于 'time-wait assassination hazards in tcp' 的修正﹐请参考 RFC 1337。如果被打开﹐会让核心丢弃哪些处于 time-wait 状态 sockets 之 RST 封包。
预设为 0 。
使用 Selective ACK﹐它可以用来找出特定的遗失封包 --- 因而有助于迅速复原。
使用 TCP urg pointer 栏位中的主机请求诠释功能。
大部份的主机都使用老旧的 BSD 诠释﹐因而﹐如果您在 Linux 打开它﹐或会导致不能和它们正确沟通。
预设为﹕FALSE
对于一个新建连线﹐核心要送多少个 SYN 封包数才决定放弃。
为了与另一端建立连线﹐核心会连同 SYN 一起送出 ACK ﹐以确认收到上一个 SYN。这是所谓的三段交握( threeway handshake) 的第二个步骤。这里决定核心在放弃连线之前所送出的 SYN+ACK 数目。
Timestamps 用在其它一些东西中﹐可以防范哪些伪造的 sequence 号码。一条 1 gigabit 的线路或许会重遇到带 out-of-line 数值的旧 sequence 号码(假如它是由于上次产生的)。Timestamp 会让它知道这是个 '旧封包'。
启动快速 TIME-WAIT sockets 回收。预设值是 1 。除非得到技术专家的建议或要求﹐请不要修改这个值。
正常来说﹐TCP/IP 可以接受大至 65535 byte 的 windows。对于高速网路﹐这或许还是不够的。这个 windows scaling 选项则允许接近 gigabyte 的 windows﹐这将有助改善高频宽延迟产品。
DEV 可以只代表一个真实界面﹐也可以是 '全部' 或 '预设值'。而预设值也或许会改变建立的界面设定。
如果 router 认为您在不适当的使用它(ie﹐需要在同一界面上重送封包)﹐那它就会送出一个 ICMP Redirect。这或许会造成轻度的安全风险﹐所以您最好关闭它﹐或是使用 secure redirects。
此功能并不常用。过去﹐您可以给出一个 IP 位址列表﹐让它提供此功能。Linux 也可以实践这个 IP 选项。
FIXME: 有待补充
FIXME: 有待补充
请参考逆向路径过滤章节。
是否在该界面上进行 multicast forwarding。
如果设为 1﹐那么所有其它界面都会回应以此界面为目的之 arp 请求。当架设 'ip pseudo bridges' 时相当有用。启用此功能之前﹐请确定您的 netmasks 要非常正确。
请参考逆向路径过滤章节。
FIXME: 有待补充
是否要送出前面提到的 redirects。
FIXME: 有待补充
FIXME: 有待补充
DEV 可以只代表一个真实界面﹐也可以是 '全部' 或 '预设值'。而预设值也或许会改变建立的界面设定。
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充
FIXME: 有待补充