pf如何限制每ip的最大连接数(已解决)。能否限制每ip的最大带宽?

colddawn

按原理讲越高层协议的处理，占用资源就越多，所以能在低层完成的东西，就不要放到高层处理。
对于网关来说，首先在ip层做好路由（可能非必需），tcp层做好nat。这两层能解决的内部客户问题就是并发连接限制和流量整形了，首先在这里设卡过滤掉非正常包已经做好流空后，如果有余力，再来考虑上层应用的问题。直接在应用层设卡会导致一切问题都要集中在应用层处理，而应用层牵涉到连接状态控制以及包内容分析，哪一个拿出来都是极其耗费资源的东西，自然也就脆弱了。

rainren

原帖由 colddawn 于 2006-1-17 17:25 发表


代理是多，但p2p软件走http代理是很难实现的，再加上并发80端口限制的话，效果很不错的，用l7分析会导致网关服务器负载过高，你跑死并不一定是流量满了，更大的原因是网关自己处理不过来了。如果是找流量和并 ...

很多如bt, emule等都可以使用代理， 防火墙上限制越多， 负荷越重， 如果带的机器较多， 想处理过来都难。 一般只能对最关键的服务做限制。


服务不会中断， 一般不出现攻击防火墙应付不过来是不会停服务， 在某一个网络速度下查看流量和并发数有效的限制一些用户的下载， 从而提高内网别的用户上网速度！

[ 本帖最后由 rainren 于 2006-1-17 17:43 编辑 ]

llzqq

我翻译的,不知有没有错:

max number   
服务器最大可以建立的连接数（状态数量），如果已经建立的连接数达到了这个数那么多处的连接将被丢弃。

source-track
跟踪每个IP的连接状态数它有中使用格式:source-track rule 和 source-track global

max-src-nodes number
最多允许连接的IP数量，它必须和“source-track rule”一块使用。

max-src-states number
单个IP的最大连接数。

例子：
pass in on $ext_if proto tcp to $web_server port www flags S/SA keep state \
(max 200, source-track rule, max-src-nodes 100, max-src-states 3)

这个例子达到了这样的效果：

l        绝对限制了最大连接状态数为200个。
l        所有连接状态数据依据source-track规则提供。
l        最大允许100个节点（IP地址）并发连接。
l        每个IP地址最大3个连接状态。


max-src-conn number
单个IP的最大连接数，注意这里是指完成了三次握手的并发连接数

max-src-conn-rate number/interval
但IP的连接建立的速率(个/秒)


例子：
table <abusive_hosts> persist
block in quick from <abusive_hosts>
pass in on $ext_if proto tcp to $web_server port www flags S/SA keep state \
(max-src-conn 100, max-src-conn-rate 15/5, overload <abusive_hosts> flush)


overload <table>
在这里放置符合条件的IP

flush [global]
清除原来的IP状态

这个例子达到这样的效果：

l        允许每个IP最大可以有100个非并发的连接
l        允许每个IP最大连接建立的速率小于每秒15个
l        把连接建立过快的IP放到abusive_hosts表中
l        一旦一个IP被放到了abusive_hosts表中后，立即应用block规测

rainren

不错， 谁有精力可以将整个pf.conf的man 翻译， 又是一个学习 pf的好的中文资料！

colddawn

原帖由 rainren 于 2006-1-17 17:32 发表


很多如bt, emule等都可以使用代理， 防火墙上限制越多， 负荷越重， 如果带的机器较多， 想处理过来都难。 一般只能对最关键的服务做限制。


服务不会中断， 一般不出现攻击防火墙应付不过来是不会停服务 ...

可以使用代理确实没错，但是据我用这些p2p软件的经验是只能使用sock代理而不能用http代理实现，我的核心思路就是把已知的重要服务放到高优先队列里以便提高服务质量，这些服务是很好鉴别的，例如大部分上网的访问网页80端口，ftp21端口等，其它非核心服务降低队列优先级，避免核心服务因为带宽问题受到阻塞。
这个思路是基于连接状态控制的基础上的，除了流量整形，不会加入更多的服务器负担，因为nat本身已经必需连接状态表了，最大的开销部分已经被状态表建立所占据了，所以我认为此方法不会过大加重网关服务器负担。实际证明，qos功能大部分三层交换甚至2层交换都提供了，性能损耗是可以接受的。

您既然都已经应用测试过l7策略了，为什么对l4的规则性能却持有怀疑态度？
确实如您所说，越多的限制就会越大加重网关负担，但我个人认为不加限制纯人工的监测应该是更不可取的。

rainren

我的核心思路就是把已知的重要服务放到高优先队列里以便提高服务质量，这些服务是很好鉴别的，例如大部分上网的访问网页80端口，ftp21端口等，

这恰恰就是可以利用的地方， 现在bt, emule的软件写的非常好。我测试过， 当我用 ipp2p, layer7封BT时， 确实有的bt软件用不了，它会显示一直在连接服务器， 但我用比特精灵测试时第一个连接在过了差不多20多分钟的寻找服务器后开始下载， 这说明我在防火墙上做的关于P2P的限制失效。

现在的软件都可以使用http, ftp. sock代理， 并不是你说的那种。现在bt算是一个过街老鼠，个个网管员都想封， 但软件开发者也会想方设法去寻求种种解决方案。因此封P2P软件是个大难题。

你可以自己测试一下， 多找几个P2P软件， 多找几个80的代理服务器， 看看你的限制还怎么样？


我做上面的实验时用了两种服务器： openbsd + pf, debian + iptables
实在限制不了， 我只好转寻另外的解决方案，当我的网速慢到一定值时（查看ping）查找某一时刻最多并发连接数的用户（P2P使用者的并发连接数非常多）将它放到一个限速的队列中。有时一个用户下载它的并发连接并不太多， 我们只好查看它的网络传输量来将它丢到限速队列中去。 这上面两个查看人工方式当然不行， 但是用unix , shell 脚本才是我们管理系统的利器， 我们可以使用脚本来完成我们上面的要求。

我贴了一个脚本， 这个脚本我也还在改进中， 看有哪些地方想的不周全，在实际应用中发现问题再改进！

[ 本帖最后由 rainren 于 2006-1-17 18:30 编辑 ]

剑心通明

这个思路挺好的

100000

原帖由 rainren 于 2006-1-17 17:48 发表
不错， 谁有精力可以将整个pf.conf的man 翻译， 又是一个学习 pf的好的中文资料！

嘿嘿，这也算大工程了，要不你组织一下，每人领一段回来翻译？

100000

原帖由 rainren 于 2006-1-17 18:29 发表
我的核心思路就是把已知的重要服务放到高优先队列里以便提高服务质量，这些服务是很好鉴别的，例如大部分上网的访问网页80端口，ftp21端口等，

这恰恰就是可以利用的地方， 现在bt, emule的 ...

是不是在发现带宽占用到一定程度的时候（95%）以上，就选择连接数和占用带宽最多的ip，然后把它们分组处理。这样是不是更好一些？
另外默认的每个ip都给个连接上限，比如100或者50（我用的50）是不是能减少带宽占用过高出现的几率？

rainren

原帖由 100000 于 2006-1-17 20:58 发表



嘿嘿，这也算大工程了，要不你组织一下，每人领一段回来翻译？

整个它讲的东西都是一些参数的解释，比pf faq的多很多。

过两天就回家过年了， 过年后的情况还不知咋样！ 要不放在顶上让大伙们来自己翻译自己贴！