老管网络日志 | funpower's blog

安装完freebsd后freebsd能正常启动，但win2000不能启动，如下提示：

NTLDR is missing

Press any key to restart

提示ntldr文件找不到，看来要重新COPY过去。排除故障操作：

将win2000安装光盘放入光驱中引导系统，然后进入“故障恢复控制台”，接着将光盘i386目录下的ntldr和ntdetect.com复制到c:下。重启，故障排除。

前天在一台装有网路岗的IBM xSeries 240服务器上安装了ZoneAlarm的防火墙–ZoneAlarm Pro 5.5.062.004，昨天（星期六）没有碰服务器，到星期天去看服务器，感觉服务器速度特别慢，打开资源管理器，发现CPU资源一直在90%-100%之间。

奇怪了，虽然网路岗也占资源，但也不可能占到这么大，转到资源管理器的进程选项，发现了vsmon.exe进程，竟然点到了78%的CPU资源。

然后用Google搜了一下vsmon.exe，发现他就是ZoneAlarm防火墙的进程名，试着把vsmon.exe结束了，CPU占用马上降下来了，速度也变快了。

总结：ZoneAlarm是一款很优秀的防火墙，机器的网络活动他都要一一检查后再放行，我这台服务器安装的网路岗本来就是用来监控局域网用户的上网活动的，通过服务器的网络流量很大，ZoneAlarm防火墙要监控这么大的流量，资源肯定是会占不少的。

感觉在一些本身是监控的服务器或者网络流量特别大的时候(比如使用BT下载或者骡子下载)，目前我的方法只有先关闭防火墙或者换一套；哪位朋友有更好的方法希望提出。

作者：管建丰 交流：funpower (at) gmail.com

为了能提供更丰富的网络服务功能，准备改造代理服务器。

原功能：提供squid的http请求服务，提供socks5的网络服务

改造后的功能：提供squid的http请求服务(不用改变客户端网络设置)，利用freebsd的ipfilter模块提供网络包过滤和网络地址转换(根据需要开通某些客户端,但需重新设置客户端)

具体操作:

说明：vr0:外网网卡接口218.90.x.x；vr1:内网网卡接口192.168.1.254

1、编辑/etc/rc.local将启动socks5服务的一行去掉

2、重新编译内核

# cd /sys/i386/conf
# cp funpower funpower2 //funpower为现内核名
# ee funpower2 //用ee打开funpower2,新添加如下三行：

options IPFILTER
options IPFILTER_LOG
options IPFILTER_DEFAULT_BLOCK

接下来重新编译内核：

# /usr/sbin/config funpower2
# cd ../../compile/funpower2
# make depend
# make
# make install

如果没有error之类的错误句，说明你的内核已编译成功。
如果你是直接在机器前操作的，可以重启机器了，但如果你是利用telnet或者ssh连接到服务器进行以上操作的，请不要急着现在重启，

因为刚才在内核中加入的ipfilter默认是阻止一切连接，继续往下操作

3、编辑/etc/rc.conf

# ee /etc/rc.conf //用ee打开/etc/rc.conf，回入如下语句：

ipfilter_enable="YES"
ipfilter_rules="/etc/ipf.conf"
ipnat_enable="YES"
ipnat_rules="/etc/ipnat.conf"
gateway_enable="YES"

4、在/etc下创建ipf.conf和ipnat.conf

# ee ipnat.conf //利用ee创建ipnat.conf

rdr vr1 0.0.0.0/0 port 80 -> 192.168.1.254 port 3128
map vr0 192.168.1.0/24 -> 0/32 proxy port ftp ftp/tcp
map vr0 192.168.1.0/24 -> 0/32 portmap tcp/udp 10000:30000
map vr0 192.168.1.0/24 -> 0/32 portmap

# ee ipf.conf //利用ee创建ipf.conf,这个文件视你的网络情况而定

block in log quick all with short
block in log quick all with ipopts
block in log quick all with frag
block in log quick all with opt lssr
block in log quick all with opt ssrr

pass out on vr1 all
pass in on vr1 all
pass out quick on lo0 all
pass in quick on lo0 all

block out on vr0 all
pass out log on vr0 proto tcp/udp from 218.90.x.x to any keep state

pass out log on vr0 proto tcp/udp from 192.168.1.1 to any keep state
pass out log on vr0 proto tcp/udp from 192.168.1.2 to any keep state
pass out log on vr0 proto tcp/udp from 192.168.1.3 to any keep state

pass out log on vr0 proto icmp all keep state
pass out log on vr0 proto tcp/udp from any to any keep state
pass in quick on vr0 proto tcp from any to any port = ftp-data keep state
pass in quick on vr0 proto tcp from any port = ftp-data to any port>1023 keep state

