大家去面试的时候，经常都让简单介绍TCP的三次握手。上半年我也去面试了一下，问了十多个人，基本都只能简单说出三次握手的SYN，ACK-SYN，ACK的发送顺序。不过基本没有人能完成说出三次握手的关键所在。 三次握手的功能主要实际包括几种：1. 接触和通信。2. 序列号的交换。client和server端把自己的初始序列号isn（一个随机数）告诉对方。3. MSS协商，协商发送报文的最大长度。4. 交换其他的参数。比如窗口比例因子(Window Scale Factor)等等
ospf协议中是有多种网络类型：1. 点到点网络（p2p）2. 广播网络(broadcast)3. 非广播多路访问(nbma)4. 点到多点(p2mp)5. 虚链路(virtual links) 其中只有广播类型和非广播多路访问是有DR,BDR的。其他三种网络类型都是没有DR,BDR的。比如P2P的 对于广播类型和非广播多路访问类型的OSPF，都是需要靠DR(BDR)来做LSA的floodding。比如有路由器R1,R2,R3,R4,R5。如果R1选举为了DR，R2是BDR，那么实际R2，R3,R4,R5都只与R1形成邻接关系。R1-5将会继续发hello包到224.0.0.5这个组播地址。更新数据包的发送是R3-R5会以组播的方式发送到组播地址224.0.0.6（只有R1 R2监听这个地址），DR收到后再使用组播发到224.0.0.5更新整个区域的LSA。
今天同事问了个dnat的问题，就是在linux服务器上把某个端口的流量dnat到上面跑的某个kvm虚拟机上没有正常工作，简单看了下就是ip_forward没有打开。。想着自己也很多没有搞过这些了，简单试试snat+dnat。基本的结构是目的使用192.168.100.17做代理服务器，专门做SNAT+DNAT，练习NAT的使用。 192.168.125.135(client)–>192.168.100.17(NAT机器)–> 192.168.128.26(DNS服务器)可以看到这几个IP都不在同一个24掩码的vlan内，所以没有办法把NAT机器设置成DNS机器的网关。所以配置上更加复杂一点，不过也便于理解nat的工作流程。实际就是在prerouting和postroute的对包的操作了。 先在 192.168.100.17上设置DNAT，让从192.168.125.135进来的dns查询包的目的IP修改为192.168.128.26```bash #iptables -t nat -A PREROUTING -i bond0 -p udp –dport 53 -j DNAT –to-destination 192.168.128.26:53 192.168.100.17上设置SNAT，把上面的包在经过路由表后，出去前把source ip改了。```bash #iptables -t nat -A POSTROUTING -o bond0 -p udp -d 192.168.128.26 –sport 53 -j SNAT –to-source 192.168.100.17
一般的流量镜像需要在交换机上做，实际上iptables也有个tee模块做流量镜像。在OpenWrt里使用也比较简单。1. 把tee模块安装上加载进去（需要依赖ipv6模块）```bash opkg install kmod-ipt-tee 2.把某个源IP的包镜像发到指定的IPiptables -t mangle -A PREROUTING -s 192.168.3.224 -j TEE –gateway 192.168.3.100 4. 删除规则iptables -t mangle -F 5. 也可以把整个网段的都镜像root@wan:/etc/config# iptables -t mangle -A PREROUTING -s 192.168.3.0/24 -j TEE –gateway 192.168.3.100root@wan:/etc/config# iptables -t mangle -A POSTROUTING -d 192.168.3.0/24 -j TEE –gateway 192.168.3.100 上图是抓包手机 微博和易讯客户端打开的的DNS查询。
这两年ospf这个内部网关协议在互联网公司的链路负载均衡上出现的频率越来越高，BAT公司都是用OSPF+LVS做负载均衡。连小米这样的公司也开始这样玩了。ospf的配置实际是比较简单的，主要是一般就网工比较了解这个，其他部门的人都这些都没有任何概念，觉得很生疏。简单贴2个配置文件。 quagga实际是个套件，里面有zebra，ospfd，ripd，bgpd等等。其中zebra是ip路由管理进程，可以去更新kernel的路由、更新本地接口的地址或者在把一个的路由协议的路由表重分发到其他重分发到其他的路由协议，比如把ospfd里的发到bgpd里去。ospfd、ripd、bgpd是各自负责ospd，rip，bgp协议的守候进程。所以一般我们在本地服务器上配置ospf会涉及2个配置文件，一个是zebra的zebra.conf，另外一个是ospfd的ospfd.conf。服务器的上联模式可以选择单上联或者双上联，具体的细节配置需要根据实际的硬件条件（主要是看上联交换机，千兆上联的交换机一般比较屌丝，LSA的支持可能也不够完善，最好使用单上联的模式）；默认路由可以本地配置死，也可以就默认通过ospfd从上联交换机学习默认路由，我一般比较推荐千兆上联直接配死。 架设服务器有4个网卡，eth0,eth1做bond连本地的内网接入交换机，eth2单上联到专门配置ospf的交换机。eth2和上联交换机的互联IP是：192.168.20.100/30这个网段，本地使用192.168.20.102这个互联地址，交换机上配置192.168.20.101.本地可以宣告的地址是192.168.200.0/24内的任意地址。 zebra.conf hostname "XXXX" password xxxx enable password xxxxx log file /var/log/zebra.log log syslog interface lo interface bond0 link-detect interface eth2 link-detect #配置link-detect的好处是链路短掉后上层交换机马上能感知，否则只能等ospf的hello超时才会把这个链路标记为不可用。可以缩短链路故障后的影响时间 interface eth3 ospfd.conf hostname XXXX password xxxx enable password xxxx log file /var/log/ospf.log interface bond0 interface eth3 interface eth2 ip ospf network point-to-point ip ospf message-digest-key 1 md5 PASSWORDXXX ip ospf hello-interval 1 ip ospf dead-interval 3 interface lo router ospf ospf router-id YOU_LOCAL_IP network 192.168.20.102/30 area 0.0.0.102 network 192.168.200.0/24 area 0.0.0.102 area 0.0.0.102 authentication message-digest line vty ospfd.conf里需要在interface里配置好网络类型，验证的密码，hello-interval和dead-interval时间。router ospf里需要把互联地址的网段配在network里，也要把想宣告的网段配置在里面。ospfd会把在这个网段内的接口分配后面指定的area里。 ...
一般我们在服务涉及多个网段的时候是直接配置一下策略路由，达到哪个口进哪个口出的目的。最近手上又批机器，因为各种原因。机器上2个网卡各上联到不通的交换机，每个网卡配置的IP也是不同的。考虑到单个交换机挂掉的情况，我就直接配置了2个默认的网关，设置不同的优先级。配置相对简单，单个交换机挂掉的时候还能工作。 #cat route-eth0 default via 10.20.25.1 metric 1 [root@test /etc/sysconfig/network-scripts] #cat route-eth1 default via 10.20.25.12 metric 2 [root@test/etc/sysconfig/network-scripts] # 另外需要注意设置一下rp_filter允许从1个网卡进来的包走另外一个网卡出去。 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0 net.ipv4.conf.eth1.rp_filter = 0
无论是权威还是递归DNS，防攻击都是特别需要的。但是现在一般开源的bind在这方面又总是有些欠缺。最近一段时间一直在查看相关的文档。 对于普通的ISP的递归DNS，一方面只允许自己的客户IP段来递归，另外可以配合使用rrl限流模块。rrl限流模块在有大量请求的时候还是可以起到不少作用的。只是这个限流的值需要把握好。 对于自己单独搞的递归DNS。类似114的这种，一般使用anycast模式，多个机房间用BGP进行流量分配，硬抗的能力能提升不少;另外就是做流量清洗，可以学习到每个IP段正常的DNS请求进入时候的TTL值，一般的DNS伪造的攻击很难试出这个正常的TTL值。 最简单的模式，也可以抓包做流量分析，直接把疑似黑名单封了。
time-wait其实本来没有啥，但是经常成为让大家恐惧的东西。比如大家一直在试图降低web服务器、代理服务器上的time-wait数量。time-wait本身的作用是提供全双工关闭、过时重复报文段失效，其实也没有什么。唯独是在做反向代理的时候需要特别注意time-wait过多的情况，主要是做代理的时候容易出现tw状态过多把本地端口耗完的情况。一般缓解的方法：1. 改成使用长连接去连后端的服务器。2. 修改ip_local_port_range增加可用的端口范围3. 同时打开tcp_tw_reuse和tcp_timestamps选项，这样收到最后1个包后1s后可以开始重用。这个是在tcp_ipv4.c里定义的 /* With PAWS, it is safe from the viewpoint of data integrity. Even without PAWS it is safe provided sequence spaces do not overlap i.e. at data rates <= 80Mbit/sec. Actually, the idea is close to VJ's one, only timestamp cache is held not per host, but per port pair and TW bucket is used as state holder. If TW bucket has been already destroyed we fall back to VJ’s scheme and use initial timestamp retrieved from peer table. */ if (tcptw->tw_ts_recent_stamp && ...
线上有的服务器停机应用比较大，单身如果又遇到网络驱动之类的有bug那就麻烦了，徘徊于等死与找死之间。想着所有的机器都是双上联做了bond的，可不可以一次升级一个网卡呢？做了bond单次挂1个网卡应该是无损的。 上周把我的这个想法给内核组的同学说了，没有想到这周就给出了具体的方案。我自己稍微测试了下，把脚本的一些细节地方修改了下昨天测试2个网卡连续切换驱动10次无丢包。 不过有实际的大流量的时候还有待验证。
SPF（发信方策略框架）记录就是在txt记录(现在也有专门的spf记录)里标明该域的邮件只能从指定的服务器发出，否则都是假冒的。现在有2个版本,spf1和spf2。不过被转发的邮件就不能通过SPF检查的。比如用163的邮箱给一个用gmail的人发邮件，对方又把自己的邮箱直接转发到了qq的邮箱上，这样就不能通过spf校验。简单看看spf格式的txt记录：dig -t txt google.comgoogle.com. 3600 IN TXT “v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all” 继续dig -t txt _spf.google.com 结果是“v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all”再继续