Ich versuche, einen Remote-VPN-Server einzurichten, um von meinem Heim-PC aus auf das Internet zuzugreifen. Er befindet sich auf einem gemieteten AWS VPS mit Debianund Strongswan. Er soll meinen Datenverkehr über den Tunnel empfangen, ihn an das Internet weiterleiten, die Antworten aus dem Internet empfangen und sie über den Tunnel an mich zurückleiten. Mein PC stellt erfolgreich eine Verbindung zu ihm her, er empfängt meinen Datenverkehr und leitet ihn an das Internet weiter, aber er scheint keine Antworten aus dem Internet zu empfangen, also funktioniert er nicht wie vorgesehen. Iptableszeigt den ausgehenden Datenverkehr vom Tunnel zum Internet, aber null Datenverkehr aus dem 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
tcpdumpzeigt auch den Verkehr, der vom Tunnel zum Internet fließt, aber keinen Verkehr in die Gegenrichtung:
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 enthält
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.confenthält (die meisten auskommentierten Zeilen werden nicht angezeigt)
# /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
Der Server selbst scheint problemlos mit dem Internet zu funktionieren, Pings sowohl über IP-Adressen als auch über Domänennamen sind erfolgreich.
Neben dem Server, von dem ich spreche, habe ich einen weiteren ähnlichen VPN-Server auf einem ähnlichen gemieteten AWS VPS. Er funktioniert gut mit einem anderen meiner Heimcomputer. Und ich kann keinen relevanten Unterschied zwischen den Konfigurationen der beiden Server feststellen.
Ich habe kaum Erfahrung mit Linux-Servern. Was sollte ich sonst noch überprüfen, um die Ursache herauszufinden? Welche zusätzlichen Informationen können Licht in die Sache bringen?
UPD: iptables -t nat -LAntworten
....
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
Ist es richtig?
Antwort1
Es war mein eigener Fehler. Ich war beim Einrichten unvorsichtig iptablesund habe geschrieben, eth0ohne den tatsächlichen Schnittstellennamen zu überprüfen, der ens5auf diesem VPS war. Es ist ein dummer Fehler, der nicht erwähnenswert wäre, aber es besteht die Möglichkeit, dass jemand anderes in diese Falle tappt, sodass die Antwort, die auf diese Situation zutrifft, jemandem helfen könnte.