主页 / server / 问题 / 1053636
Accepted
Volodymyr Melnyk
Asked: 2021-02-15 10:22:00 +0800 CST

从远程网络到 Kubernetes 集群的 VPN

  • 772

我需要在网络和 Kubernetes 集群之间建立 VPN 连接，因此在该网络中托管的应用程序可以通过安全隧道访问 K8S 服务。

所以，我在自托管环境中有一堆 K8S 节点。我在这个环境中添加了一个单独的服务器，这个服务器作为一个 VPN 网关工作，它连接到集群节点所连接的同一个 VLAN。节点具有以下 IP 地址：10.13.17.1/22、10.13.17.2/22等10.13.17.3/22。VPN 网关具有10.13.16.253/22.

Cluster IP CIDR 是10.233.0.0/18，pod IP CIDR 是10.233.64.0/18。

VPN 服务器支持与远程网络的 IPSec 站点到站点连接，10.103.103.0/24. 我使用 Calico 作为网络管理器，因此我设置了我的 VPN 服务器以保持与所有 K8S 节点的 BGP 会话。VPN 服务器的路由表充满了 Calico 节点宣布的前缀（10.233.0.0/18当然也存在），集群节点10.103.103.0/24的路由表中还有其他一些网络，所以 BGP 似乎工作正常。到目前为止，一切都很好...

当我从 VPN 服务器与集群内的服务建立连接时，一切都很好。客户端（10.13.16.253）向服务（ ）发送一个 SYN 数据包10.233.10.101:1337，工作人员接收到这个数据包，将其目标 IP 地址更改为 pod 的 IP 地址（10.233.103.49:1337）并将其源 IP 地址更改为某个 IP 地址（10.233.110.0) 这将帮助工作人员接收回复并将其返回给连接发起者。以下是收到此 SYN 数据包的工作人员发生的情况。SYN 数据包到达工人：

22:04:25.866546 IP 10.13.16.253.56297 > 10.233.10.101.1337: Flags [S], seq 3575679444, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1385938010 ecr 0], length 0

SYN-packed 正在被 SNATed 和 DNATed，然后被发送到运行 pod 的工作人员：

22:04:25.866656 IP 10.233.110.0.54430 > 10.233.103.49.1337: Flags [S], seq 3575679444, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1385938010 ecr 0], length 0

回复来了：

22:04:25.867313 IP 10.233.103.49.1337 > 10.233.110.0.54430: Flags [S.], seq 2017844946, ack 3575679445, win 28960, options [mss 1460,sackOK,TS val 1201488363 ecr 1385938010,nop,wscale 7], length 0

回复被 deSNATed 和 deDNATed 发送给连接发起者：

22:04:25.867533 IP 10.233.10.101.1337 > 10.13.16.253.56297: Flags [S.], seq 2017844946, ack 3575679445, win 28960, options [mss 1460,sackOK,TS val 1201488363 ecr 1385938010,nop,wscale 7], length 0

因此，建立了联系，每个人都很高兴。

但是当我尝试从外部网络（10.103.103.0/24）连接到相同的服务时，接收 SYN 数据包的工作人员不会更改源 IP 地址，它只会更改目标 IP 地址，因此数据包的源 IP 地址是不变。SYN 数据包到达工作人员

21:56:05.794171 IP 10.103.103.1.52132 > 10.233.10.101.1337: Flags [S], seq 3759345254, win 29200, options [mss 1460,sackOK,TS val 195801472 ecr 0,nop,wscale 7], length 0

SYN 数据包正在被 DNATed 并重新发送给运行 pod 的工作人员

21:56:05.794242 IP 10.103.103.1.52132 > 10.233.103.49.1337: Flags [S], seq 3759345254, win 29200, options [mss 1460,sackOK,TS val 195801472 ecr 0,nop,wscale 7], length 0

没有任何回应。:-(

因此，我看到目标 IP 地址已更改，因此我可以在运行 pod 的工作人员上看到这些数据包，但没有对它们的回复：

21:56:05.794602 IP 10.103.103.1.52132 > 10.233.103.49.1337: Flags [S], seq 3759345254, win 29200, options [mss 1460,sackOK,TS val 195801472 ecr 0,nop,wscale 7], length 0

10.103.103.0/24VPN 服务器通过 BGP 通告外部网络 ( )，因此所有工作人员都知道该网络可通过 访问10.13.16.253。当我从外部网络中的主机 ( 10.103.103.1) 到服务的 IP 地址( ) 运行 ping 测试时10.233.10.101，测试通过，VPN 工作正常并且路由表似乎是正确的。

那么，为什么网络“信任”10.13.16.253而不信任10.103.103.1呢？为什么工人对来自的数据包执行 SNAT 和 DNAT，10.13.16.253而不对来自的数据包执行 SNAT 10.103.103.1？我应该添加一些策略来允许此流量吗？

在此先感谢您提供任何线索！

kubernetes calico

1 个回答

  1. Best Answer

    该死！

    pfSense 正在破坏 SYN 数据包的校验和：

    13:53:32.286601 IP (tos 0x0, ttl 62, id 33830, offset 0, flags [DF], proto TCP (6), length 60)
    10.103.103.1.47390 > 10.233.10.101.1337: Flags [S], cksum 0x86e4 (incorrect -> 0x99db), seq 4230752647, win 29200, options [mss 1460,sackOK,TS val 598846881 ecr 0,nop,wscale 7], length 0
        0x0000:  4500 003c 8426 4000 3e06 31e0 0a67 6701  E..<.&@.>.1..gg.
        0x0010:  0ae9 0a65 b91e 0539 fc2c 2987 0000 0000  ...e...9.,).....
        0x0020:  a002 7210 86e4 0000 0204 05b4 0402 080a  ..r.............
        0x0030:  23b1 ada1 0000 0000 0103 0307            #...........

    我已禁用硬件校验和卸载功能，现在一切正常。

    非常感谢大家的时间和关注！

    • 2

相关问题