☰

无法连接到 VPN 网络内的成员服务器或反之亦然，但是为什么呢？

tag-icon • tag-icon linux iptables routing openvpn amazon-vpc
无法连接到 VPN 网络内的成员服务器或反之亦然，但是为什么呢？

我已经在 AWS 中创建了一个测试 VPC，用于 OpenVPN 概念验证。

在这个 VPC 中，我从 AWS Marketplace 创建了一个 Linux 成员服务器和一个 OpenVPN 服务器 AMI，并进行了安装和配置。

作为客户端，我能够ssh使用它的 3 个 IP 中的每一个来连接到 VPN 网络并进入 OpenVPN 服务器，但问题是我无法ssh进入 VPC 主子网中的成员服务器。

OpenVPN 服务器与成员服务器之间网络已完全建立。

详情如下：

VPC CIDR: 172.16.0.0/16
VPC Main Subnet CIDR: 172.16.200.0/24 
VPN CIDR: 172.16.201.0/24

OVPN server: 
Main Subnet interface: 172.16.200.66
VPN Server interface: 172.16.201.1
VPN Client interface: 172.16.201.129

Member server:
Main Subnet interface: 172.16.200.71

My Client IP: 172.16.201.131-134 (disconnected a few times)

我已经像这样配置了 OpenVPN 服务器： 在此处输入图片描述 和： 在此处输入图片描述

此外，我尝试过使用 NAT，但是没有效果。

当我tcpdump尝试ssh从客户端计算机运行 OVPN 服务器并连接到成员服务器时：

openvpnas@openvpnas2:~$ sudo tcpdump -i as0t1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on as0t1, link-type RAW (Raw IP), capture size 262144 bytes
11:21:52.668974 IP 172.16.201.131.59009 > 172.16.200.71.ssh: Flags [SEW], seq 2266158529, win 65535, options [mss 1252,nop,wscale 5,nop,nop,TS val 758529356 ecr 0,sackOK,eol], length 0
11:21:53.681875 IP 172.16.201.131.59009 > 172.16.200.71.ssh: Flags [S], seq 2266158529, win 65535, options [mss 1252,nop,wscale 5,nop,nop,TS val 758530357 ecr 0,sackOK,eol], length 0

我可以看到 OVPN 服务器正在尝试将数据包转发到成员服务器，但是在tcpdump成员服务器的接口上运行时，我发现没有数据包到达。

OVPN 服务器上的路由：

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.200.1    0.0.0.0         UG    0      0        0 eth0
172.16.200.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.16.201.0    0.0.0.0         255.255.255.128 U     0      0        0 as0t0
172.16.201.128  0.0.0.0         255.255.255.128 U     0      0        0 as0t1

成员服务器上的路由：

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.200.1    0.0.0.0         UG    0      0        0 eth0
172.16.200.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.16.201.0    172.16.200.66   255.255.255.0   UG    0      0        0 eth0

客户端（我的笔记本电脑）上的路由，其中​​一些是我手动添加的：

netstat -nr | grep tun
172.16.200/24      172.16.201.134     UGSc            4        4   utun2
172.16.201/24      172.16.200.66      UGSc            1        2   utun2
172.16.201.134     172.16.201.134     UH              3        4   utun2

OVPN 服务器上的网络接口：

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:fb:99:4a:67:04 brd ff:ff:ff:ff:ff:ff
    inet 172.16.200.66/24 brd 172.16.200.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::fb:99ff:fe4a:6704/64 scope link
       valid_lft forever preferred_lft forever
3: pr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 36:ce:f1:ac:59:42 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::34ce:f1ff:feac:5942/64 scope link
       valid_lft forever preferred_lft forever
21: as0t0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 200
    link/none
    inet 172.16.201.1/25 brd 172.16.201.127 scope global as0t0
       valid_lft forever preferred_lft forever
22: as0t1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 200
    link/none
    inet 172.16.201.129/25 brd 172.16.201.255 scope global as0t1
       valid_lft forever preferred_lft forever

成员服务器上的网络接口：

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:c5:62:3b:ef:02 brd ff:ff:ff:ff:ff:ff
    inet 172.16.200.71/24 brd 172.16.200.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::c5:62ff:fe3b:ef02/64 scope link
       valid_lft forever preferred_lft forever

其他几点：

ping从我的客户端到成员服务器：

$ ping 172.16.200.71
PING 172.16.200.71 (172.16.200.71): 56 data bytes
Request timeout for icmp_seq 0

ping从我的客户端到 OVPN 服务器（使用 VPC 主子网）：

$ ping 172.16.200.66
PING 172.16.200.66 (172.16.200.66): 56 data bytes
64 bytes from 172.16.200.66: icmp_seq=0 ttl=64 time=87.657 ms

ping从我的客户端到 OVPN vpn ip 也可以正常工作。

此VPC在AWS中的路由表： 在此处输入图片描述

这些是我的问题：

  1. 我是否应该在 VPC 中创建一个“172.16.201.0”（vpn 子网）子网？（我已经这样做了，但是并没有解决问题……这只是我尝试过的方法之一）。

  2. 好像我遗漏了一些东西，也许是在 AWS 的配置中，您能尝试找出我的问题吗？

答案1

我能想到 3 件事你可以看看

  1. 目前，172.16.0.0/16 CIDR 范围内的任何内容都将通过本地路由进行路由，其他所有内容 0.0.0.0/0 都将通过互联网网关发送。因为您的 VPN 子网属于 172.16.0.0/16 范围，所以这可能会导致问题。可能是：

a. 为你的 VPN 子网选择不同的地址范围

b. 确保路由表中有一条路由可通过 VPN 设备将流量路由到此子网

  1. 您是否查看过链接到 EC2 实例的安全组？它们是否允许您要流向这些 EC2 实例的正确流量（在本例中为 SSH）
  2. 您是否查看过链接到您的 VPC 及其子网的网络 ACL，它们是否允许正确的入站和出站流量？

相关内容