所以在启用ipfw的时候，会启用默认禁止的全部连接的规则，那么直接的后果是把ssh的连接踢下线，并切断外界到这个服务器一切端口的连接请求。

解决方案，在启用ipfw后，马上加入一条允许所有请求的规则:

kldload ipfw && ipfw add 65534 allow ip from any to any

另外需要注意一点：绝对禁止使用/sbin/ipfw -q -f flush，会导致把上面这条手动添加的开放规则删除！

同时，如果想在重启后ipfw也开启生效，那么需要这样做：

在/etc/rc.conf里加入:

firewall_enable="YES"
firewall_script="/etc/firewall.sh"


同时/etc/firewall.sh的内容是

#!/bin/sh
/sbin/ipfw -q -f flush
/sbin/ipfw add 65534 allow ip from any to any


同时自定义的ipfw规则也可以向/etc/firewall.sh中添加，比如阻止118.215.66.135到本机80端口的连接，那么加入

/sbin/ipfw add 1 deny ip from 124.193.167.1 to any dst-port 80


• 加入zfsloader；
• zpool升级到14版本；
• UFS和ZFS支持NFSv4 ACL，并且添加入到cp(1), find(1), getfacl(1), mv(1), 和 setfacl(1)；
• 添加对Sun UltraSPARC IV/IV+和 SPARC64 V的CPU支持
• 对IBM PowerPC G5加入SMP支持
• BIND升级到9.6.2-P2
• sendmail升级到8.14.4
• OpenSSH升级到5.4p1
• GNOME 2.30.1, KDE 4.4.5

详细的release announcement详见 http://www.freebsd.org/releases/8.1R/announce.html

从日本的Mirror下载ISO可以到100KB/s +，ftp://ftp.jp.freebsd.org/pub/FreeBSD/

1,  kernel update
2,  ports update

# portsnap fetch extract update

3, kernel configure

# cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/kernel_ipsec
# cat >> /usr/src/sys/i386/conf/kernel_ipsec << _EOF_
options  IPSEC
options  IPSEC_ESP
device   gif
_EOF_

# cd /usr/src
# make buildkernel KERNCONF=kernel_ipsec
# make installkernel KERNCONF=kernel_ipsec

4,  Edit tunnel – /etc/rc.conf
host 1:

gif_interfaces="gif0"
gifconfig_gif0="A.B.C.D W.X.Y.Z"
ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff"
static_routes="vpn"
route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00"

host 2:

gif_interfaces="gif0"
gifconfig_gif0="W.X.Y.Z A.B.C.D"
ifconfig_gif0="inet 192.168.2.1 192.168.1.1 netmask 0xffffffff"
static_routes="vpn"
route_vpn="192.168.1.0 192.168.1.1 netmask 0xffffff00"

5, do tunnel commands
host 1:

# ifconfig gif0 create
# ifconfig gif0 tunnel A.B.C.D W.X.Y.Z
# ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff

host 2:

# ifconfig gif0 create
# ifconfig gif0 tunnel W.X.Y.Z A.B.C.D
# ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff

6, enable ipsec – /etc/rc.conf

ipsec_enable="YES"
ipsec_file="/etc/ipsec.conf"

7, setkey – /etc/ipsec.conf
host 1:

spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;

host 2:

spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;

8, enable racoon in /etc/rc.conf

racoon_enable="YES"

9,  racoon configure

# mkdir -p /usr/local/etc/racoon
# echo "A.B.C.D password" > /usr/local/etc/racoon/psk.txt
# chmod 0600 /usr/local/etc/racoon/psk.txt
# cat >> /usr/local/etc/racoon/racoon.conf << _EOF_
path pre_shared_key "/usr/local/etc/racoon/psk.txt";

