Linux的Netfilter钩子点的位置会导致一些奇怪的问题，比如本机发出的包无法使用基于mark的策略路由，这是因为mark一般是在Netfilter中进行的，而Linux的路由处在OUTPUT钩子点之前，因此这是一个顺序倒置的问题，如何来解决呢?只能在路由之前打上mark，而我们知道，对于外部进入的包，mark是在PREROUTING进行的，因此对于外部进入的包，策略路由是好使的，对于本机发出的包，路由之前只能是socket层了，那为何不能在传输层做呢?因为一来传输层比较杂，二来很多协议直接走到IP层，比如OSPF之类的，三来很多传输层协议也需要路由查找，比如TCP在connect的时候就需要查找路由以确定源IP地址(如果没有bind的话)。

幸运的是，Linux的socket支持SO_MARK这样一个option，可以很方便的使用：

mark = 100;

setsockopt(client_socket, SOL_SOCKET, SO_MARK, &mark, sizeof(mark));

1.对TRACK的影响

虽然raw表是数据包经过的第一个表，使用SO_MARK仍然可以在整个raw表起作用之前做点mark，从而使得一个特定socket发出的包统统NOTRACK：

iptables -t raw -A OUTPUT -m mark --mark 100 -j NOTRACK

如果不这样的话，就需要：

iptables -t raw -A OUTPUT [-s xxxx] [-d yyyy] [-p tcp|udp [--sport X] [--dport Y] ... -j MARK --set-mark 100

...[一大堆和上面类似的规则]

iptables -t raw -A OUTPUT -m mark --mark 100 -j NOTRACK

正如在PREROUTING上的raw表需要做的那样。我们得意于OUTPUT上面是socket，是应用程序的世界，而PREROUTING以下则是内核以及驱动的世界了，后者太杂太乱，不便做更多的事，而前者则是我们可以掌控的范围。

2.对策略路由的影响

SO_MARK最大的受益者就是策略路由了，如果我们这是以下的路由：

ip rule add fwmark 100 table abc

ip route add 1.2.3.4/32 via 192.168.0.254 table abc

ip route del 1.2.3.4/32 table main

不设置SO_MARK的情况下，所有的访问1.2.3.4的流量将因为没有路由而被丢弃，因为在进入PREROUTING前首先要查找路由，而此时还没有打上mark，因而不会匹配到abc策略表中的那条路由，而main表中的对应路由我们已经删除了...但是如果我们在应用程序中加入：

mark = 100;

setsockopt(client_socket, SOL_SOCKET, SO_MARK, &mark, sizeof(mark));

访问就可以正常了，因为在查找路由的时候，已经有这个mark了。