VPN 客户端连接后无法 ssh 进入 EC2 实例

VPN 客户端连接后无法 ssh 进入 EC2 实例

我在 EC2 实例中运行 Ubuntu 18.04.4 LTS 服务器。我在此服务器中安装了 expressvpn 客户端(我经常在家庭服务器中使用它,没有任何问题)。

一旦服务器上启动 VPN 连接,我就无法再从笔记本电脑连接到服务器。我服务器上还运行着一个 Apache 服务器,目前也无法访问。

有没有办法解决这个问题?我知道这可能是由于 AWS 中的配置方式奇怪而导致的。在这种情况下,有没有办法将所有到端口 22 的流量强制到特定的非 VPN 接口(如 eth0)?

的输出ip ruleiptables -nvLip route

连接 VPN 之前

Tue Apr 21 21:51:01 UTC 2020
0:  from all lookup local
32766:  from all lookup main
32767:  from all lookup default
---------
Chain INPUT (policy ACCEPT 7536 packets, 1858K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 7340 packets, 2732K bytes)
 pkts bytes target     prot opt in     out     source               destination
---------
default via 172.31.32.1 dev eth0 proto dhcp src 172.31.35.37 metric 100
172.31.32.0/20 dev eth0 proto kernel scope link src 172.31.35.37
172.31.32.1 dev eth0 proto dhcp scope link src 172.31.35.37 metric 100

连接到 VPN 后

Tue Apr 21 21:53:01 UTC 2020
0:  from all lookup local
32766:  from all lookup main
32767:  from all lookup default
---------
Chain INPUT (policy ACCEPT 8168 packets, 2072K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 7954 packets, 2896K bytes)
 pkts bytes target     prot opt in     out     source               destination
---------
0.0.0.0/1 via 10.150.0.21 dev tun0
default via 172.31.32.1 dev eth0 proto dhcp src 172.31.35.37 metric 100
10.0.0.0/8 via 172.31.32.1 dev eth0
10.150.0.1 via 10.150.0.21 dev tun0
10.150.0.21 dev tun0 proto kernel scope link src 10.150.0.22
43.241.61.245 via 172.31.32.1 dev eth0
128.0.0.0/1 via 10.150.0.21 dev tun0
172.16.0.0/12 via 172.31.32.1 dev eth0
172.31.32.0/20 dev eth0 proto kernel scope link src 172.31.35.37
172.31.32.1 dev eth0 proto dhcp scope link src 172.31.35.37 metric 100
192.168.0.0/16 via 172.31.32.1 dev eth0

答案1

假设侦听特定端口的服务使用原始目标端口作为答复源端口(或甚至任何非随机特定端口)进行回复,则可以制定如下 IP 规则:

ip rule add iif lo ipproto tcp sport 22 table 123

并在表中具有到 LAN(网关)的直接路由和默认路由:

ip route add 172.31.32.1 dev eth0 table 123 / ip route add 172.31.32.0/20 dev eth0 table 123
ip route add default via 172.31.32.1 dev eth0 table 123

或者,如果您可以并且愿意,您可以避免在主表中使用通向隧道的“事实上的默认路由”(例如,redirect-gateway ...在 openvpn 的情况下,通过删除/忽略)并手动将一个路由(例如,使用up脚本指令)添加到新表中,然后让上述 ip 规则查找主表,但使用优先级低于它的另一条规则(但高于 32766)查找新路由。这样,当 LAN 子网由于 DHCP 而发生变化时,您无需更改配置(网关对 tun 路由来说无关紧要/不是必需的)。

答案2

我无法告诉你如何配置 expressvpn 以使问题消失,但问题是

0.0.0.0/1 via 10.150.0.21 dev tun0
128.0.0.0/1 via 10.150.0.21 dev tun0

这是通过 VPN 的事实上的默认路由。

问题是:应通过 VPN 传输哪些内容?哪些源地址可以通过 VPN 传输?

例如,如果 VPN 仅用于 10.150.0.0/24,那么您就需要路由表中的这样的条目。

“最坏”的情况是所有源地址都是可能的,并且您希望按照请求传入的方式进行响应。这是一个明显的意图,但不幸的是,没有一个开关可以打开它。您需要高级路由,即您必须为两个接口创建(通过您自己的脚本或新版本的 SystemD)单独的路由表并安装策略路由(ip rule)以选择适当的路由表;在这种情况下,基于联系系统的 IP 地址(VPN 地址或公共地址)。

相关内容