在具有活动 OpenVPN 客户端的服务器上允许 SSH

odi*_*533 26 ssh openvpn

我有一个运行 CentOS 7 的 VPS,我通过 SSH 连接到它。我想在 VPS 上运行 OpenVPN 客户端,以便通过 VPN 路由互联网流量,但仍允许我通过 SSH 连接到服务器。当我启动 OpenVPN 时,我的 SSH 会话断开,我无法再连接到我的 VPS。如何配置 VPS 以允许在 VPS 的实际 IP (104.167.102.77) 上打开传入的 SSH(端口 22)连接,但仍通过 VPN 路由传出流量(例如来自 VPS 上的 Web 浏览器)?

我使用的 OpenVPN 服务是 PrivateInternetAccess,一个示例 config.ovpn 文件是:

客户
开发屯
原始UDP
远程 nl.privateinternetaccess.com 1194
解决重试无限
没有绑定
持久键
持久化
ca.crt
TLS客户端
远程证书 TLS 服务器
授权用户通行证
comp-lzo
动词 1
重新秒 0
crl-验证crl.pem

VPS的ip地址:

1: lo: mtu 65536 qdisc noqueue state UNKNOWN
    链接/环回 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 范围主机 lo
       valid_lft 永远首选_lft 永远
    inet6 ::1/128 范围主机
       valid_lft 永远首选_lft 永远
2:ens33:mtu 1500 qdisc pfifo_fast 状态 UP qlen 1000
    链接/以太 00:50:56:be:16:f7 brd ff:ff:ff:ff:ff:ff
    inet 104.167.102.77/24 brd 104.167.102.255 范围全球 ens33
       valid_lft 永远首选_lft 永远
    inet6 fe80::250:56ff:febe:16f7/64 范围链接
       valid_lft 永远首选_lft 永远
4:tun0:mtu 1500 qdisc pfifo_fast 状态未知 qlen 100
    链接/无
    inet 10.172.1.6 peer 10.172.1.5/32 范围全局 tun0
       valid_lft 永远首选_lft 永远

VPS的ip路由:

0.0.0.0/1 通过 10.172.1.5 dev tun0
默认通过 104.167.102.1 dev ens33 proto static metric 1024
10.172.1.1 通过 10.172.1.5 dev tun0
10.172.1.5 dev tun0 proto 内核范围链接 src 10.172.1.6
104.167.102.0/24 dev ens33 proto 内核范围链接 src 104.167.102.77
109.201.154.177 通过 104.167.102.1 dev ens33
128.0.0.0/1 通过 10.172.1.5 dev tun0

小智 32

根据@MrK 的回答,我在这里编写了一些简单的代码,以便更快地完成工作,这样您就不必检查接口/IP:

ip rule add from $(ip route get 1 | grep -Po '(?<=src )(\S+)') table 128
ip route add table 128 to $(ip route get 1 | grep -Po '(?<=src )(\S+)')/32 dev $(ip -4 route ls | grep default | grep -Po '(?<=dev )(\S+)')
ip route add table 128 default via $(ip -4 route ls | grep default | grep -Po '(?<=via )(\S+)')
Run Code Online (Sandbox Code Playgroud)

我已经在我的 4 个 VPS 上尝试过这个脚本,它运行良好。


Joh*_*Doe 20

这可能有点晚了,但是......

问题是 OpenVPN 更改了默认网关,除非您在启动 OpenVPN 之前设置了适当的路由,否则会中断您当前的 SSH 连接。

以下内容对我有用。它使用 iptables 和 ip (iproute2)。下面,假设OpenVPN启动前的默认网关接口为“eth0”。这个想法是确保当与 eth0 建立连接时,即使 eth0 不再是默认网关接口,连接的响应数据包也会再次返回 eth0。

您可以对连接标记、防火墙标记和路由表使用相同的编号。我使用不同的数字来使它们之间的差异更加明显。

# set "connection" mark of connection from eth0 when first packet of connection arrives
sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234

# set "firewall" mark for response packets in connection with our connection mark
sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 table 3412

# route packets with our firewall mark using our routing table
sudo ip rule add fwmark 4321 table 3412
Run Code Online (Sandbox Code Playgroud)

===

更新:

以上在 Debian Jessie 上对我来说很好用。但是在较旧的 Wheezy 系统上,我刚刚发现需要在路由表条目中添加“via”:

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 via 12.345.67.89 table 3412
Run Code Online (Sandbox Code Playgroud)

其中“12.345.67.89”一定是原来的非VPN网关。


小智 18

我遇到了与此类似的问题,并且一直在尝试此论坛帖子中描述的修复程序。

这个想法是,当前当您连接到您的公共 IP 地址时,返回的数据包正在通过 VPN 路由。您需要强制通过公共接口路由这些数据包。

这些路由命令有望解决问题:

从 xxxx 表 128 添加的 ip 规则

ip route 将表 128 添加到 yyyy/y dev ethX

ip 路由添加表 128 默认通过 zzzz

其中 xxxx 是您的公共 IP,yyyy/y 应该是您的公共 IP 地址的子网,ethX 应该是您的公共以太网接口,而 zzzz 应该是默认网关。

请注意,这对我不起作用(使用 Debian 和 PrivateInternetAccess),但可能会帮助您。