linux&F-Stack(FreeBSD)多vlan VIP策略路由设置

假设我们的服务器上有如下vlan和ip的配置

vlan 10:
IP:10.10.10.10 netmask:255.255.255.0 broadcast:10.10.10.255 gateway:10.10.10.1
外网VIP:110.110.110.0/24中的一个或多个IP,如110.110.110.110

vlan 20:
IP:10.10.20.20 netmask:255.255.255.0 broadcast:10.10.20.255 gateway:10.10.20.1
外网VIP:120.120.120.0/24中的一个或多个IP,如120.120.120.120

vlan 30:
IP:10.10.30.30 netmask:255.255.255.0 broadcast:10.10.30.255 gateway:10.10.30.1
外网VIP:130.130.130.0/24中的一个或多个IP,如30.130.130.130

外部主要访问各个vlan里的vip,需要系统应答包也正确的对应的vlan回复到该vlan的gateway地址上,下面为linux系统和F-Stack(FreeBSD)的策略设置方式

Linux 系统路由配置

创建 vlan 并设置 IP 地址

ip link add link eth0 name eth0.10 type vlan id 10
ifconfig eth0.10 10.10.10.10 netmask 255.255.255.0 broadcast 10.10.10.255 up
route add -net 10.10.10.0/24 gw 10.10.10.1 dev eth0.10

ip link add link eth0 name eth0.20 type vlan id 20
ifconfig eth0.20 10.10.20.20 netmask 255.255.255.0 broadcast 10.10.20.255 up
route add -net 10.10.20.0/24 gw 10.10.20.1 dev eth0.20

ip link add link eth0 name eth0.30 type vlan id 30
ifconfig eth0.30 10.10.30.30 netmask 255.255.255.0 broadcast 10.10.30.255 up
route add -net 10.10.30.0/24 gw 10.10.30.1 dev eth0.30

# 设置各 vlan 的外网 VIP
ifconfig lo.0 110.110.110.110 netmask 255.255.255.255
ifconfig lo.1 120.120.120.120 netmask 255.255.255.255
ifconfig lo.2 130.130.130.130 netmask 255.255.255.255

设置策略路由

echo "10 t0" >> /etc/iproute2/rt_tables
echo "20 t1" >> /etc/iproute2/rt_tables
echo "30 t2" >> /etc/iproute2/rt_tables

# 设置各 vlan 的路由表, 并设置对应的网关地址
ip route add default dev eth0.10 via 10.10.10.1 table 10
ip route add default dev eth0.20 via 10.10.20.1 table 20
ip route add default dev eth0.30 via 10.10.30.1 table 30

#systemctl restart network

# 从对应 VIP 出去的包使用对应 vlan 的路由表
ip rule add from 110.110.110.0/24 table 10
ip rule add from 120.120.120.0/24 table 20
ip rule add from 130.130.130.0/24 table 30

F-Stack(FreeBSD) 路由配置

前提条件:在 F-Stack 的 lib/Makefile中打开默认关闭的ipfw选项,并重新编译 F-Stack lib 库,各个工具及应用程序

# NETGRAPH drivers ipfw
FF_NETGRAPH=1
FF_IPFW=1

创建 vlan 并设置 IP 地址

ff_ifconfig -p 0 f-stack-0.10 create
ff_ifconfig -p 0 f-stack-0.10 inet 10.10.10.10 netmask 255.255.255.0 broadcast 10.10.10.255

ff_ifconfig -p 0 f-stack-0.20 create
ff_ifconfig -p 0 f-stack-0.20 inet 10.10.20.20 netmask 255.255.255.0 broadcast 10.10.20.255

ff_ifconfig -p 0 f-stack-0.30 create
ff_ifconfig -p 0 f-stack-0.30 inet 10.10.30.30 netmask 255.255.255.0 broadcast 10.10.30.255

# 设置各 vlan 的外网 VIP
ff_ifconfig -p0 f-stack-0.10 inet 110.110.110.110 netmask 255.255.255.255 alias
ff_ifconfig -p0 f-stack-0.20 inet 120.120.120.120 netmask 255.255.255.255 alias
ff_ifconfig -p0 f-stack-0.30 inet 130.130.130.130 netmask 255.255.255.255 alias

