ubuntuusers.de

Hallo.

Gegeben ist folgendes:

Eim VPN Server mit Standort 1 steht im Rechenzentrum, mit der public IP XXX.XXX.XXX.44 auf br0. Des weiteren hängt er an einem internen Verwaltungsnetz mit der 192.168.190.200 auf eth1. Im eigenen VPN Netz sitzt er auf 192.168.80.1 auf der tun0.

Es gibt folgende Routen:

default via XXX.XXX.XXX.XXX dev br0 onlink 
XXX.XXX.XXX.XX/XX dev br0 proto kernel scope link src XXX.XXX.XXX.44 
192.168.80.0/24 dev tun0 proto kernel scope link src 192.168.80.1 
192.168.150.0/24 via 192.168.80.2 dev tun0 src 192.168.80.1 
192.168.190.0/24 dev eth1 scope link 
192.168.190.0/24 dev eth1 proto kernel scope link src 192.168.190.200 

Jetzt gibt es an Standort 2 ein Gateway mit der VPN IP 192.168.80.2 auf tun0, und der lokalen IP 192.168.150.20.

routen:

default via 192.168.150.1 dev eth0 
192.168.80.0/24 dev tun0 proto kernel scope link src 192.168.80.2 
192.168.150.0/24 dev eth0 proto kernel scope link src 192.168.150.20 
192.168.190.0/24 via 192.168.80.1 dev tun0 

Ich kann jetzt problemlos aus dem 192.168.150.0 netz ins 192.168.190.* pingen, auch ist 192.168.80.2 vom vpn server erreichbar. Was aber nicht geht ist der andere weg ins 150.* Netzwerk an Standort 2, selbst vom VPN Server aus kann ich 192.168.150.20 (oder andere Rechner im Netz) nicht anpingen. Ein tcp dump auf dem vpn server zeigt dass die pings noch raus gehen, ein tcpdump auf dem Gateway an Standort 2 zeigt aber gar nichts mehr an.

Wie können die Pakete auf dem Weg verloren gehen, oder was kann das Problem sein?

Was ich verstanden habe:

┌───────────RZ──────────────────────────┐           .───────────.           ┌──────────Standort A───────────────────┐
│ Verwaltungsnetz: 192.168.190.0/24     │        ,─'             '─.        │  LAN: 192.168.150.0/24                │
│                                       │      ,'                   `.      │  VPN Gegenstelle IP: 192.168.80.2/24  │
│ OpenVPN Transfernetz: 192.168.80.0/24 │     ;                       :     │  LAN GW: 192.168.150.1                │
│ VPN Server RZ IP: 192.168.80.1/24     ├─────:       INTERNET        ;─────┤                                       │
│ GW: ?                                 │      ╲                     ╱      │                                       │
│                                       │       `.                 ,'       │                                       │
│                                       │         '─.           ,─'         │                                       │
└───────────────────────────────────────┘            `─────────'            └───────────────────────────────────────┘

Fragen:

• Wer ist im RZ GW?

• Wie genau ist die OpenVPN Konfiguration (S2S oder Road Warrior)?

• Wie genau sie die Konfiguration in beiden Standorten aus (sysctl.conf) bitte als codeblock

• Sind die Systeme du du zum testen pings alles Linux/Unix System oder ist da auch Windoof bei?

Andi79 schrieb:

Ein tcp dump auf dem vpn server zeigt dass die pings noch raus gehen, ein tcpdump auf dem Gateway an Standort 2 zeigt aber gar nichts mehr an.

Teste mal am Standort 2 mit:

sudo tcpdump -c 20 -vvveni tun0 icmp

wenn Du den Ping vom Standort 1 machst.

Teste mal am Standort 2 mit:

sudo tcpdump -c 20 -vvveni tun0 icmp

wenn Du den Ping vom Standort 1 machst.

ein ping auf 192.168.80.2 kommt an

