|
mw2000
Anmeldungsdatum:
27. Dezember 2009
Beiträge: Zähle...
|
Hi zusammen, ich habe bei mir im Routing ein "Knoten und komme da nicht richtig weiter. Vielleicht kann mir ja jemand einen Tip geben, wo ich suchen kann... Aufbau des Netzwerkes:
Netzwerk "1" ist mein Heimnetzwerk mit folgenden Rechnern:
192.168.1.1 → fritzbox (Router und Gateway von Netzwerk 1) 192.168.1.41 → ubuntuserver (WG-A) 192.168.1.84 → ubuntuclient
Netzwerk "5" ist mein Remote Netzwerk mit folgenden Rechnern:
Beide Netzwerke verbinde ich über Wireguard. Dazu läuft eine Verbindung zwischen WG-A (IP: 10.0.0.1) und WG-B (IP: 10.0.0.5). Damit alle Rechner im Netzwerk 1 auf das Netzwerk 5 zugreifen können habe ich in der Fritzbox eine statische Route (192.168.5.0 via 192.168.1.41 angelegt) Das funktioniert soweit gut, wie man an folgenden Listings sieht:
| matthias@WG-A:~$ sudo wg show
interface: VPN
public key: tf.....
private key: (hidden)
listening port: 38783
peer: yr...
endpoint: 176.xxx
allowed ips: 10.0.0.5/32, 192.168.5.0/24
latest handshake: 1 minute, 16 seconds ago
transfer: 604.12 KiB received, 363.07 KiB sent
|
1
2
3
4
5
6
7
8
9
10
11
12 | root@WG-B:~# wg show
interface: NAXOSVPN
public key: yr...
private key: (hidden)
listening port: 47674
peer: tf...
endpoint: 109.xxx
allowed ips: 10.0.0.0/24, 192.168.5.0/24, 192.168.1.0/24
latest handshake: 55 seconds ago
transfer: 470.22 KiB received, 839.79 KiB sent
persistent keepalive: every 25 seconds
|
Wenn ich mich nun auf WG-A einlogge, kann ich die Verbindung testen:
| matthias@WG-A:~$ traceroute 192.168.5.203
traceroute to 192.168.5.203 (192.168.5.203), 30 hops max, 60 byte packets
1 10.0.0.5 (10.0.0.5) 87.362 ms 95.579 ms 95.514 ms
2 * * *
3 * * 192.168.5.203 (192.168.5.203) 86.716 ms
|
Sieht Top aus. Ich kann mich von WG-A auf WG-B mit SSH einloggen und mach nun folgendes:
| root@WG-B:~# traceroute 192.168.1.41
traceroute to 192.168.1.41 (192.168.1.41), 30 hops max, 38 byte packets
1 192.168.1.41 (192.168.1.41) 57.595 ms 61.315 ms 56.199 ms
root@WG-B:~# traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 38 byte packets
1 * *^C
|
Leider funktioniert aus der Richtung von WG-B nur der Zugriff auf WG-A, aber nicht die Weiterleitung an andere Rechner im Netz 1. Wichtig: Das ganze System hat lange Zeit gut funktioniert, bis ich den Rechner WG-A ein Distro Update gemacht habe, daher vermute ich schwer den Fehler im Routing von WG-A Dazu ein paar Infos zu WG-A:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25 | matthias@WG-B:~$ ip r
default via 192.168.1.1 dev eth0
10.0.0.0/24 dev VPN proto kernel scope link src 10.0.0.1
192.168.1.0/24 dev eth0
192.168.5.0/24 dev VPN scope link
matthias@WG-A:~$ ifconfig
VPN: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1420
inet 10.0.0.1 netmask 255.255.255.0 destination 10.0.0.1
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC)
RX packets 4675 bytes 635424 (635.4 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3703 bytes 389592 (389.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.41 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::a2b3:ccff:fedf:20fd prefixlen 64 scopeid 0x20<link>
inet6 fd00::a2b3:ccff:fedf:20fd prefixlen 64 scopeid 0x0<global>
inet6 2a02:8070:487:7e80:a2b3:ccff:fedf:20fd prefixlen 64 scopeid 0x0<global>
ether a0:b3:cc:df:20:fd txqueuelen 1000 (Ethernet)
RX packets 1296835 bytes 439167939 (439.1 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 538610 bytes 306819083 (306.8 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18
|
Eine Verbindung von 192.168.1.84 zu dem Netz 5 funktioniert ebenfalls nicht. Habt Ihr eine Idee wie ich dem auf die Spur komme? Irgendwie scheine die Pakete nicht von WG-A raus in Netzwerk 1 zu kommen... Danke für tips
|
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum:
18. Oktober 2016
Beiträge: 16818
|
Leider funktioniert aus der Richtung von WG-B nur der Zugriff auf WG-A, aber nicht die Weiterleitung an andere Rechner im Netz 1.
Dann zeige Die Routingtabelle von WG-B.
|
|
mw2000
(Themenstarter)
Anmeldungsdatum:
27. Dezember 2009
Beiträge: 90
|
Hi, anbei die Routingtabelle von WG-B: | root@WG-B:~# ip r
default dev wwan0 proto static scope link src 10.157.91.142 metric 4
10.0.0.0/24 dev NAXOSVPN proto kernel scope link src 10.0.0.5
10.0.0.1 via 10.0.0.5 dev NAXOSVPN
10.xxx.xxx.xxx dev wwan0 proto static scope link metric 4
192.168.1.0/24 via 10.0.0.1 dev NAXOSVPN
192.168.5.0/24 dev br-lan proto static scope link metric 3
|
Ich denke aber das Routing in WG-B sollte i.O sein, WG-B ja erfolgreich Pakete von WG-A nach Netz 5 ( z.B 192.168.5.203) und zurück leitet. Mein Verständnis des der Route von Netz5 in Netz 1 sehe so aus:
auf 192.168.5.203 wird ping 192.168.1.1 ausgeführt: 192.168.5.203 (RasPi) 192.168.5.1 (WG-B - br-lan) 10.0.0.5 (WG-B → NAXOSVPN) 10.0.0.1 (WG-A → VPN) 192.168.1.41 (WG-A → eth0) 192.168.1.1 (fritzbox)
In die Richtung funktioniert dies nur von 1 nach 5 und in die Andere Richtung nur von 5 nach 1. Irgendwie muss doch das Routing 5 nach 6 nicht i.O. sein oder?
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 13293
|
mw2000 schrieb: Aufbau des Netzwerkes:
Netzwerk "1" ist mein Heimnetzwerk mit folgenden Rechnern:
192.168.1.1 → fritzbox (Router und Gateway von Netzwerk 1) 192.168.1.41 → ubuntuserver (WG-A) 192.168.1.84 → ubuntuclient
Netzwerk "5" ist mein Remote Netzwerk mit folgenden Rechnern:
Beide Netzwerke verbinde ich über Wireguard. ...
Poste mal vom Ubuntuclient (192.168.1.84) die Ausgabe von:
ip r g 192.168.5.202
Starte auf dem Ubuntuserver (192.168.1.41):
sudo tcpdump -c 20 -vvveni eth0 icmp
sudo tcpdump -c 20 -vvveni VPN icmp
und auf dem Wireguard-gateway-Gerät (im anderen Subnetz):
sudo tcpdump -c 20 -vvveni NAXOSVPN icmp
Mach vom Ubuntuclient (192.168.1.84) einen Ping auf die IP-Adresse 192.168.5.202 und poste danach die Ausgaben von tcpdump. BTW: Für jedes deiner Geräte in der o. g. Konstellation, gibt es Wireguard. Ein Routing zwischen Subnetzen (lan-to-lan) sollte somit nicht mehr erforderlich sein.
|
|
mw2000
(Themenstarter)
Anmeldungsdatum:
27. Dezember 2009
Beiträge: 90
|
Poste mal vom Ubuntuclient (192.168.1.84) die Ausgabe von:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29 | matthias@ubuntuclient:~$ ip r g 192.168.5.202
192.168.5.202 via 192.168.1.1 dev enp0s31f6 src 192.168.1.84 uid 1000
cache
matthias@ubuntuclient:~$ ifconfig
enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.84 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 2a02:8070:487:7e80:24de:f504:f49b:80b4 prefixlen 64 scopeid 0x0<global>
inet6 fe80::1e86:356e:cd25:b9d3 prefixlen 64 scopeid 0x20<link>
inet6 2a02:8070:487:7e80:9fd8:78c1:ab3f:36b5 prefixlen 64 scopeid 0x0<global>
ether 40:8d:5c:4b:d0:fa txqueuelen 1000 (Ethernet)
RX packets 1024828 bytes 672238575 (672.2 MB)
RX errors 0 dropped 123207 overruns 0 frame 0
TX packets 514512 bytes 89908811 (89.9 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xdf300000-df320000
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Lokale Schleife)
RX packets 481819 bytes 47681774 (47.6 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 481819 bytes 47681774 (47.6 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
matthias@ubuntuclient:~$ ip r
default via 192.168.1.1 dev enp0s31f6 proto dhcp metric 100
169.254.0.0/16 dev enp0s31f6 scope link metric 1000
192.168.1.0/24 dev enp0s31f6 proto kernel scope link src 192.168.1.84 metric 100
|
Starte auf dem Ubuntuserver (192.168.1.41) und mach vom Ubuntuclient (192.168.1.84) einen Ping auf die IP-Adresse 192.168.5.202 :
1
2
3
4
5
6
7
8
9
10
11
12 | matthias@naxos:~$ sudo tcpdump -c 20 -vvveni eth0 icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
matthias@naxos:~$ sudo tcpdump -c 20 -vvveni VPN icmp
tcpdump: listening on VPN, link-type RAW (Raw IP), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
|
der Router WG-B hat leider kein tcpdump installiert, da schaue ich gerade noch ob ich ein paket dafür finde.
BTW: Für jedes deiner Geräte in der o. g. Konstellation, gibt es Wireguard. Ein Routing zwischen Subnetzen (lan-to-lan) sollte somit nicht mehr erforderlich sein.
Ja ich weiss das die Fritzbox mit der neuesten FW jetzt wireguard kann. leider habe ich es noch nicht geschafft von dem entfernen Router WB-B (ist ein RUT955) eine Verbindung mit der Fritzbox direkt zu etablieren. Ich brauche den zentralen Wireguard Zugang im Netz1, da ich mit allen Geräten(iPhone, Tablets etc) auf des fremde Netz5 zugreifen will. Das setup wie beschrieben, hat 2 Jahre lang tadellos funktioniert, bis ich die ubuntuserver auf 22.04LTS und die Fritzbox auf FW-7.50 upgedated habe. ICh hatte mir damals bei der Einrichtung (war auch etwas fummelig) sogar alle Daten abgestrieben und ich sehe bei ip -r auch keinen unterschied zu damals, daher bin ich auch so lost...
|
|
mw2000
(Themenstarter)
Anmeldungsdatum:
27. Dezember 2009
Beiträge: 90
|
hier noch ein andere Auszug mitgeloggt auf WG-A(192.168.1.41):
Ausgeführt auf Rechner 192.168.5.203 ping auf 192.168.1.1 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22 | matthias@WG-A:~$ sudo tcpdump -c 20 -vvveni eth0 icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
matthias@WG-A:~$ sudo tcpdump -c 20 -vvveni VPN icmp
tcpdump: listening on VPN, link-type RAW (Raw IP), snapshot length 262144 bytes
09:29:47.143246 ip: (tos 0x0, ttl 63, id 42380, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.5 > 192.168.1.1: ICMP echo request, id 7, seq 10, length 64
09:29:48.183176 ip: (tos 0x0, ttl 63, id 42459, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.5 > 192.168.1.1: ICMP echo request, id 7, seq 11, length 64
09:29:49.223123 ip: (tos 0x0, ttl 63, id 42524, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.5 > 192.168.1.1: ICMP echo request, id 7, seq 12, length 64
09:29:50.263256 ip: (tos 0x0, ttl 63, id 42535, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.5 > 192.168.1.1: ICMP echo request, id 7, seq 13, length 64
09:29:51.303348 ip: (tos 0x0, ttl 63, id 42552, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.5 > 192.168.1.1: ICMP echo request, id 7, seq 14, length 64
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel
|
Ist es nicht so, das auf WG-A hier das packet ankommt über das Netz 10.0.0.0 dev VPN aber nicht zum physikalischem Netz eth0 weitergegeben wird?
|
|
mw2000
(Themenstarter)
Anmeldungsdatum:
27. Dezember 2009
Beiträge: 90
|
mittlerweile habe ich auch auf dem WG-B tcpdump installieren können. hier noch ein andere Auszug mitgeloggt auf WG-B(192.168.5.1): Ausgeführt auf Rechner 192.168.1.41 ping auf 192.168.5.203 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48 | root@WG-B:~# ip r
default dev wwan0 proto static scope link src 10.157.91.142 metric 4
10.0.0.0/24 dev NAXOSVPN proto kernel scope link src 10.0.0.5
10.0.0.1 via 10.0.0.5 dev NAXOSVPN
10.157.91.142 dev wwan0 proto static scope link metric 4
192.168.1.0/24 via 10.0.0.1 dev NAXOSVPN
192.168.5.0/24 dev br-lan proto static scope link metric 3
root@WG-B:~# tcpdump -c 20 -vvveni br-lan icmp
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
09:42:34.491166 00:1e:42:3d:ef:c2 > 00:e0:4c:36:00:29, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 57625, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.1 > 192.168.5.203: ICMP echo request, id 26, seq 1, length 64
09:42:34.492105 00:e0:4c:36:00:29 > 00:1e:42:3d:ef:c2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 47882, offset 0, flags [none], proto ICMP (1), length 84)
192.168.5.203 > 10.0.0.1: ICMP echo reply, id 26, seq 1, length 64
09:42:35.491106 00:1e:42:3d:ef:c2 > 00:e0:4c:36:00:29, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 57795, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.1 > 192.168.5.203: ICMP echo request, id 26, seq 2, length 64
09:42:35.492054 00:e0:4c:36:00:29 > 00:1e:42:3d:ef:c2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 47939, offset 0, flags [none], proto ICMP (1), length 84)
192.168.5.203 > 10.0.0.1: ICMP echo reply, id 26, seq 2, length 64
09:42:36.491112 00:1e:42:3d:ef:c2 > 00:e0:4c:36:00:29, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 57950, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.1 > 192.168.5.203: ICMP echo request, id 26, seq 3, length 64
09:42:36.492045 00:e0:4c:36:00:29 > 00:1e:42:3d:ef:c2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 47958, offset 0, flags [none], proto ICMP (1), length 84)
192.168.5.203 > 10.0.0.1: ICMP echo reply, id 26, seq 3, length 64
09:42:37.489612 00:1e:42:3d:ef:c2 > 00:e0:4c:36:00:29, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 58092, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.1 > 192.168.5.203: ICMP echo request, id 26, seq 4, length 64
09:42:37.490504 00:e0:4c:36:00:29 > 00:1e:42:3d:ef:c2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 47987, offset 0, flags [none], proto ICMP (1), length 84)
192.168.5.203 > 10.0.0.1: ICMP echo reply, id 26, seq 4, length 64
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel
root@WG-B:~# tcpdump -c 20 -vvveni NAXOSVPN icmp
tcpdump: listening on NAXOSVPN, link-type RAW (Raw IP), capture size 262144 bytes
09:43:45.729127 ip: (tos 0x0, ttl 64, id 4485, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.1 > 192.168.5.203: ICMP echo request, id 27, seq 1, length 64
09:43:45.730393 ip: (tos 0x0, ttl 63, id 48652, offset 0, flags [none], proto ICMP (1), length 84)
192.168.5.203 > 10.0.0.1: ICMP echo reply, id 27, seq 1, length 64
09:43:46.689124 ip: (tos 0x0, ttl 64, id 4649, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.1 > 192.168.5.203: ICMP echo request, id 27, seq 2, length 64
09:43:46.690413 ip: (tos 0x0, ttl 63, id 48701, offset 0, flags [none], proto ICMP (1), length 84)
192.168.5.203 > 10.0.0.1: ICMP echo reply, id 27, seq 2, length 64
09:43:47.729104 ip: (tos 0x0, ttl 64, id 4709, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.1 > 192.168.5.203: ICMP echo request, id 27, seq 3, length 64
09:43:47.730330 ip: (tos 0x0, ttl 63, id 48727, offset 0, flags [none], proto ICMP (1), length 84)
192.168.5.203 > 10.0.0.1: ICMP echo reply, id 27, seq 3, length 64
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
root@Teltonika-RUT955:~#
|
Bei einem Ping ausgeführt auf Rechner 192.168.1.84 zu 192.168.5.203, kommt da gar nichts an ....
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 13293
|
mw2000 schrieb: Starte auf dem Ubuntuserver (192.168.1.41) und mach vom Ubuntuclient (192.168.1.84) einen Ping auf die IP-Adresse 192.168.5.202 :
matthias@naxos:~$ sudo tcpdump -c 20 -vvveni eth0 icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel :~$ ip r g 192.168.5.202
192.168.5.202 via 192.168.1.1 dev enp0s31f6 src 192.168.1.84 uid 1000
cache
Wenn der Ubuntuserver das gateway ins WG-VPN/Subnetz .5.0/24 ist und die FritzBox das weiß, warum kommen dann die icmp-Pakete (ping) am eth0-Interface vom Ubuntuserver(gateway), nicht an? Verlassen die icmp-Pakete überhaupt den Ubuntuclient? Schau mal nach mit:
sudo tcpdump -c 20 -vvveni enp0s31f6 icmp
auf dem Ubuntuclient nach. Oder werden diese icmp-Pakete in der FritzBox geblockt? EDIT:
Damit alle Rechner im Netzwerk 1 auf das Netzwerk 5 zugreifen können habe ich in der Fritzbox eine statische
Route (192.168.5.0 via 192.168.1.41 angelegt)
|
|
mw2000
(Themenstarter)
Anmeldungsdatum:
27. Dezember 2009
Beiträge: 90
|
Update. Es gab scheinbar auf der Fritzbox (Gateway 192.168.1.1) einen Fehler im Routing. Wenn ich nun auf 192.168.1.84 einen Ping auf 192.168.5.202 ausführe erscheint im WG-A (192.168.1.41) folgendes: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23 | matthias@WG-A:~$ sudo tcpdump -c 20 -vvveni eth0 icmp
[sudo] Passwort für matthias:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:52:50.008393 2c:91:ab:95:a2:c7 > a0:b3:cc:df:20:fd, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 17096, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.84 > 192.168.5.202: ICMP echo request, id 11, seq 1, length 64
15:52:51.008800 2c:91:ab:95:a2:c7 > a0:b3:cc:df:20:fd, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 17255, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.84 > 192.168.5.202: ICMP echo request, id 11, seq 2, length 64
15:52:52.025218 2c:91:ab:95:a2:c7 > a0:b3:cc:df:20:fd, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 17373, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.84 > 192.168.5.202: ICMP echo request, id 11, seq 3, length 64
15:52:53.049388 2c:91:ab:95:a2:c7 > a0:b3:cc:df:20:fd, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 17384, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.84 > 192.168.5.202: ICMP echo request, id 11, seq 4, length 64
15:52:54.073377 2c:91:ab:95:a2:c7 > a0:b3:cc:df:20:fd, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 17586, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.84 > 192.168.5.202: ICMP echo request, id 11, seq 5, length 64
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel
matthias@WG-A:~$ sudo tcpdump -c 20 -vvveni VPN icmp
tcpdump: listening on VPN, link-type RAW (Raw IP), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
|
Das bedeutet doch das Routing im Netzwerk hin zum WG-A funktioniert oder?
Es scheint die Übergabe zwischen eth0 und VPN auf WG-A (192.168.1.41) in beide Richtungen nicht zu funktionieren....
|
|
mw2000
(Themenstarter)
Anmeldungsdatum:
27. Dezember 2009
Beiträge: 90
|
Heureka ..... 🤓 Ich habe die Lösung gefunden. So Simpel wie auch nervig nach einer Woche suchen. Aktiviere einfach das ip-Forwarding | matthias@WG-A:~$ sudo sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
|
... jetzt noch permanent aktivieren 😎 Danke an alle Helfer, die Befehle waren sehr hilfreich zur Eingrenzung des Problems....
|
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum:
18. Oktober 2016
Beiträge: 16818
|
Das musst du dann natürlich auch für IPv6 machen.
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 13293
|
mw2000 schrieb: Ich habe die Lösung gefunden. So Simpel wie auch nervig nach einer Woche suchen. Aktiviere einfach das ip-Forwarding | matthias@WG-A:~$ sudo sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
|
Dann stimmt aber deine Aussage aus dem Beitrag von 09:25 Uhr (siehe oben) nicht:
Das setup wie beschrieben, hat 2 Jahre lang tadellos funktioniert, bis ich die ubuntuserver auf 22.04LTS
und die Fritzbox auf FW-7.50 upgedated habe.
Denn durch das updaten vom Ubuntuserver (gateway ins WG-VPN) verschwindet der Eintrag:
net.ipv4.ip_forward = 1
ja nicht plötzlich aus der sysctl.conf (oder gleichwertig). ... und ohne forwarding kann ein Gerät nicht als gateway fungieren. Naja, man darf sich auf nichts verlassen und muss jedes Detail hinterfragen.
|
|
mw2000
(Themenstarter)
Anmeldungsdatum:
27. Dezember 2009
Beiträge: 90
|
Denn durch das updaten vom Ubuntuserver (gateway ins WG-VPN) verschwindet der Eintrag:
net.ipv4.ip_forward = 1
ja nicht plötzlich aus der sysctl.conf (oder gleichwertig). ... und ohne forwarding kann ein Gerät nicht als gateway fungieren.
Naja, man darf sich auf nichts verlassen und muss jedes Detail hinterfragen.
Sorry, aber ich kann es mir auch nicht erklären. Es funktionierte ja vorher 2 Jahre lang mit Ubuntu 20.04LTS fehlerfrei. Wie das beim update verschwunden ist (ggf auf default zurückgesetzt, vielleicht habe ich das auch unbewusst gemacht) kann ich auch nicht mehr nachvollziehen. Taktisch unklug war sicher den ubuntuserver und die Fritzbox gleichzeitig upzudaten, da dies mich am Anfang etwas verwirrt hat, wo der Fehler denn liegen mag.
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 13293
|
mw2000 schrieb: Taktisch unklug war sicher den ubuntuserver und die Fritzbox gleichzeitig upzudaten, ...
Nein, das hat damit nichts zu tun.
|