注：ipf.conf和ipnat.conf推荐一篇文章.

5、重启机器，设置客户端

到这儿重启后对telnet和ssh就没影响了，因为在ipf.conf已经加入了内网网卡的通行规则。
客户端设置，对于原来的只需http上网的用户客户端无需修改网络设置，需要ipfilter的首先需在ipf.conf中加入规则表,然后网络设置

也要填上网关：192.168.1.254和DNS地址，才能使用。

以上是简要的改造过程，错误之处肯定有，欢迎转载，转载请保留原作者信息，作者：管建丰；交流: funpower(at)gmail.com

以前装双系统时一直发现windows2000下的boot.ini一直找不到，用搜索什么的方法都不行，今天使用的下面的方法，竟然把他给找出来了！

先在开始的运行菜单中打入attrib boot.ini -h -s ，把他的“系统”、“隐藏”属性给去了，然后在运行中打入c:boot.ini，就打开了。

有时编辑了freebsd的rc.conf中的一个项后就要重启很是麻烦，介绍一种不用重启机器就能重启rc.conf的方法，如下：

# cd /etc
# sh rc

昨晚网络中心断电，有一台代理启动不了，提示说文件系统有错误，请检查，印象中记得有个cs开头的磁盘修复工具，但一时想不起来，上chinaunix一搜索，才想起来是fsck命令，打入fsck检测完，重启代理，正常。

补充些fsck的用法(下次要记得了)：

对文件系统进行检查，并对损害的文件系统进行修复。
fsck的语法如下：
fsck (-F fstype) (-v) (-m) (-special…)
fsck (-F fstype) (-v) (-y|Y|n|N)
(-o fstype options) (special…)
其中：
-F fstype : 说明被检查的文件系统的类型
-v : 返回完成的命令行，但不运行
-y|Y: 对所有问题均回答Yes
-n|N: 对所有问题均回答No
-m: 对文件系统进行检查，不修复文件系统，
如果文件系统经检查后是可安装的，则显示
ufs fsck : sanity check : /dev/rdsk/c0t0d0s0 okay.
-o: 文件系统类型选项，选项由逗号分隔，
最常用的选项有两个：
P: 整理(preen)模式
F: 强制检查模式，此选项忽略文件系统状态标志。
1) 移去一个没有相关文件的目录入口　答Yes或Y来删除该目录入口
2) 重连接一个已分配但不能访问的文件
对fsck的"RECONNECT？"回答Yes，即把该I节点连接到lost+found目录下，文件名即是I节点号
3) 连接数调整　回答Yes或Y来改正连接数
4) 自由块表不一致　回答Yes或Y来修正超级块
　　对于fsck询问的问题大多数情况下都可以用Yes来回答，所以在实际应用时，可以用" -y"选项来执行该命令
对硬盘进行检查和修复。

上学期05年1月17日发生了代理服务器mbuf clusters exhausted ，当时只是以为服务器被攻击了，但昨晚（05-04-11）服务器又出现相同的故障，显示All mbuf clusters exhausted , Please see tuning(7) 。局域网上网时断时续，我用SSH登陆到服务器（也时断时续），然后netstat -m 果然