tcpdump: listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
20:36:25.830142 ip: (tos 0x0, ttl 64, id 19240, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.80.1 > 192.168.80.2: ICMP echo request, id 104, seq 1, length 64
20:36:25.830272 ip: (tos 0x0, ttl 64, id 912, offset 0, flags [none], proto ICMP (1), length 84)

bei einem Ping auf 192.168.150.20 (eth0) allerdings gähnende leere.

ein tcpdump auf dem VPN Server zeigt aber, raus geht der Ping

tcpdump: listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
20:39:10.407047 ip: (tos 0x0, ttl 64, id 26610, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.80.1 > 192.168.150.110: ICMP echo request, id 108, seq 1, length 64
20:39:11.428414 ip: (tos 0x0, ttl 64, id 26679, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.80.1 > 192.168.150.110: ICMP echo request, id 108, seq 2, length 64

und was eben auch geht ist vom 192.168.150.0/24 hin ins 192.168.190.0/24 zu pingen. Wie als wäre in eine Richtung ein tiefer Abgrund in dem alles verschwindet ☺. Es ist ja nicht nur so dass das Gateway 192.168.80.2 nichts weiterleitet, er scheint nichtmal was zu empfangen. Firewallregeln gibt es zwischen denen aber auch keine

Andi79 schrieb:

bei einem Ping auf 192.168.150.20 (eth0) allerdings gähnende leere.

ein tcpdump auf dem VPN Server zeigt aber, raus geht der Ping
und was eben auch geht ist vom 192.168.150.0/24 hin ins 192.168.190.0/24 zu pingen.

Hast Du (... wenn das routing vollständig und OK ist) das source-NAT (MASQUERADE) an den zuständigen Interfaces (richtig) konfiguriert?

micneu schrieb:

Was ich verstanden habe:

┌───────────RZ──────────────────────────┐           .───────────.           ┌──────────Standort A───────────────────┐
│ Verwaltungsnetz: 192.168.190.0/24     │        ,─'             '─.        │  LAN: 192.168.150.0/24                │
│                                       │      ,'                   `.      │  VPN Gegenstelle IP: 192.168.80.2/24  │
│ OpenVPN Transfernetz: 192.168.80.0/24 │     ;                       :     │  LAN GW: 192.168.150.1                │
│ VPN Server RZ IP: 192.168.80.1/24     ├─────:       INTERNET        ;─────┤                                       │
│ GW: ?                                 │      ╲                     ╱      │                                       │
│                                       │       `.                 ,'       │                                       │
│                                       │         '─.           ,─'         │                                       │
└───────────────────────────────────────┘            `─────────'            └───────────────────────────────────────┘

Fragen:

• Wer ist im RZ GW?

Also sowohl der VPN server im RZ als auch der Rechner am anderen Standort haben ihre default route / gw auf den jeweiligen Internetdevices. Beim Standort 2 rechner geht die route über das tun0 device zum VPN Server selbst der Gateway ins 192.168.190.0/24 macht, im Verwaltungsnetz hat der VPN Server eine Route nach 192.168.150.0/24 mit gw 192.168.80.2. Beide fungieren praktisch gegenseitig als Gateway in ihr Netz.

• Wie genau ist die OpenVPN Konfiguration (S2S oder Road Warrior)?

s2s. Sollte zumindest.

• Wie genau sie die Konfiguration in beiden Standorten aus (sysctl.conf) bitte als codeblock

vpn server & gateway am anderen Standort

# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#

net.ipv4.ip_forward=1

• Sind die Systeme du du zum testen pings alles Linux/Unix System oder ist da auch Windoof bei?

Alles Linuxkisten

Das seltsame ist vor allem dass pings vom vpn server ja über tun0 raus gehen, aber nie beim empfänger ankommen. Pings an die vpn ip (also das hinterlegte gateway) direkt kommen dagegen an. Bei einem forwardproblem würde ich zumindest annehmen dass die pings ankommen, dann aber verworfen werden.

Andi79 schrieb:

Bei einem forwardproblem würde ich zumindest annehmen dass die pings ankommen, dann aber verworfen werden.

Verworfen wird auch dann, wenn der Rückweg nicht bekannt ist.

Verworfen wird auch dann, wenn der Rückweg nicht bekannt ist.

müsste er nicht aber zumindest die eingehenden pakete beim tcpdump anzeigen? ich lausch ja auf tun0

Andi79 schrieb:

müsste er nicht aber zumindest die eingehenden pakete beim tcpdump anzeigen?

Wenn er die eingehenden Pakete nicht anzeigt, dann stimmt m. E. das Routing _für Ziel dieser Pakete_, nicht.

lubux schrieb:

Hast Du (... wenn das routing vollständig und OK ist) das source-NAT (MASQUERADE) an den zuständigen Interfaces (richtig) konfiguriert?

für was müsste da ein ip Masquerading eingerichtet werden, sind ja nur 2 private netze die untereinander verbunden werden sollen und ins 192.168.190.0 Netz geht es ja auch so. Ich hab aber testweise trotzdem mal was eingerichtet, hatte auch keine Auswirkung.

Wenn er die eingehenden Pakete nicht anzeigt, dann stimmt m. E. das Routing _für Ziel dieser Pakete_, nicht.

nur welches. ich seh die pakete ja am vpn server rausgehen über tun0

default via XXX.XXX.XXX.XX dev br0 onlink 
XXX.XXX.XXX.XXX/27 dev br0 proto kernel scope link src XXX.XXX.XXX.XXX
192.168.80.0/24 dev tun0 proto kernel scope link src 192.168.80.1 
192.168.150.0/24 via 192.168.80.2 dev tun0 src 192.168.80.1 
192.168.190.0/24 dev eth1 scope link 
192.168.190.0/24 dev eth1 proto kernel scope link src 192.168.190.200 

und hier das routing des gateways am anderen Standort

default via 192.168.150.1 dev eth0 
192.168.80.0/24 dev tun0 proto kernel scope link src 192.168.80.2 
192.168.150.0/24 dev eth0 proto kernel scope link src 192.168.150.20 
192.168.190.0/24 via 192.168.80.1 dev tun0

Das VPN schickt also pings an 192.168.150.0/24 via 192.168.80.2 dev tun0 src 192.168.80.1 raus (was man auch sieht im dump). Wo könnte das verloren gehen?

was auch nicht geht ist die route so zu setzen am vpn server

192.168.150.0/24 via 192.168.80.2 dev tun0 src 192.168.190.200

auch hier das gleiche spiel, pings gehen raus, kommen aber nicht an

tcpdump: listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
21:44:54.596485 ip: (tos 0x0, ttl 64, id 18060, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.190.200 > 192.168.150.20: ICMP echo request, id 119, seq 4, length 64

Jetzt bitte die VPN Konfigs als Codeblock

vpn server

port 1194
proto udp4
dev tun0
persist-key
persist-tun
client-to-client
ca ca.crt  
cert issued/server.crt  
key private/server.key 
dh dh.pem  
topology subnet  
server 192.168.80.0 255.255.255.0  
route 192.168.80 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt


client-to-client  
keepalive 10 120  
tls-auth ta.key 0  
key-direction 0
cipher AES-256-CBC  
persist-key  
persist-tun  
status /var/log/openvpn/openvpn-status.log  
log-append /var/log/openvpn/openvpn.log  
verb 1
explicit-exit-notify 1  
auth SHA512
script-security 3 
client-config-dir /etc/openvpn/ip

client standort 2

client
dev tun
#dev tap
proto udp4
remote XXX.XXX.XXX.XXX 1194
resolv-retry infinite
nobind
persist-key
persist-tun
verb 5
cipher AES-256-CBC
auth SHA512
key-direction 1
tls-auth /etc/openvpn/ta.key 1
mute-replay-warnings
ca "/etc/openvpn/ca.crt"
cert "/etc/openvpn/vpngateway.standort2.crt"
key "/etc/openvpn/vpngateway.standort2.key"
keepalive 10 60
tls-cipher "DEFAULT:@SECLEVEL=0"
remote-cert-tls server

Ihr solltet eure OpenVPN-Konfiguration auf den aktuellen Stand der Technik bringen. Die Verwendung von CBC gilt nicht mehr als zeitgemäß.