Skip to main content

Nichi Yorozuya

Networking

       好久不见,网课还上的快乐吗( 又咕咕了好久呢,这次来写写关于networking的事。前些时日注册了自己的ASN,我也成为了能在公网上漏油的one man NOC了呐。然而由于贫穷我的上游只有Vultr和HE,在公网BGP上并没有很大的操作空间,虽然收了全表,但是import none,because why not?故而工作的重心更多的放在了overlay network上。现有的overlay network方案其实非常多,从tinc、zerotier到weave,还有新的nebula,他们都有着先进的控制平面,为使用者带来了极大的便利,但是也都存在着各自的问题。先从共性问题而言,他们大多提供的是二层转发,从使用的便利性而言,大二层确实很快乐,但在大规模的overlay network中,二层有着严重的scalability issue,同时也难以优化路由。各自而言,首先是tinc,tinc作为一个历史悠久的项目,长期支撑着tuna内部某个申必网络的运作,打洞、自发现、加密,tinc拥有可以想到的各种feature,然而它的转发平面性能一言难尽。再说zerotier,单就运作模式而言,zt更加接近SDN的意义,一个中心化的控制平面,但它的性能更糟糕….weave是一个奇妙的选择,它的原意是container networking,但也可以在host machine之间提供连接,虽然工作在用户态,他会使用内核中的Open vSwitch Datapath加速包转发,并使用IPSec加密,听上去是一个never reinvent the wheel的优秀方案呢。在实际的实验中,他也确实表现出了非常优异的包转发性能。但是!我没能找到一个关闭weave的二层转发的方式,更令人失望的是当需要转发时他会fallback到用户态转发。综上所述,我们的实际需求是:一个三层的隧道(既然不需要二层我们也没有理由承担ethernet头带来的额外overhead),同tinc一样,我们也希望能继续使用公钥体系加密,避免PSK带来的隐患,我们也希望他是一个内核态的隧道,来获得较优的转发性能。

       A.K.A. wireguard。I’m limited by the technology of my time。满足这所有需求的,似乎就只有wireguard了。当然wireguard也不是一个完美的方案,它最大的问题有两点,首先是AllowedIP的机制,使得它几乎不可能与routing daemon妥善共存,另外一点则是sticky socket,这本是一个feature,但也导致wireguard所使用的UDP socket无法绑定至特定源地址,限制了他在具有多个上游的节点或是双栈节点上的使用。对于AllowedIP,解决方法虽说不漂亮,但是it works(,将它作为peer to peer的隧道使用,AllowedIP = ANY即可,(会有114514个interface就是了)(塞在netns里不就好了)。而对于bind to IP的问题,WIP。

       wireguard作为一个全新的项目,相关的轮子也不多,有几个自动组网的,但都是单interface的架构,不曾考虑到与routing daemon的结合,故而我不得不造了个新轮子:RAIT,确保了link scope的通联,而对于site scope的通联性则是选择了babel作为路由协定,以从RTT的角度优化网络路径。netns的使用被证明是一个优秀的决定,每个节点的维护者往往会构建自己的路由策略,在以往的网络中,每个节点的网络栈同时又是整个cluster的转发平面,路由策略也会影响到整张网络,而netns的使用确保了一个不受干扰的转发平面,大大提升了网络的可靠性。在接下来的工作上,首先为wireguard添加bind to IP的支持自然是重点,同时在scalability上,目前的架构是由babel同时承担了内部与外部路由的广播,并非可取之举,故而与BGP的整合也值得探索。