☰

Docker-Host, der über VPN mit dem Host verbunden ist, kann nicht gepingt werden

tag-icon • tag-icon linux networking openvpn docker centos-7
Docker-Host, der über VPN mit dem Host verbunden ist, kann nicht gepingt werden

Ich habe zwei Hosts: CentOS 7, das ein Docker-Host und OpenVPN-Server ist, und Ubuntu als Client. Ich verwende OpenVPN, um einen Client mit dem Host zu verbinden, aber das Problem ist, dass der VPN-Server keine Antwort zurücksendet, d. h. er sendet keine Pakete zurück. Der Client befindet sich hinter dem NAT. Ich habe die Firewall auf beiden Seiten überprüft – alle Arten von Datenverkehr sind zulässig. Was sollte ich noch überprüfen? MTU ist definitiv nicht die Ursache. Als Router verwenden wir Mikrotik.

Client-Konfiguration:

remote <Server IP>
dev tun
rport 18999
lport 18999
proto udp
ifconfig IP1 IP2
secret /etc/openvpn/static.key 1
persist-tun
persist-key
keepalive 10 60
ping-timer-rem
verb 3
daemon
log-append /var/log/openvpn.log

Konfiguration auf der Serverseite:

ev tun.yasha
proto udp
local <someip>
lport 18999
rport 18999
secret /etc/openvpn/.keys/secret.key 0
ifconfig <IP2> <IP1>
user nobody # On CentOS
group nobody # On CentOS
persist-tun
persist-key
keepalive 10 60
ping-timer-rem
verb 6
daemon
log-append /var/log/openvpn.log

Ausgaben während der Tunnel aktiv ist: Klient: ip r

default via 192.168.88.1 dev wlp3s0 proto dhcp metric 600 
10.8.0.1 dev tun0 proto kernel scope link src 10.8.0.2 
169.254.0.0/16 dev wlp3s0 scope link metric 1000 
192.168.88.0/24 dev wlp3s0 proto kernel scope link src 192.168.88.34 metric 600

IP-Adresse

tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.0.2 peer 10.8.0.1/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::9b45:4bf5:f2d7:5375/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

Server:

ip r

default via 217.12.XXX.X dev eno1 
10.8.0.2 dev tun.yasha proto kernel scope link src 10.8.0.1

ip a (wir haben viele Schnittstellen auf der Maschine, deshalb lasse ich sie weg)

tun.yasha: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun.yasha
       valid_lft forever preferred_lft forever
    inet6 fe80::4815:ef11:3756:faea/64 scope link flags 800 
       valid_lft forever preferred_lft forever

Antwort1

Mit Ihren Konfigurationen haben Sie lediglich eine IP-Adresse für den Tunnel auf dem Client konfiguriert.

Da es sich bei der Adresse um eine /32-Punkt-zu-Punkt-Adresse handelt, wird möglicherweise standardmäßig keine Route hinzugefügt. (Das kann plattformabhängig sein.)

Wenn Sie lediglich über mit dem Server kommunizieren möchten, IP1dies aber nicht sofort funktioniert, route IP1sollte das Hinzufügen ausreichen.

Wenn Sie beispielsweise möchten, dass der gesamte Datenverkehr des Client-Hosts in den Tunnel geleitet wird, sollten Sie redirect-gatewaystattdessen diese Option verwenden.

Für Letzteres müssen Sie sicherstellen, dass der Client-Host DNS-Server verwendet, die über den Tunnel erreichbar sind (siehe dhcp-option DNS). Außerdem muss auf dem Server die IP-Weiterleitung zwischen dem Tunnel und der Netzwerkkarte aktiviert sein.

verwandte Informationen