与第三方 Cisco 设备的 VPN 集成

与第三方 Cisco 设备的 VPN 集成

如果这个设置不合理,请见谅。对我来说,这不合理,但任何帮助都将不胜感激。

背景

我有一家支付提供商,他们要求我提供 2 个 IP 地址,并建立一个 VPN(这是 M-Pesa Tanzania)。

我拥有一堆云托管的 Ubuntu 服务器可供使用。

我认为他们想要的是:

私对私隧道

这就是我所拥有的:

公私混乱

我也尝试过使用子网(来自云提供商):

公有子网

并且我尝试将我方目标服务器作为我的 VPN 设备的客户端:

隐藏于 VPN

最终目标是他们可以查询我将放在 94.130.xx.xx 上的 HTTPS 端点(是的,据我所知,这使得整个 VPN 变得毫无意义)。

我从 M-Pesa 那里得到的所有信息就是每天尝试一两次,telnet 94.130.xx.xx 443然后他们会告诉我是否连接成功。他们不会给我任何日志、配置建议或任何其他帮助。

经过几天的搜索和实验,没有取得任何成功。

我需要的

41.217.xx.xx 的服务器应该能够通过其网关 197.250.xx.xx 呼叫 94.130.xx.xx

他们的设置要求我这边有一个 VPN 设备,该设备的 IP 与我的服务器不同。该设备的 IP 设置为 159.69.xx.xx

我并不关心真实的网络最终会怎样,只要 M-Pesa 能够达到他们的预期。

我尝试过

我在 159.69.xx.xx 上安装了 strong-swan,配置/etc/ipsec.config如下:

conn mpesa
    type=tunnel
    left=159.69.xx.xx
    leftid=159.96.xx.xx
    leftsubnet=94.130.xx.xx/32
    right=197.250.xx.xx
    rightid=197.250.xx.xx
    rightsubnet=41.217.xx.xx/32
    ikelifetime=8h
    lifetime=8h
    keyexchange=ikev2
    authby=secret
    closeaction=restart
    dpdaction=restart
    dpddelay=300s
    auto=start

我已经设置了 PSK,并且可以建立连接:

ipsec route mpesa
ipsec statusall

返回

Status of IKE charon daemon (strongSwan 5.9.5, Linux 5.15.0-41-generic, x86_64):
  uptime: 37 seconds, since Jul 26 12:42:22 2022
  malloc: sbrk 3174400, mmap 0, used 1312768, free 1861632
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon aesni aes rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm drbg attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
  159.69.xx.xx
  2a01:4f8:c0c:95a7::1
  172.17.xx.xx
Connections:
       mpesa:  159.69.xx.xx...197.250.xx.xx  IKEv2, dpddelay=300s
       mpesa:   local:  [159.96.xx.xx] uses pre-shared key authentication
       mpesa:   remote: [197.250.xx.xx] uses pre-shared key authentication
       mpesa:   child:  dynamic === 41.217.xx.xx/32 TUNNEL, dpdaction=restart
Routed Connections:
       mpesa{2}:  ROUTED, TUNNEL, reqid 1
       mpesa{2}:   159.69.xx.xx/32 === 41.217.xx.xx/32
Security Associations (1 up, 0 connecting):
       mpesa[1]: ESTABLISHED 37 seconds ago, 159.69.xx.xx[159.96.xx.xx]...197.250.xx.xx[197.250.xx.xx]
       mpesa[1]: IKEv2 SPIs: ace5850eaaa5eee5_i* 662ecd6b9b800036_r, pre-shared key reauthentication in 7 hours
       mpesa[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048

在此基础上,我尝试了iptables我能想到的这种隧道的每一种变体,并且尝试了不使用以下方法:

iptables --append INPUT -s 197.250.xx.xx -j ACCEPT
iptables --append INPUT -d 197.250.xx.xx -j ACCEPT
iptables --table mangle --append FORWARD -o Tunnel1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

ip tunnel add Tunnel1 local 159.69.xx.xx remote 197.250.xx.xx mode vti key 42

ip addr add 94.130.xx.xx/32 remote 41.217.xx.xx/32 dev Tunnel1
ip addr add 41.217.xx.xx/32 remote 94.130.xx.xx/32 dev Tunnel1
ip link set Tunnel1 up mtu 1419

sysctl -w net.ipv4.conf.Tunnel1.disable_policy=1
iptables --table mangle --append FORWARD -m policy --pol ipsec --dir in -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
iptables --table mangle --append FORWARD -m policy --pol ipsec --dir out -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360

我还尝试在 94.130.108.249 上设置另一个 VPN,并将其隧道连接到 159.69.xx.xx 上的“VPN”;我还尝试将 VPN 连接回环到自身,以创建 159.69.xx.126看起来像94.139.108.249——但我很确定我没有正确操作。

答案1

评论太长了,但请向您的提供商询问详细信息。在大多数情况下,只需一个简单的站点到站点 VPN 即可。您现在想得太多了。

最终目标是他们可以查询我将放在 94.130.108.249 上的 HTTPS 端点(是的,据我所知,这使得整个 VPN 变得毫无意义)。

这并非毫无意义,因为它可以双重保护您的网络服务器,您有 HTTPS 来保护流量,您有隧道来保护连接到该服务器的人员的身份。

您的 VPN 设备应连接到提供商 VPN 设备,并在配置中公开您希望他们访问的服务器子网。您的提供商必须公开与您相同的设置(右/左)

之后应该配置路由,远程端点将知道要与 91.* 通信,它需要在 VPN 内部通信。这意味着您的端点直接与 91.* 服务器对话。

答案2

以防万一有人遇到这种情况......

我认为我的问题的核心是云托管机器上的网络已经虚拟化,所以我有两个不同的ip tunnel实例,它们无法互相交谈而不会引起自我反馈。

我从来没有研究过如何使用 Linux + StrongSwan 来实现这一点。

作为一名开发人员而非网络技术人员,我决定编写一个虚拟化 VPN 软件。这可能是我做过的最愚蠢的事情,但我找不到其他方法。

https://github.com/ieb/VirtualVpn

相关内容