主页 / server / 问题 / 1142982
Accepted
m. vokhm
Asked: 2023-09-04 16:21:09 +0800 CST

Debian + Strongswan：不将流量从互联网传递到隧道

  • 772

我正在尝试设置远程 VPN 服务器以从我的家用电脑访问互联网。它位于租用的 AWS VPS 上，带有Debian和Strongswan. 它的目的是通过隧道接收我的流量，将其转发到互联网，接收来自互联网的响应，然后通过隧道将它们转发回我。我的电脑成功连接到它，它接收我的流量并将其转发到互联网，但它似乎没有收到来自互联网的响应，因此它无法按预期工作。Iptables显示从隧道到 Internet 的传出流量，但来自 Internet 的流量为零：

root@internal_aws_ip:/home/admin# iptables -L -nv
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
14667 2284K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  595 56329 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    3   168 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
   13  7232 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:500
   35 19992 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:4500
   14  4592 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 8697  522K ACCEPT     all  --  *      *       10.10.10.0/24        0.0.0.0/0            policy match dir in pol ipsec proto 50
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            10.10.10.0/24        policy match dir out pol ipsec proto 50
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 8639 packets, 3433K bytes)
 pkts bytes target     prot opt in     out     source               destination

tcpdump还显示从隧道到互联网的流量，但没有反向流量：

root@internal_aws_ip:/home/admin# tcpdump port not ssh
....
06:46:19.605227 IP #HOME_PC#.ipsec-nat-t > #AWS_VPS#.eu-central-1.compute.internal.ipsec-nat-t: UDP-encap: ESP(spi=0xcbf6e396,seq=0x43), length 100
06:46:19.605227 IP ip-10-10-10-1.eu-central-1.compute.internal.50576 > dns.google.domain: 38403+ A? dns.msftncsi.com. (34)
06:46:19.605284 IP ip-10-10-10-1.eu-central-1.compute.internal.50576 > dns.google.domain: 38403+ A? dns.msftncsi.com. (34)
06:46:20.119576 IP #HOME_PC#.ipsec-nat-t > #AWS_VPS#.eu-central-1.compute.internal.ipsec-nat-t: UDP-encap: ESP(spi=0xcbf6e396,seq=0x44), length 100
06:46:20.119576 IP ip-10-10-10-1.eu-central-1.compute.internal.61302 > dns.google.domain: 42466+ A? dns.msftncsi.com. (34)
06:46:20.119634 IP ip-10-10-10-1.eu-central-1.compute.internal.61302 > dns.google.domain: 42466+ A? dns.msftncsi.com. (34)
06:46:20.122526 IP #HOME_PC#.ipsec-nat-t > #AWS_VPS#.eu-central-1.compute.internal.ipsec-nat-t: UDP-encap: ESP(spi=0xcbf6e396,seq=0x45), length 100
06:46:20.122526 IP ip-10-10-10-1.eu-central-1.compute.internal.53026 > 82.221.107.34.bc.googleusercontent.com.http: Flags [S], seq 2356796043, win 65280, options [mss 1360,nop,wscale 8,nop,nop,sackOK], length 0
06:46:20.122580 IP ip-10-10-10-1.eu-central-1.compute.internal.53026 > 82.221.107.34.bc.googleusercontent.com.http: Flags [S], seq 2356796043, win 65280, options [mss 1320,nop,wscale 8,nop,nop,sackOK], length 0
06:46:20.122773 IP #HOME_PC#.ipsec-nat-t > #AWS_VPS#.eu-central-1.compute.internal.ipsec-nat-t: UDP-encap: ESP(spi=0xcbf6e396,seq=0x46), length 100
06:46:20.122773 IP ip-10-10-10-1.eu-central-1.compute.internal.53027 > 82.221.107.34.bc.googleusercontent.com.http: Flags [S], seq 2988801698, win 65280, options [mss 1360,nop,wscale 8,nop,nop,sackOK], length 0
06:46:20.122791 IP ip-10-10-10-1.eu-central-1.compute.internal.53027 > 82.221.107.34.bc.googleusercontent.com.http: Flags [S], seq 2988801698, win 65280, options [mss 1320,nop,wscale 8,nop,nop,sackOK], length 0
....

IPsec.conf 包含

config setup
        uniqueids=never
        charondebug="ike 2, knl 2, cfg 3, net 2, esp 2, dmn 2,  mgr 2"

conn %default
        keyexchange=ikev2
        ike=aes128gcm16-sha2_256-prfsha256-ecp256,aes256-sha2_256-prfsha256-modp2048!
        esp=aes128gcm16-sha2_256-ecp256,chacha20poly1305-sha512,aes256gcm16-ecp384,aes256-sha256,aes256-sha1!
        fragmentation=yes
        rekey=no
        compress=yes
        dpdaction=clear
        left=%any
        leftauth=pubkey
        leftsourceip=#SERVER_IP#
        leftid=#SERVER_IP#
        leftcert=debian.pem
        leftsendcert=always
        leftsubnet=0.0.0.0/0
        right=%any
        rightauth=pubkey
        rightsourceip=10.10.10.0/24
        rightdns=8.8.8.8,8.8.4.4

conn ikev2-pubkey
        auto=add

sysctl.conf包含（大多数注释掉的行未显示）

# /etc/sysctl.conf - Configuration file for setting system variables

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Do not accept ICMP redirects (prevent MITM attacks)
net.ipv4.conf.all.accept_redirects = 0

# Do not send ICMP redirects (we are not a router)
net.ipv4.conf.all.send_redirects = 0

net.ipv4.ip_no_pmtu_disc = 1

服务器本身似乎可以与 Internet 正常工作，通过 IP 地址和域名进行 ping 操作均成功。

除了我正在谈论的服务器之外，我在类似的租赁 AWS VPS 上还有另一个类似的 VPN 服务器。它与我的另一台家用电脑配合得很好。我找不到两台服务器配置之间的任何相关差异。

我对 Linux 服务器的经验很少。我还应该检查什么来找出原因？哪些其他信息可以阐明情况？

UPD：iptables -t nat -L回复

.... 
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  ip-10-10-10-0.eu-central-1.compute.internal/24  anywhere             policy match dir out pol ipsec  
MASQUERADE  all  --  ip-10-10-10-0.eu-central-1.compute.internal/24  anywhere

这是对的吗？

debian

1 个回答

  1. Best Answer

    这是我自己的错。我在设置时很粗心，没有检查该 VPS 上的实际接口名称就iptables写了。这是一个不值得一提的愚蠢错误，但其他人可能会陷入这个陷阱，因此应用这种情况的答案可能会对某人有所帮助。eth0ens5

    • 0

相关问题