Hallo,
Ich habe auf eine Cloud Server von Hetzner die VPN Dinste OpenVPN und WireGuard am laufen so weit so gut. Nun ist emine fragen kann man das so einrichten das ich von WG zu OpenVPN und OpenVPN zu WG via IP schalten kann? Den OpenVPN brauch ich leiter für 2x Synolegis die leider nur disen Dinst können.
WG ip ist 10.7.0.1/24
OpenVPN IP ist 10.8.0.1/24
MfG Pilipp Lindner
Das sollte gehen, allerdings kann der Schuss auch schnell nach hinten losgehen. An deiner Stelle würde ich eine weitere VM mit einer Software Firewall (bspw. OPNsense oder pfsense) installieren. Dort kannst du beide VPN Dienste konfigurieren und untereinander Routen lassen. Außerdem steht die Firewall Funktionalität zur Verfügung, sodass du nur einzelne Verbindungen/Ports zulassen kannst, also z.B. administrative Ports nur bestimmen IP Adressen erlaubst. Ist wesentlich einfacher als irgendwelche config files zu verpfuschen, die man eh nicht versteht, und hinterher den Server und dahinterliegende Dienste für jeden Angreifer ausversehen verfügbar macht.
Kannst du das etwas genauer formulieren?
Geht es darum, das du vom WG-Netz auf OpenVPN-Netz zugreifen willst und umgekehrt? Oder was ganz anderes.
Wenn meine Vermutung richtig ist, musst du nur das forwarding aktivieren.
Internet sharing - ArchWiki
Warning: Enabling IP forwarding without a properly configured firewall is a security risk.
ja ich will von WG-netz ins OpenVPN-Netz uns Umgekehrt. danke für den tip
Wenn du das Forwarding generll aktivierst, solltest du noch eine Firewall installieren, damit niemand von außen auf deine VPNs kommt.
Alternativ kannst du testen, ob es vielleicht auch schon ausreichend ist, das Forwarding nur für die VPN-Interfaces zu aktivieren
sudo sysctl -a|grep forward
# einzelnes Interface -> Funktionsfähigkeit ist nicht geprüft...
sudo sysctl -w net.ipv4.conf.<interface-name>.forwarding=1
# Für alle Interfaces aktivieren
sudo sysctl -w net.ipv4.ip_forward=1
Hallo, Leider hat die Einstellung nichts gebracht keine Verbindung zur Nas via OpenVPN meine einstellung siehe bild:
Schau mal, ob du mit tcpdump mehr heraus bekommst.
Beispiel:
tcpdump -i <interface>
# Zeige ICMP-Pakete (dazu gehört ping) auf Interface tun0 an
tcpdump -i tun0 icmp
tcpdump -i wg0 icmp
# oder mit Angabe eine Adresse
tcpdump -i tun0 host 1.2.3.4
...
Siehe tcpdump(1) man page | TCPDUMP & LIBPCAP Absatz EXAMPLES
Da bekommst du vielleicht heraus oder kannst es eingrenzen, ob deine Pakete überhaupt weitergeleitet werden. Bevor oder während du tcpdump ausführst macht es natürlich Sinn pings von A nach B zu schicken.
Hier das ergebnis aus TCP Dump, OpenVPN zu WG geht. WG zu OpenVPN nicht.
WG ausgabe.
root@VPN-Server:~# tcpdump -i wg0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
21:09:04.946894 IP 10.7.0.6 > 10.8.0.5: ICMP echo request, id 1, seq 219, length 40
21:09:09.854713 IP 10.7.0.6 > 10.8.0.5: ICMP echo request, id 1, seq 220, length 40
21:09:14.854829 IP 10.7.0.6 > 10.8.0.5: ICMP echo request, id 1, seq 221, length 40
21:09:19.844396 IP 10.7.0.6 > 10.8.0.5: ICMP echo request, id 1, seq 222, length 40
21:09:33.067124 IP 10.7.0.6 > 10.8.0.2: ICMP echo request, id 1, seq 223, length 40
21:09:37.862660 IP 10.7.0.6 > 10.8.0.2: ICMP echo request, id 1, seq 224, length 40
21:09:42.855333 IP 10.7.0.6 > 10.8.0.2: ICMP echo request, id 1, seq 225, length 40
21:09:47.836666 IP 10.7.0.6 > 10.8.0.2: ICMP echo request, id 1, seq 226, length 40
21:11:21.850925 IP static.110.18.217.95.clients.your-server.de > 10.7.0.6: ICMP ip reassembly time exceeded, length 556
21:11:21.850948 IP static.110.18.217.95.clients.your-server.de > 10.7.0.6: ICMP ip reassembly time exceeded, length 556
21:11:21.850957 IP static.110.18.217.95.clients.your-server.de > 10.7.0.6: ICMP ip reassembly time exceeded, length 556
21:11:21.850962 IP static.110.18.217.95.clients.your-server.de > 10.7.0.6: ICMP ip reassembly time exceeded, length 556
21:11:21.850970 IP static.110.18.217.95.clients.your-server.de > 10.7.0.6: ICMP ip reassembly time exceeded, length 556
21:11:21.850976 IP static.110.18.217.95.clients.your-server.de > 10.7.0.6: ICMP ip reassembly time exceeded, length 556
21:12:53.528450 IP static.110.18.217.95.clients.your-server.de > 10.7.0.2: ICMP echo request, id 1, seq 231, length 40
21:12:53.585384 IP 10.7.0.2 > static.110.18.217.95.clients.your-server.de: ICMP echo reply, id 1, seq 231, length 40
21:12:54.544801 IP static.110.18.217.95.clients.your-server.de > 10.7.0.2: ICMP echo request, id 1, seq 232, length 40
21:12:54.593377 IP 10.7.0.2 > static.110.18.217.95.clients.your-server.de: ICMP echo reply, id 1, seq 232, length 40
21:12:55.562768 IP static.110.18.217.95.clients.your-server.de > 10.7.0.2: ICMP echo request, id 1, seq 233, length 40
21:12:55.734944 IP 10.7.0.2 > static.110.18.217.95.clients.your-server.de: ICMP echo reply, id 1, seq 233, length 40
21:12:56.583294 IP static.110.18.217.95.clients.your-server.de > 10.7.0.2: ICMP echo request, id 1, seq 234, length 40
21:12:56.660650 IP 10.7.0.2 > static.110.18.217.95.clients.your-server.de: ICMP echo reply, id 1, seq 234, length 40
OpenVPN Ausgabe:
root@VPN-Server:~# tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
21:03:52.739237 IP static.110.18.217.95.clients.your-server.de > 10.8.0.2: ICMP echo request, id 1, seq 211, length 40
21:03:57.354196 IP static.110.18.217.95.clients.your-server.de > 10.8.0.2: ICMP echo request, id 1, seq 212, length 40
21:04:02.361746 IP static.110.18.217.95.clients.your-server.de > 10.8.0.2: ICMP echo request, id 1, seq 213, length 40
21:04:07.354296 IP static.110.18.217.95.clients.your-server.de > 10.8.0.2: ICMP echo request, id 1, seq 214, length 40
21:06:35.930094 IP static.110.18.217.95.clients.your-server.de > 10.8.0.5: ICMP echo request, id 1, seq 215, length 40
21:06:45.874749 IP static.110.18.217.95.clients.your-server.de > 10.8.0.5: ICMP echo request, id 1, seq 217, length 40
21:06:50.848222 IP static.110.18.217.95.clients.your-server.de > 10.8.0.5: ICMP echo request, id 1, seq 218, length 40
21:09:04.946963 IP static.110.18.217.95.clients.your-server.de > 10.8.0.5: ICMP echo request, id 1, seq 219, length 40
21:09:09.854758 IP static.110.18.217.95.clients.your-server.de > 10.8.0.5: ICMP echo request, id 1, seq 220, length 40
21:09:14.854868 IP static.110.18.217.95.clients.your-server.de > 10.8.0.5: ICMP echo request, id 1, seq 221, length 40
21:09:19.844430 IP static.110.18.217.95.clients.your-server.de > 10.8.0.5: ICMP echo request, id 1, seq 222, length 40
21:09:33.067220 IP static.110.18.217.95.clients.your-server.de > 10.8.0.2: ICMP echo request, id 1, seq 223, length 40
21:09:37.862705 IP static.110.18.217.95.clients.your-server.de > 10.8.0.2: ICMP echo request, id 1, seq 224, length 40
21:09:42.855369 IP static.110.18.217.95.clients.your-server.de > 10.8.0.2: ICMP echo request, id 1, seq 225, length 40
21:09:47.836707 IP static.110.18.217.95.clients.your-server.de > 10.8.0.2: ICMP echo request, id 1, seq 226, length 40
21:12:53.528381 IP 10.8.0.6 > 10.7.0.2: ICMP echo request, id 1, seq 231, length 40
21:12:53.585426 IP 10.7.0.2 > 10.8.0.6: ICMP echo reply, id 1, seq 231, length 40
21:12:54.544774 IP 10.8.0.6 > 10.7.0.2: ICMP echo request, id 1, seq 232, length 40
21:12:54.593408 IP 10.7.0.2 > 10.8.0.6: ICMP echo reply, id 1, seq 232, length 40
21:12:55.562737 IP 10.8.0.6 > 10.7.0.2: ICMP echo request, id 1, seq 233, length 40
21:12:55.734982 IP 10.7.0.2 > 10.8.0.6: ICMP echo reply, id 1, seq 233, length 40
21:12:56.583164 IP 10.8.0.6 > 10.7.0.2: ICMP echo request, id 1, seq 234, length 40
21:12:56.660695 IP 10.7.0.2 > 10.8.0.6: ICMP echo reply, id 1, seq 234, length 40
21:14:14.171916 IP 10.8.0.1 > 10.8.0.6: ICMP 10.8.0.1 udp port 5351 unreachable, length 38
die Obersen ausgaben ist WG zu OpenVPN der Unter ist OpenVPN zu WG
ip route.allowed-ips eingetragen?Hallo,
Firewalls bzw NAT habe ich nichts zusetzliches eingetragen
die AllowedIPs sind auf serverseite auf den jewaligen cliend eingetragen als 10.7.0.x/32 auf Cient seiet auf 0.0.0.0/0
Hier der eintragen von IP Routs:
root@VPN-Server:~# ip r
default via 172.31.1.1 dev eth0
10.7.0.0/24 dev wg0 proto kernel scope link src 10.7.0.1
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
172.31.1.1 dev eth0 scope link
Mich verwirrt hier etwas ganz gewalttätig bzgl den IPs im tcpdump.
Ich fasse mal zusammen:
Es wird von 10.7.0.6 (vermutlich Windows-PC, typischer Echo-Request) einmal (mit 4 Requests) nach 10.8.0.5 und einmal (ebenfalls mit 4 Requests) nach 10.8.0.2 gepingt, ist aus dem wg0-dump gut zu entnehmen. Ich fokussiere mich mal auf die Sequenz 219.
Im tun0-dump ist die Sequenz ebenfalls zu sehen, Routing stimmt also.
Ich gehe mal davon aus, das 10.8.0.2 und 10.8.0.5 die beiden Synologys sein sollen.
Was jetzt im tun0-dump ausbleibt, ist das Echo-Reply von den Syns. Man sieht im wg0-dump nur, wie zum 10.7.0.6 ein Timeout gemeldet wurde.
Danach wird von der OpenVPN-Seite von einer ganz anderen IP zu einer wiederrum anderen IP auf WG-Seite gepingt, welche überraschend funktioniert, aber zwei gänzlich unterschiedliche Endpunkte sind und damit den Funktionstest verfälschen.
Wenn dann bitte auch von den Synologys aus auch 10.7.0.6 anpingen. Dazu den SSH-Dienst auf den Syns aktivieren und sich per SSH einloggen. Aber vorher mal deren Netzwerkeinstellung überprüfen, ob die auch kerrekt ist.
Da ich OpenVPN auf der Synology nicht verwende, kann ich nur raten und würde vermuten, dass dort die Route zum WG-Netzwerk fehlt. Es genügt nicht, diese mittels „AllowedIPs“ auf dem Cloud-Server bei Hetzner zu setzen, die muss auch auf den Synologys vorhanden sein.
Hallo @Lonaril,
das WG nterz hat dei IP 10.7.0.x/24, das OpenVPN hatdie IP 10.8.0.x/24, ich habe mich auf eine der beiden Synos geschalten und wolte die WG IP 10.7.0.1 anpingen da kam volgende Meldung: ping -I tun1 10.7.0.1 ping: socket: Operation not permitted in der Route stehet volgenden drin:
default via 192.168.1.1 dev eth0 src 192.168.1.42
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.5
10.8.0.0/24 dev tun1 proto kernel scope link src 10.8.0.5
95.217.18.110 via 192.168.1.1 dev eth0 src 192.168.1.42
192.168.0.0/20 dev eth0 proto kernel scope link src 192.168.1.42
wo soll ich dei Route eintragen via ssh odert über sie oberfliche?
Auch wenn du zu Gruppe der Administratoren gehörst, wirst du in der SSH nur als Standard-User gesehen und diese dürfen ‚Ping‘ nicht ausführen auf der Synology. Sollte man am ‚$‘ erkennen können. Nur beim Root ist es ‚#‘. Aber wenn du zur Gruppe der Administratoren (via WebGUI) gehörst, gehörst du auch zur sudo-Gruppe. Versuche es mal mit vorangestellten ‚sudo‘, dann sollte es funktionieren.
sudo ping -I tun1 10.7.0.1
danke für den Tip volgendes ist reausgekommen:
$ sudo ping -I tun1 10.7.0.1
PING 10.7.0.1 (10.7.0.1) from 10.8.0.5 tun1: 56(84) bytes of data.
64 bytes from 10.7.0.1: icmp_seq=1 ttl=64 time=46.2 ms
64 bytes from 10.7.0.1: icmp_seq=2 ttl=64 time=46.0 ms
64 bytes from 10.7.0.1: icmp_seq=3 ttl=64 time=46.5 ms
64 bytes from 10.7.0.1: icmp_seq=4 ttl=64 time=47.2 ms
64 bytes from 10.7.0.1: icmp_seq=5 ttl=64 time=46.7 ms
64 bytes from 10.7.0.1: icmp_seq=6 ttl=64 time=46.6 ms
64 bytes from 10.7.0.1: icmp_seq=7 ttl=64 time=46.1 ms
64 bytes from 10.7.0.1: icmp_seq=8 ttl=64 time=46.1 ms
64 bytes from 10.7.0.1: icmp_seq=9 ttl=64 time=49.6 ms
64 bytes from 10.7.0.1: icmp_seq=10 ttl=64 time=46.5 ms
64 bytes from 10.7.0.1: icmp_seq=11 ttl=64 time=46.3 ms
64 bytes from 10.7.0.1: icmp_seq=12 ttl=64 time=45.10 ms
64 bytes from 10.7.0.1: icmp_seq=13 ttl=64 time=46.6 ms
64 bytes from 10.7.0.1: icmp_seq=14 ttl=64 time=46.4 ms
64 bytes from 10.7.0.1: icmp_seq=15 ttl=64 time=47.4 ms
64 bytes from 10.7.0.1: icmp_seq=16 ttl=64 time=46.8 ms
^C
--- 10.7.0.1 ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 40ms
rtt min/avg/max/mdev = 45.977/46.682/49.566/0.846 ms
als ist die Rute da
Geht der Ping auch ohne Angabe des Interface?
Wenn die Routen in der Synology stimmen, sollte das gehen.
Durch Angabe des Interface tun1 umgehst du in gewisser Weise ja die Routing-Tabellen auf der Synology.
[Edit]
Sehe den Fehler, habe den Auszug der Routing-Tabelle von deiner Synology übersehen.
Da fehlt eine Route:
10.7.0.0/24 dev tun1 proto kernel scope link src 10.8.0.5
Und ohne diese greift ja die Synology somit auf die dafault zurück:
default via 192.168.1.1 dev eth0 src 192.168.1.42
als so die Rute eintragen wie sie angegben haben?
es kann auch keine ping an.
Schau mal, ob du diese in der Synology als statische Route anlegen kannst.
Ich nutze leider kein OpenVPN, deswegen kann ích es selber nicht testen.
ok mit Statischer rut get das, blöd blos das sie Synology nicht das Interfas name ales Schitstellen angib da ist es eine Rätzelraden wlche VPN der Richtige ist.
brereucht ich ach noch eine Rückrut auf der Synology ?
Nein, denn wenn ich das oben schon richtig herausgelesen habe (ist oft schwierig bei fehlenden Satzzeichen) hast du auf der WG-Clientseite schon eine Route zu den Synologys.
Ich trage dort allerdings immer nur notwendige Routen ein. Ein deinem Fall sollte aber dies reichen:
AllowedIPs = 10.7.0.1, 10.8.0.0/24
Die WG-Tunnel-IP des Servers und die des OpenVPN-Netzwwerkes dahinter.
Die Routen auf dem Server sind OK.