dlewando
Anmeldungsdatum: 4. Juli 2006
Beiträge: 382
|
hi folks,
mein forwarding funktioniert nicht mehr. hat sich unter ubuntu 18.04 da irgendwas geändert? hier mal ein beispiel:
meine interface:
enp2s0 ist das interface richtung router, sprich internet tun0 tunnelinterface von openvpn die restlichen interface sind uninteressant
dlewando@nc-nas:~$ ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
inet6 fe80::42:f0ff:fee7:1331 prefixlen 64 scopeid 0x20<link>
ether 02:42:f0:e7:13:31 txqueuelen 0 (Ethernet)
RX packets 3312 bytes 2001685 (2.0 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 19992 bytes 4927523 (4.9 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.44 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fd87:7ae4:82c6:0:3aea:a7ff:fea9:2bf4 prefixlen 64 scopeid 0x0<global>
inet6 fe80::3aea:a7ff:fea9:2bf4 prefixlen 64 scopeid 0x20<link>
ether 38:ea:a7:a9:2b:f4 txqueuelen 1000 (Ethernet)
RX packets 36942758 bytes 49752869702 (49.7 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 38622426 bytes 45713235622 (45.7 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18
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 101034 bytes 11507896 (11.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 101034 bytes 11507896 (11.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 192.168.9.1 netmask 255.255.255.255 destination 192.168.9.2
inet6 fe80::8afd:87fc:91aa:8622 prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 3135 bytes 203025 (203.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 15596 bytes 3746344 (3.7 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vethb913e14: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::bc24:f5ff:fe3e:546e prefixlen 64 scopeid 0x20<link>
ether be:24:f5:3e:54:6e txqueuelen 0 (Ethernet)
RX packets 1414 bytes 1425869 (1.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10083 bytes 2592730 (2.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
jetzt forwarding und PAT (port address translation) aktivieren:
dlewando@nc-nas:~$
dlewando@nc-nas:$ sudo sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
dlewando@nc-nas:$ sudo iptables -t nat -A POSTROUTING -o enp2s0 -j MASQUERADE
jetzt kommt der funktionstest:
1. ping auf google dns, also 8.8.8.8. es wird das "normale" enp2s0 interface (192.168.1.44) gewählt, da es ja die defaultroute nutzt
dlewando@nc-nas:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=122 time=16.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=122 time=16.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=122 time=22.9 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 16.315/18.542/22.970/3.131 ms
dlewando@nc-nas:~$
jetzt kommt der gleiche ping, allerdings nehme ich das tun0 interface, welches aus einem anderen netz kommt (192.168.9.1)
dlewando@nc-nas:~$ ping -I tun0 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.168.9.1 tun0: 56(84) bytes of data.
und schon ist ende im gelände ... jemand ne ahnung, warum das forwarding hier nicht greift?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
dlewando schrieb: jetzt kommt der gleiche ping, allerdings nehme ich das tun0 interface, welches aus einem anderen netz kommt (192.168.9.1)
dlewando@nc-nas:~$ ping -I tun0 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.168.9.1 tun0: 56(84) bytes of data.
und schon ist ende im gelände ... jemand ne ahnung, warum das forwarding hier nicht greift?
Wie ist die Ausgabe von:
route -n
?
|
dlewando
(Themenstarter)
Anmeldungsdatum: 4. Juli 2006
Beiträge: 382
|
dlewando@nc-nas:~$ route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 100 0 0 enp2s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp2s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp2s0
192.168.9.0 192.168.9.2 255.255.255.0 UG 0 0 0 tun0
192.168.9.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
dlewando@nc-nas:~$
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
dlewando schrieb: Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 100 0 0 enp2s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp2s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp2s0
192.168.9.0 192.168.9.2 255.255.255.0 UG 0 0 0 tun0
192.168.9.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
Starte mal vor dem Ping:
sudo tcpdump -c 100 -vvveni tun0 icmp
und führe danach:
ping -I tun0 8.8.8.8
aus. Wie ist nach dem Ping die Ausgabe von tcpdump?
|
dlewando
(Themenstarter)
Anmeldungsdatum: 4. Juli 2006
Beiträge: 382
|
dlewando@nc-nas:~$ ping -I tun0 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.168.9.1 tun0: 56(84) bytes of data.
dlewando@nc-nas:~$ sudo tcpdump -c 100 -vvveni tun0 icmp
[sudo] Passwort für dlewando:
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
13:02:15.684237 ip: (tos 0x0, ttl 64, id 47195, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 8.8.8.8: ICMP echo request, id 9575, seq 1, length 64
13:02:16.692738 ip: (tos 0x0, ttl 64, id 47250, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 8.8.8.8: ICMP echo request, id 9575, seq 2, length 64
13:02:17.716757 ip: (tos 0x0, ttl 64, id 47455, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 8.8.8.8: ICMP echo request, id 9575, seq 3, length 64
13:02:18.740758 ip: (tos 0x0, ttl 64, id 47542, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 8.8.8.8: ICMP echo request, id 9575, seq 4, length 64
13:02:19.764751 ip: (tos 0x0, ttl 64, id 47731, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 8.8.8.8: ICMP echo request, id 9575, seq 5, length 64
13:02:20.788744 ip: (tos 0x0, ttl 64, id 47919, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 8.8.8.8: ICMP echo request, id 9575, seq 6, length 64
13:02:21.812761 ip: (tos 0x0, ttl 64, id 48130, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 8.8.8.8: ICMP echo request, id 9575, seq 7, length 64
13:02:22.836765 ip: (tos 0x0, ttl 64, id 48294, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 8.8.8.8: ICMP echo request, id 9575, seq 8, length 64
13:02:23.860759 ip: (tos 0x0, ttl 64, id 48543, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 8.8.8.8: ICMP echo request, id 9575, seq 9, length 64
13:02:24.884735 ip: (tos 0x0, ttl 64, id 48587, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 8.8.8.8: ICMP echo request, id 9575, seq 10, length 64
13:02:25.908733 ip: (tos 0x0, ttl 64, id 48621, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 8.8.8.8: ICMP echo request, id 9575, seq 11, length 64
^C
11 packets captured
11 packets received by filter
0 packets dropped by kernel
dlewando@nc-nas:~$
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
dlewando schrieb: 13:02:25.908733 ip: (tos 0x0, ttl 64, id 48621, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 8.8.8.8: ICMP echo request, id 9575, seq 11, length 64
Jetzt:
sudo iptables -t nat -I POSTROUTING 1 -o tun0 -j MASQUERADE
eingeben und erneut versuchen.
|
dlewando
(Themenstarter)
Anmeldungsdatum: 4. Juli 2006
Beiträge: 382
|
leider gleiches verhalten.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
dlewando schrieb: leider gleiches verhalten.
D. h. es werden mit tcpdump auch keine "ICMP echo reply" angezeigt?
Dann versuch mal mit tcpdump auf dem VPN-Server, um zu sehen, ob dort die "ICMP echo requests" ankommen.
|
dlewando
(Themenstarter)
Anmeldungsdatum: 4. Juli 2006
Beiträge: 382
|
😁 das ist der vpnserver
das masquerading kann ja eigentlich erstmal weggelassen werden. was halt nicht funktioniert is das forwarding von tun0 nach enp2s0. wie als wäre ne firewall aktiv. oder openvpn blockiert das irgendwie?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
dlewando schrieb: das ist der vpnserver
OK, dann auf dem VPN-Client (d. h. dort wohin der Ping gehen soll).
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
dlewando schrieb: was halt nicht funktioniert is das forwarding von tun0 nach enp2s0.
Was genau meinst Du mit forwarding von tun0 nach enp2s0? Kannst Du z. Zt. die IP-Adresse des tun-Interfaces auf dem VPN-Client pingen (d. h. ping im Zwischennetz)?
|
dlewando
(Themenstarter)
Anmeldungsdatum: 4. Juli 2006
Beiträge: 382
|
ping von tun0 nach enp2s0
dlewando@nc-nas:~$ ping -I tun0 192.168.1.44
PING 192.168.1.44 (192.168.1.44) from 192.168.9.1 tun0: 56(84) bytes of data.
dump zeigt echo request auf tun0
dlewando@nc-nas:~$ sudo tcpdump -i tun0 -vvvn host 192.168.9.1
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
12:11:59.124757 IP (tos 0x0, ttl 64, id 46265, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 192.168.1.44: ICMP echo request, id 4364, seq 93, length 64
12:12:00.148732 IP (tos 0x0, ttl 64, id 46476, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 192.168.1.44: ICMP echo request, id 4364, seq 94, length 64
12:12:01.172677 IP (tos 0x0, ttl 64, id 46543, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 192.168.1.44: ICMP echo request, id 4364, seq 95, length 64
12:12:02.196738 IP (tos 0x0, ttl 64, id 46625, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 192.168.1.44: ICMP echo request, id 4364, seq 96, length 64
12:12:03.220745 IP (tos 0x0, ttl 64, id 46643, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 192.168.1.44: ICMP echo request, id 4364, seq 97, length 64
12:12:04.244727 IP (tos 0x0, ttl 64, id 46742, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.9.1 > 192.168.1.44: ICMP echo request, id 4364, seq 98, length 64
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
dlewando@nc-nas:~$
auf enp2s0 kommt der request aber nicht an,
dlewando@nc-nas:~$ sudo tcpdump -i enp2s0 -vvvn host 192.168.9.1
tcpdump: listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
also macht der kein forwarding von tun0 auf enp2so. also funktioniert der befehl
dlewando@nc-nas:$ sudo sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
nicht. hat sich der befehl vielleicht in der syntax auf ubuntu 18.04 geändert? edit:
ich habe das jetzt auch mal auf meinem notebook versucht, indem ich manuell noch ein interface hinzugefügt habe:
dlewando@notebook:~$ ping -I enp1s0 192.168.1.119
PING 192.168.1.119 (192.168.1.119) from 192.168.9.1 enp1s0: 56(84) bytes of data.
^C
--- 192.168.1.119 ping statistics ---
17 packets transmitted, 0 received, 100% packet loss, time 16391ms
dlewando@notebook:~$ sudo sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
dlewando@notebook:~$ ping -I enp1s0 192.168.1.119
PING 192.168.1.119 (192.168.1.119) from 192.168.9.1 enp1s0: 56(84) bytes of data.
^C
--- 192.168.1.119 ping statistics ---
36 packets transmitted, 0 received, 100% packet loss, time 35818ms
dlewando@notebook:~$
da läuft auch ubuntu 18.04 und da geht's auch nicht.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
dlewando schrieb: ping von tun0 nach enp2s0
Ich meinte den Ping von tun0 (VPN-Server) nach tun0 (VPN-Client).
|
dlewando
(Themenstarter)
Anmeldungsdatum: 4. Juli 2006
Beiträge: 382
|
jetzt wird's komisch. ping vom vpn-client zur interfaceadresse von enp2s0 funktioniert
dlewando@nc-nas:~$ sudo tcpdump -n -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
13:04:52.495181 IP 192.168.9.6 > 192.168.1.44: ICMP echo request, id 5, seq 1, length 64
13:04:52.495266 IP 192.168.1.44 > 192.168.9.6: ICMP echo reply, id 5, seq 1, length 64
13:04:53.485999 IP 192.168.9.6 > 192.168.1.44: ICMP echo request, id 5, seq 2, length 64
13:04:53.486059 IP 192.168.1.44 > 192.168.9.6: ICMP echo reply, id 5, seq 2, length 64
13:04:54.492006 IP 192.168.9.6 > 192.168.1.44: ICMP echo request, id 5, seq 3, length 64
13:04:54.492066 IP 192.168.1.44 > 192.168.9.6: ICMP echo reply, id 5, seq 3, length 64
13:04:55.490876 IP 192.168.9.6 > 192.168.1.44: ICMP echo request, id 5, seq 4, length 64
13:04:55.490944 IP 192.168.1.44 > 192.168.9.6: ICMP echo reply, id 5, seq 4, length 64
13:04:56.489709 IP 192.168.9.6 > 192.168.1.44: ICMP echo request, id 5, seq 5, length 64
13:04:56.489770 IP 192.168.1.44 > 192.168.9.6: ICMP echo reply, id 5, seq 5, length 64
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
aber auf dem enp2s0 interface sehe ich nichts ankommen? man sieht die pakete nur auf dem tun0?
dlewando@nc-nas:~$ sudo tcpdump -n -i enp2s0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
ps: ping auf den router 192.168.1.254 vom vpn-client funktioniert allerdings nicht.
ps2: ping von tun0 server nach tun0 client geht natürlich auch (also 192.168.9.1 nach 192.168.9.6)
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
dlewando schrieb: jetzt wird's komisch. ping vom vpn-client zur interfaceadresse von enp2s0 funktioniert
Wo befindet sich das Interface enp2s0? Auf dem VPN-Client oder auf dem VPN-Server? Wie ist der Ping von tun0 (VPN-Server) nach tun0 (VPN-Client)?
|