【问题标题】:GCE + OpenVPN + subnetwork does not work the routingGCE + OpenVPN + 子网不起作用的路由
【发布时间】:2017-01-03 06:39:54
【问题描述】:

我想在谷歌计算平台上创建一个专用网络,我只能使用 vpn 进入。 所以,我在 GCE 中创建了一台机器并安装了 openvpn。这台机器有一个静态 IP、开放的 ssh 端口和来自 GCE 的默认网络配置。 然后,我在同一网络中创建了第二台机器(称为 MachineA),但没有外部 IP。 然后我创建路由规则,以便将流量从 vpn 机器重定向到另一个内部实例。

我可以从我的机器连接到 vpn。 我可以ping到vpn机器。 我可以 ping 通到 MachineA。 我可以通过 ssh 连接到 vpn 机器。 我可以通过 ssh 连接到 MachineA。

但是... 当我连接到 ssh vpn 机器并运行 gsutil 时,它可以工作,也可以 ping 到 8.8.8.8 当我连接到 ssh MachineA 并运行 gstult 或 ping 8.8.8.8 时不起作用。

知道我做错了什么吗?

一些信息

来自 VPN 机器

xxx@dev-vpn:~$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.240.10.1     0.0.0.0         UG        0 0          0 eth0
10.16.0.0       10.16.0.2       255.255.255.0   UG        0 0          0 tun0
10.16.0.2       0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.240.10.1     0.0.0.0         255.255.255.255 UH        0 0          0 eth0

xxx@dev-vpn:~$ traceroute 10.240.10.3
traceroute to 10.240.10.3 (10.240.10.3), 30 hops max, 60 byte packets
 1  * * instance-1.c.project.internal (10.240.10.3)  1.188 ms

来自 MachineA

traceroute to 10.240.10.2 (10.240.10.2), 30 hops max, 60 byte packets
 1  * * *
 2  * * dev-vpn.c.project.internal (10.240.10.2)  0.899 ms

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.240.10.1     0.0.0.0         UG        0 0          0 eth0
10.240.10.1     0.0.0.0         255.255.255.255 UH        0 0          0 eth0

在谷歌网络中我添加了这个规则 vpn-routing 10.16.0.0/24 1001 无 dev-vpn (Zone us-central1-a)

【问题讨论】:

  • “然后我创建了路由规则,以便将流量从 vpn 机器重定向到另一个内部实例”,你是怎么做到的? “我添加这条规则 vpn-routing 10.16.0.0/24 1001 None dev-vpn”,对我来说看起来毫无意义,你想用它来实现什么?您的失败是关于从 machineA 访问外部 IP,它与 VPN 通信无关。
  • 嗨,我的问题是命令行工具gsutil在MachineA中不起作用,如果我删除规则vpn-routing 10.16.0.0/24,命令开始工作,但我没有能够从我的本地机器 ping/ssh MachineA。
  • 我猜gsutil访问的地址恰好落在10.16.0.0/24空间?你能把你的 ip 空间更改为另一个私有 IP 范围,例如 192.168.0.0/16?

标签: networking google-compute-engine google-cloud-platform


【解决方案1】:

我有一个可以做到这一点的工作系统。我所做的创新是添加别名 IP 范围并让 OpenVPN 服务器使用该 Google IP 范围。

因此,对于具有外部 IP 地址并将在 GCE 上运行 OpenVPN 服务器的路由器实例,您需要创建仅具有一个接口和较小 IP 别名范围的实例。这将允许 IP 转发从主接口到小别名范围。假设您在默认网络 10.156.0.10/20 上,并且添加了 10.156.1.0/28 的别名范围,然后在 OpenVPN 服务器配置中添加为服务器行:服务器 10.156.1.1。

所以 OpenVPN(服务器端)的 tun0 接口将出现在 10.156.1.1 上,隧道端点出现在 10.156.1.2 上。

您必须将路由推送到 OpenVPN 客户端(因此在服务器配置中推送 10.156.0.0/20)。您还需要在服务器的 ccd/client 中使用 iroute 语句。

以下是 OpenVPN 服务器配置文件的摘录:

server 10.156.1.0 255.255.255.240

push "route 10.156.0.0 255.255.240.0"
push "route 10.164.0.0 255.255.240.0"
push "route 10.132.0.0 255.255.240.0"
route 192.168.127.0 255.255.255.0

如果您的站点网络是 192.168.127.0/24,并且您使用 3 个 Google 网络。 ccd/client 文件有这个

route 192.168.127.0 255.255.255.0
iroute 192.168.127.0 255.255.255.0

如果您有其他路线,您可能需要添加其他路线。 (OpenVPN 手册中有一节是关于 ccd/ 和 iroute 的。)

回到 Google 云,您需要通过 10.156.0.10 上的 OpenVPN 网关添加一条 Google 路由才能返回 192.168.127.0/24。

你应该做很多防火墙来确保你的主机安全,但你至少必须为 OpenVPN 打开 1194 端口。

在您的站点上,如果您想访问 Google Cloud 专用网络,则需要使用 Quagga 的 RIPd。这是一个相对简单的配置:

router rip
 network eth0
 passive-interface tun0
 no default-information originate
 redistribute kernel route-map GMAP
 access-list GCE permit 10.156.0.0/20
 access-list GCE permit 10.164.0.0/20
 access-list GCE permit 10.132.0.0/20
 access-list GCE deny any
 route-map GMAP permit 10
 match ip address GCE

这是 OpenVPN client 网关的 RIPd 配置,它是一个路由器。此配置传播三个 Google Cloud 网络 10.{156,164,132}.0.0/20 的所有路由。

您站点网络中其他主机上的 RIPd 配置不需要任何特殊配置,只需将“路由器 rip”和“网络 eth0”命名为您的主机的网络接口并启动 RIPd。 (VPN 客户端网关上的配置应该比这更容易,但我发现“没有默认信息来源”对我不起作用,所以我只好传播 Google 路由。)

【讨论】:

  • 我应该说最初我尝试使用自己的网络定义而不是使用默认值。我得到了一些工作,但路由变得困难。默认网络包含您需要的所有路由,因此请尝试使用这些路由。
猜你喜欢
  • 2012-06-24
  • 2017-12-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-02-24
  • 2019-02-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多