设置策略路由

# 设置各 vlan 的转发路由表(fib), 并设置对应的网关地址
ff_route -p 0 add -net 0.0.0.0 10.10.10.1 -fib 10
ff_route -p 0 add -net 0.0.0.0 10.10.20.1 -fib 20
ff_route -p 0 add -net 0.0.0.0 10.10.30.1 -fib 30

# 将对应 VIP 发出去的数据包设置对应 vlan 的 fib num,以便使用正确的转发路由表(fib)
ff_ipfw -P 0 add 100 setfib 10 ip from 110.110.110.0/24 to any out
ff_ipfw -P 0 add 200 setfib 20 ip from 120.120.120.0/24 to any out
ff_ipfw -P 0 add 300 setfib 30 ip from 130.130.130.0/24 to any out

参考资料

  1. F-Stack vlan 的支持与使用
  2. Nginx TCP 多证书透明代理及 Linux/F-Stack(FreeBSD) 路由相关设置
  3. linux 和 FreeBSD 相关工具的 man page

IOS 16 异常降级到 tls1.0 的问题

最近碰到个客户问题,微信公众号里有个服务链接,在 IOS 下偶发失败,报错 -1200,经过排查发现是 IOS 16 在特定情况下可能会出现发起的 https 请求降级为了 tls1.0 导致的。

排查过程

简单发几条排查的发现和截图,怀疑是 IOS 16 的网络请求有什么 bug 导致非正常的降级到了 tls1.0,而 tls1.0 宣称在 IOS 15 后已经不再支持,如果有 IOS 客户端同学可以看看具体是什么原因导致的

  • 只有 IOS 出现,目前发现的 case 都为 IOS 16,包括 16.0 和 16.1 ;9 月底之后开始出现;微信、chrome、safari、qq浏览器等都可以复现。
  • 服务端在香港,开启 UDP 的 443 端口,但是该业务域名并未配置开启 HTTP3(QUIC),请求如下所示
curl --http3 -vvv https://xxxx.cn/
*   Trying x.x.x.x:443...
* Connect socket 5 over QUIC to x.x.x.x:443
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
*  subjectAltName does not match xxxx.cn
* SSL: no alternative certificate subject name matches target host name 'xxxx.cn'
* connect to x.x.x.x port 443 failed: SSL peer certificate or SSH remote key was not OK
* Failed to connect to xxxx.cn port 443 after 102 ms: SSL peer certificate or SSH remote key was not OK
* Closing connection 0
curl: (60) SSL: no alternative certificate subject name matches target host name 'xxxx.cn'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
  • 开启 H3 协商失败后降级到 http1.1,使用tcp请求,此时客户端发起的请求在服务端应答 syn+ack 后,经常性的会出现客户端直接rst连接的情况(110-160ms左右收到 syn+ack, 130ms的应答也可以正常连接),检查客户端发起的syn和服务端回复的 syn+ack,并没有发现什么异常。与未被客户端 rst 的请求/应答包也没什么异常区别。
    HTTP3协商失败和客户端TCP rst 貌似总是同时出现。
  • 如果连接未被 rst,则可能发起 tls1.3 或 tls1.0 的请求,如果发起 tls1.3 的请求,则可以正常请求应答
  • 如果客户端发起 tls1.0 的请求,如果服务端未开启 tls1.0 的支持,则无法正常握手;如果服务端开启tls1.0,因为客户端发起的 client hello中 携带了TLS_FALLBACK_SCSV标记,服务端则返回 Inappropriate Fallback错误,还是无法握手,如下所示。

临时规避方案

  1. 正确配置服务器的HTTP3(QUIC)
  2. 完全关闭服务器的HTTP3(QUIC)端口,即UDP 443

其他

腾讯云 DNSPod 已经支持 HTTPS(type65)记录类型设置,正确设置后可以对 IOS14 以上的访问有一定的优化作用。

该记录类型尚处于草案阶段, 腾讯云 DNSPod 后续会持续关注并跟进相关草案的更新。