问题标签 [google-cloud-vpn]

请多多包涵，因为我的背景是开发而不是系统管理员。网络是我边走边学的东西，因此我在这里写东西:)

几个月前，我开始设计我们云的网络结构。在这里进行了几次交流后，我决定拥有一个项目，该项目将托管一个 VPN 隧道到本地资源和一些其他项目，一旦它们从本地服务器移动，它们将托管我们的产品。

一切都很好，我设法进行了设置。

现在，其中一个项目专门用于“存储”：对我们来说，这意味着数据库、用于访问 statis 数据的存储桶等。

我创建了第一个 mySQL 数据库（第二代）来开始测试，并注意到从内部 IP 访问 SQL 数据库的唯一选项是使用“父项目”子网。

我意识到 SQL 引擎为此专门创建了一个子网。它也写在文档中，我很傻。没问题，我把它拆了，开启私有服务连接，在VPC管理中创建一个分配的IP范围，设置为导出路由。

然后我回到 SQL 引擎创建了一个新数据库。正如预期的那样，新的 IP 已分配给先前设置的分配 IP 范围。

现在，我希望每个对等网络也能够看到 SQL 子网，但显然不是。再一次，RDFM 你这傻鹅。它也写在那里。

我通过 GCP 激活了青铜支持订阅以获得一些指导，但我得到的是重复的“在两个项目之间创建 vpn 隧道”，这让我有点失望，因为 Peered VPC 的概念非常好。

但无论如何，让我们这样做吧。

我在项目中创建了一个指向网关的隧道，该网关将具有 K8s 集群，反之亦然。仪表板告诉我隧道已建立，但显然bgp设置存在问题，因为它们一直挂在两侧的“等待对等点”上，因为永远。

在这一点上，我正在寻找与 BGP 相关的任何东西，但我能找到的只是它在理论上是如何工作的、它的用途、保留的 ASM 编号等。

我真的需要有人指出显而易见的事情并告诉我我在这里搞砸了什么，所以：

这是托管数据库的项目上的 VPN 隧道：

这是将要部署产品的项目上的 VPN 隧道，需要访问数据库。

任何帮助是极大的赞赏！

我一直在 GCP 中遇到问题。

我有两个 vpn，每个都有两个隧道。

VPN 1 位于美国东部地区。VPN 2 位于 us-central 区域。

问题：当我尝试使用在 us-central 中创建的 vm 实例连接到我的数据库时，我只能通过 VPN 2 连接。当我在这个 VM 上使用 VPN 1 时，我无法连接到我的数据库。

当我的虚拟机是 us-east 时也会发生同样的情况，我只能通过 VPN 1 连接到我的数据库。

这是一个问题吗？还是只是巧合？

编辑：

我想我发现了问题所在。vpn 1 和 vpn 2 配置了不同的子网。

VPN 1： 10.142.0.0/20

VPN 2： 10.128.0.0/20

us-central 中的所有 VM 为 10.128.0.0/20 us-east 中的所有 VM 为 10.142.0.0/20

看图片

根据谷歌文档，我们已经使用支持的阶段 1 阶段 2 密码配置了 cisco ASA FTD vpn 隧道，但未建立连接。状态是“初始握手”

在日志中，我们可以看到来自 cisco end 的阶段 1 DH 组不匹配。

我们用来配置隧道的密码 - > https://cloud.google.com/vpn/docs/concepts/supported-ike-ciphers#ikev1-ciphers

当我们选择 IKEv1 时，Google 承诺他们使用上述密码，但为什么它没有连接以及为什么我们在日志中收到 DH 组不匹配错误。所有必要的 VPN 端口都从两端打开。

任何帮助，将不胜感激 。

在 Google Cloud Platform 上搜索日志查看器并选择 Metric type oflogging.googleapis.com/user/vpn sessions时，显示：

2020-02-17 15:51:28.909 IST Stackdriver Logging API UpdateLogMetric vpn-sessions xyz@gmail.com INVALID_ARGUMENT

谁能告诉我什么是INVALID_ARGUMENT以及它与这个 VPN 会话有什么关系？

我有一个带有 EC2 的 AWS 帐户，我正在尝试连接到 Google Cloud Platform 内的 Cloud SQL Server (MySQL 5.6)。

我已经成功地在 AWS 和 GCP 之间建立了 VPN，并且可以通过 nc 在 AWS 上的 ec2 和 GCP 上的 vm 之间回显一条消息。

由于 GCP 管理的数据库未放置在我选择的 VPC 中，因此我按照本指南为数据库提供了一个私有 IP，然后将其与我的谷歌 VPC 对等。我通过使用数据库的私有 IP 从 GCP 中的 VM 通过 pymsql 访问数据库来测试这项工作。

但是我的问题来自以同样的方式将 AWS 内部的 EC2 连接到 Cloud SQL DB，我已按照本指南允许从外部源使用 DB 的私有 IP，但我似乎不知道如何设置使用 AWS 路由路由到数据库所在的对等网络。

在 GCP 混合连接上，我最终需要专门针对广告 IP 范围和本地子网编辑 VPN 隧道。当这种必要性出现时，是否可以更改隧道配置？到目前为止，我无法做到这一点，需要重新创建不希望的隧道......

I have an issue with Google Cloud VPN and tunneling to a peer VPN. The tunnel is up and running but I cannot connect to any points on the peer network from my GCE VM.

My setup looks like the following:

• A custom VPC network with one interal IP-range. Let's call it custom-net
• A classic VPN Gateway with a IPSec tunnel to a peer VPN. The tunnel has status Established. The VPN Gateway has a Reserved IP address to it. The VPN Gateways VPC network is custom-net.
• Three routes on custom-net:
  • Local route to the only subnet, prio 1000
  • To default internet gateway, prio 900
  • To the gateway tunnel, prio 1000
• A fresh Linux VM in GCE. Let's call it vm1. It has one network interface on custom-neton its only sub network.
• Two firewall rules in GC that allow everything Ingress and Egress.

I can connect to vm1 with ssh and access the internet from it, but I cannot access any points in the peer VPN despite the tunnel being status Established. The IP-range on custom-net does not interfere with any ranges on the peer network.

What could be the issue here? I'm novice in network setups. Could it be something missing in the routing, or do I have to do some configuration in vm1 to get this to roll?

Any help appreciated!

我有这个问题：我需要通过 VPN 从 Cloud Function 请求一些第 3 方 HTTP 资源。对方只能路由一个 IP 作为请求的来源，但附加到 Cloud Function 的 VPC 连接器是 /28 CIDR，所以我不知道该范围的哪个 IP 将用来告诉对方将其添加到 VPN 的路由中交通。

也许我可以使用一些内部 NAT / 代理来转发该流量，但我想用一些本机或更清洁的解决方案来解决。

我会感谢你的帮助。

我正在尝试在我的 GCP 的默认网络中创建一个子网系统。

我创建了一个带有子网 CIDR (10.142.xx/28) 的 vpc 网络。此子网的 CIDR 在该区域的地址范围内。即10.142.0.2 to 10.142.15.253对于那个地区。

但是，当我尝试通过默认网络上的另一台机器连接到机器时。我无法连接到子网上的机器。

我不确定这里发生了什么？我认为默认网络上的资源始终可以连接到该区域的子网。

我有一个通过 GCPCompute Engine在组实例上运行的应用程序。

我在全国不同的专用网络上有多台计算机，我需要它们通过VPC. 他们已经可以通过公共 IP 进行通信，但这不是目标。

我查看了VPNGCP 提供的连接选项；我要么不完全理解它们，要么这不是我想要的。