remote anonymous
{
exchange_mode main,aggressive,base;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key ;
dh_group 2 ;
}
}
sainfo anonymous
{
pfs_group 2;
lifetime time 12 hour ;
encryption_algorithm 3des, cast128, blowfish 448, des, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
_EOF_

10, add route

/sbin/route add -net 10.55.0/16 192.168.1.101
/sbin/route add -net 172.16.0/16 192.168.1.101
/sbin/route add -net 10.69.0/16 192.168.1.101

11, /etc/sysctl.conf

# echo 'net.inet.ip.forwarding=1' >> /etc/sysctl.conf
# sysctl net.inet.ip.forwarding=1

11, ipsec boot

# setkey -F
# setkey -FP
# setkey -f /etc/ipsec.conf
# /usr/local/etc/rc.d/racoon start

12, Done!

IO模型

GNU/Linux I/O模型图略：

已知的IO模型有三种：阻塞同步(blocking synchronous) ，阻塞异步(blocking asynchronous)，非阻塞同步(non-blocking synchronous) 和非阻塞异步(non-blocking asynchronous) 。

阻塞同步(blocking synchronous)：必须等待操作的完成，否则只有等待。在此模型中，应用程序执行一个系统调用，会导致应用程序一直阻塞，直到系统调用执行完毕（成功或返回错误码）。例如：去ATM取钱，前面有人正在取钱，你只有等待此人完成后才能开始。

典型的read/write系统调用即是阻塞同步式IO，如图所示：

阻塞异步(blocking asynchronous)：select(2)和poll(2)都是这种模型，select(2)调用本身会导致系统的阻塞，但是后续的处理是异步进行的，如图所示：

非阻塞同步 (non-blocking synchronous)：同步操作，但是当资源不可用时，此调用将会立即返回，并得到通知指示资源不可用；否则立即开始。对应前面取钱例子，当你发现ATM前已经有人正在取钱，你立即放弃取钱，继续干以后的事情。在open(2)文件时加入O_NONBLOCK标志的read(2)系统调用的过程如下：

非阻塞异步 (non-blocking asynchronous)：异步最重要的是调用方和被调用方的非阻塞运行。我要给你指派任务；好，如果操作立即完成，你会立即返回给我结果；否则就告诉我说你在执行中，完成了再通知我，我接着干自己的事情去吧，无须等待。对应前面例子，你发现前面有人在取钱，你立即委托他帮你取钱，然后立即做下一件事，被委托人取好将交给你。自然的必须提供一种机制，以期能在任务完成时让我得到通知。GNU/Linux的aio_read(2)系统调用的示意图：

阻塞式模型的问题

首先传统的poll()和select()方式在接受大量连接请求时会有以下问题：

0，kernel<->user space的内存拷贝代价。一但一个请求到来之后，无论其是否被处理都会有一次从kernel -> user space的内存拷贝；

1，应用程序需要扫描所有已经打开的文件描述符，根据kernel标记的状态来判断其是否就绪；因为系统内核已经知道了每个FD的状态，那么在app中的这个线性操作( O(N) )显然是一个重复劳动（显而易见的一个更好方式是kernel直接把就绪的FD告诉app)；

2，同时在kernel内部对于select()的实现也不理想。首先必须在内存中保存在一个所有打开FD的列表；其次在一个连接到来时，kernel需要遍历这个列表找到空闲的FD。

这个问题的根源在于操作系统内核没有去记录每个应用程序关注的FD的状态和记录应用程序对应不同状态所要应用的操作（注册回掉函数）。

而epoll/kqueue/IOCP就针对以上3个问题采用了原理相同，但是细节略有差异的解决方法。

epoll kqueue IOCP

常规的select()操作是一个同步阻塞式的操作，如果要改变它的这些不足，需要将其改变为“非阻塞的同步”或“非阻塞的异步”。

非阻塞异步的好处是程序无需以相对较高的切换开销（如前文所说开销来自kernel <-> user 的切换，找到就绪FD的开销等）。

epoll

linux kernel 2.5开始引入到2.6内核已经非常成熟，包括Edge Triggered (ET)和Level Triggered (LT)两种工作方式。

LT(level triggered，水平触发)是默认方式，并且同时支持blocking和non-blocking 的IO操作。在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行后续操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。

ET(edge-triggered，边缘触发)是高速工作方式，只支持no-blocking IO。在这种模式下，当文件描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个已经就绪的文件描述符发送更多的通知，等到下次有新的文件描述符就绪才会再次出发就绪通知。

kqueue：FreeBSD 4.x引入。

IOCP：windows 2000引入。

未完，继续。