8887/80000/80000 mbufs in use (current/peak/max):
791 mbufs allocated to data
96 mbufs allocated to packet headers
8782/10000/10000 mbuf clusters in use (current/peak/max)
25508 Kbytes allocated to network (25% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines

然后我用netstat -a命令，发现有一个地址192.168.31.97一直出现，占到了整个输出的大半，我想可能问题是出在那台机器上，可能是中毒了。马上检查，发现是中毒了。

今天早上，我在freebsdchina也搜到了delphij的一个关于mbuf的老贴子，也看了昨天我在freebsdchina发的求救贴的回贴，发现了一个问题：导致这种情况不一定是外网的攻击，有可能是你内网的机器中毒发大量数据包的病毒。就像我这台192.168.31.97一样。

可以先这样解决：

1、用netstat -a查看将有异常（在Foreign Address一项中IP的出现次数多的）的机器立即隔断与局域网的连接。

2、把maxuser设置成256

3、编辑/boot/defaults/loader.conf ，编辑kern.ipc.nmbclusters="65536"

4、重启server

看了前辈们的贴子和自己的经历暂时只想到这样解决，如有更好的方法，我想听听老大们是怎么解决的？

这学期刚开始几天，学校校园网基本正常，唯独网络中心至图书馆之间经常数据包丢失（如下），影响了图书馆的正常工作（借还书、采编、阅览室）。具体如下：

网络环境：校园局域网，建筑物间光纤100M，Internet入口电信10M。

网络故障： 图书馆至网络中心之间通信时经常丢包，从网络中心向图书馆ping时情况如下：

C:Documents and Settingsfreebsd>ping 192.168.20.3 -t

Pinging 192.168.20.31 with 32 bytes of data:

Reply from 192.168.20.31: bytes=32 time<1ms TTL=128

Request timed out.

Reply from 192.168.20.31: bytes=32 time<1ms TTL=128

Reply from 192.168.20.31: bytes=32 time<1ms TTL=128

Request timed out.

Request timed out.

Request timed out.

Reply from 192.168.20.31: bytes=32 time<1ms TTL=128

Reply from 192.168.20.31: bytes=32 time<1ms TTL=128

Reply from 192.168.20.31: bytes=32 time<1ms TTL=128

Reply from 192.168.20.31: bytes=32 time<1ms TTL=128

Request timed out.

Reply from 192.168.20.31: bytes=32 time<1ms TTL=128

Reply from 192.168.20.31: bytes=32 time<1ms TTL=128

网络拓扑：图书馆至网络中心拓扑图如下

排除方法1： 网络中心这边维持不动，将图书馆的3COM4400交换机上接到图书馆的办公用机、采编室、阅览室的网线全部拔下，然后拿一台笔记本用一根双绞线单独连到交换机上，在用笔记本ping网络中心的机器，故障依旧。刚开始是怀疑图书馆的机器中蠕虫病毒，现在可以肯定图书馆的所有用机均正常。

排除方法2： 将网络中心和图书馆两边的3COM交换机上连接的网线都拔下，然后各自连接一台笔记本，从一台ping另一台笔记本，故障依旧。可以断定网络中心上连接的计算机也没问题。

排除方法3：  经过上两次排除后，可以断定是光纤或光纤熔接盒或者3COM交换机的问题。

先检查两建筑物之间的光纤和光纤熔接盒里的光纤熔接情况，特请了熔接光纤的人过来看了，说两建筑物间的光纤没问题，但两头光纤熔接盒里的耦合器有松动，而且材质是铜的，通信质量不好，所以换了四个新的材质是陶瓷的耦合器，然后按照排除方法2进行ping，但故障依旧。

排除方法4： 这一次将怀疑目标定在了3COM交换机上，我们用了两对D-LINK的光纤转换器，将耦合器两头出来的尾纤分别连接到D-LINK光纤转换器的光纤端口，然后从两个光纤转换器上的双绞线接口上分别接出两根双绞线连接到两台笔记本上（如下网络拓扑图），

然后开始ping，没有丢包，故障排除！！！然后将网络中心这边恢复正常，然后从图书馆这边的笔记本ping网络中心的网管机，没有丢包；接着将图书馆这的D-LINK光纤转换器上的直接接在笔记本上的双绞线接到3COM交换机的双绞线口上，然后再用双绞线将笔记本和交换机连接，再用笔记本ping网络中心的网管机，也正常，没有丢包。这说明两建筑物间光纤及光纤熔接器及尾纤都没有问题。

总结：从上两张网络拓扑图中可以看出，不同处就在于省略了两个3COM交换机下的光纤模块，问题肯定是出在了光纤模块上了，我记得一块光纤模块和一台3COM交换机的价钱都差不多，怎么就发生在它身上。

利用squid的acl控制语句来控制某些站点的访问，前几天在网络改造时一直没有成功。在squid.conf中acl字段如下：

acl web src 192.168.20.0/24
http_access allow web
acl badsite dstdomain 17lele.com
acl badurl url_regex -i sex
http_access deny badsite
http_access deny badurl
acl all src 0.0.0.0/0.0.0.0
http_access deny all

今天刚看了CNFUG十六期Horus的一篇文章–在FreeBSD上安装Squid，才再次去试着改一下，最后明白：上次我是装禁止站点的语句加在了

acl web src 192.168.20.0/24
http_access allow web

的后面，所以就省略了我新加的这两句。所以我将badsite和badurl字段的两句放到前面，重启，成功禁止了17lele.com和带sex字段的网址。如下：

acl badsite dstdomain 17lele.com
acl badurl url_regex -i sex
http_access deny badsite
http_access deny badurlacl web src 192.168.20.0/24
http_access allow web
acl all src 0.0.0.0/0.0.0.0
http_access deny all

附上acl语句详细说明:

ACL,Access Control List,访问控制列表.它的语法是: (在/usr/local/squid/etc/squid.conf里添加)
acl 表名 表类型 [-i] 表的值
http_access [allow/deny] 表名下面分条解释:
表名:可以自定义
表类型:表类型有
src 源地址:客户机的IP地址
dst 目的地址:服务器的IP地址
srcdomain 源域:客户机所属的域
dstdomain 目的域:服务器所属的域
url_regex URL正则表达式(字符串部分)
urlpath_regex URL正则表达式中的路径
time [星期] [时间段]
maxconn 客户端的最大连接数
-i 这个参数使Squid不区分大小写
表的值:随表的类型不同而不同
注意:time中的星期要用如下字符:
S (Sunday,星期日) M(Monday,星期一) T(Tuesday,星期二) W(Wednesday,星期三)
H(Thursday,星期四) F(Friday,星期五) A(Saturday,星期六)
时间段的表示方式是: XX:00-YY:00 如: 20:00-22:00
http_access 选项允许你设置一个表是允许(allow)还是拒绝(deny)
下面举几个例子: 防3721的ACL.在squid.conf中加入:
acl badurls dstdomain -i www.3721.com www.3721.net download.3721.com cnsmin.3721.com
http_access deny badurls
acl badkeywords url_regex -i 3721.com 3721.net
http_access deny badkeywords
解释:
badurls 和 badkeywords 是你自定义的表名.
dstdomain 是服务器的域名(目的域) 而 url_regex 则是URL正则表达式(字符串部分)包含的内容.
http_access 选项的 deny 则是把表badurls和表badkeywords的访问拒绝.
禁止下载Flash:
acl badfiles urlpath_regex -i .swf$
http_access deny badfiles
大家在今后的配置中,慢慢体会ACL的用法吧! 达到目的喽:
错误
您所请求的网址（URL）无法获取
——————————————————————————–
当尝试读取以下网址（URL）时： http://www.3721.com/ 发生了下列的错误：
Access Denied. 拒绝访问
Access control configuration prevents your request from being allowed at this time. Please contact your service provider if you feel this is incorrect. 当前的存取控制设定禁止您的请求被接受，如果您觉得这是错误的，请与您网路服务的提供者联系。 本缓存服务器管理员：[email protected]

一台代理，内网网卡ping内网地址不通，ping自己localhost也不通，提示是：

fun@ns[/etc]ping localhost
PING localhost (127.0.0.1): 56 data bytes
No route to host
No route to host
No route to host

折腾了两天，开始以为是网卡的地址或驱动掉了，但用ifconfig都能看到两块网卡，地址也绑着：

fun@ns[/etc]ifconfig -a
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 218.90.159.29 netmask 0xfffffff8 broadcast 218.90.159.31
        inet6 fe80::250:baff:fe66:413e%vr0 prefixlen 64 scopeid 0x1
        ether 00:50:ba:66:41:3e
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
em0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        ether 00:d0:b7:b9:82:92
        media: Ethernet autoselect
        status: no carrier
vr1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.8.254 netmask 0xffffff00 broadcast 192.168.8.255
        inet6 fe80::205:5dff:fee4:7254%vr1 prefixlen 64 scopeid 0x3
        ether 00:05:5d:e4:72:54
        media: Ethernet autoselect (100baseTX)
        status: active
lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
faith0: flags=8002<BROADCAST,MULTICAST> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
        inet 127.0.0.1 netmask 0xff000000

直到今天才想起来服务器开始了ipfilter并且默认阻止所有包通过。再看一下/etc/ipf.conf:

pass out on vr0 all
pass in on vr0 all
pass out on vr1 all
pass in on vr1 all
pass out log on vr0 proto icmp all keep state
pass out log on vr0 proto tcp/udp from any to any keep state

果然，没将lo0(回路网卡接口)口加入ipf.conf，立刻加入如下两句在ipf.conf中:
pass out on lo0 all
pass in on lo0 all

保存后reboot，再ping自己localhost和内网地址，通了：）

fun@ns[/etc]ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.131 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.066 ms
^C
— localhost ping statistics —
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.066/0.099/0.131/0.033 ms
fun@ns[/etc]ping 192.168.8.8
PING 192.168.8.8 (192.168.8.8): 56 data bytes
64 bytes from 192.168.8.8: icmp_seq=0 ttl=128 time=0.431 ms
64 bytes from 192.168.8.8: icmp_seq=1 ttl=128 time=0.326 ms
64 bytes from 192.168.8.8: icmp_seq=2 ttl=128 time=0.359 ms
^C
— 192.168.8.8 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.326/0.372/0.431/0.044 ms

[总结] 原因:回路地址lo0没有加入ipf.conf中。以后真得注意了，记得上次我也犯过这错，可这次出故障时就是想不起来，以后得记得这种事情应该多总结，多记记，好记性不如烂笔头，有道理: )