lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Revilum schrieb: Also könnte ich doch einen VPN Tunnel vom Client zum Server eröffnen und dann vom CLient aus auf das Internet zugreifen . Der letzte schritt aber funktioniert aber leider nicht.
Wie sind auf dem debian-Client, die Ausgaben von:
route -n
ip a
?
|
Revilum
(Themenstarter)
Anmeldungsdatum: 9. März 2018
Beiträge: 23
|
route -n: | Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.178.1 0.0.0.0 UG 100 0 0 enp6s0
192.168.178.0 0.0.0.0 255.255.255.0 U 100 0 0 enp6s0
|
ip a: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether f8:32:e4:6f:04:a3 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.31/24 brd 192.168.178.255 scope global dynamic enp6s0
valid_lft 863761sec preferred_lft 863761sec
inet6 2a04:4540:8203:8501:c9f8:1285:9f5d:d637/64 scope global temporary dynamic
valid_lft 6996sec preferred_lft 3396sec
inet6 2a04:4540:8203:8501:fa32:e4ff:fe6f:4a3/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 6996sec preferred_lft 3396sec
inet6 fe80::fa32:e4ff:fe6f:4a3/64 scope link
valid_lft forever preferred_lft forever
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Revilum schrieb: route -n: | Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.178.1 0.0.0.0 UG 100 0 0 enp6s0
192.168.178.0 0.0.0.0 255.255.255.0 U 100 0 0 enp6s0
|
Das sind die Ausgaben ohne VPN-Verbindung (ohne VPN-Tunnel vom Client zum Server). Poste die Ausgaben, wenn der VPN-Tunnel hergestellt ist.
|
Revilum
(Themenstarter)
Anmeldungsdatum: 9. März 2018
Beiträge: 23
|
Achso mit VPN an. route -n: | Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.178.1 0.0.0.0 UG 100 0 0 enp6s0
10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0
10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
128.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
192.168.2.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
192.168.178.0 0.0.0.0 255.255.255.0 U 100 0 0 enp6s0
192.168.178.60 0.0.0.0 255.255.255.255 UH 0 0 0 enp6s0
|
ip a: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22 | 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether f8:32:e4:6f:04:a3 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.31/24 brd 192.168.178.255 scope global dynamic enp6s0
valid_lft 863388sec preferred_lft 863388sec
inet6 2a04:4540:8203:8501:c9f8:1285:9f5d:d637/64 scope global temporary dynamic
valid_lft 7160sec preferred_lft 3560sec
inet6 2a04:4540:8203:8501:fa32:e4ff:fe6f:4a3/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7160sec preferred_lft 3560sec
inet6 fe80::fa32:e4ff:fe6f:4a3/64 scope link
valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 10.8.0.6 peer 10.8.0.5/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::4cbd:ef80:b8bd:bfc6/64 scope link stable-privacy
valid_lft forever preferred_lft forever
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Revilum schrieb: Achso mit VPN an. route -n: | Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.178.1 0.0.0.0 UG 100 0 0 enp6s0
10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0
10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
128.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0
192.168.2.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
192.168.178.0 0.0.0.0 255.255.255.0 U 100 0 0 enp6s0
192.168.178.60 0.0.0.0 255.255.255.255 UH 0 0 0 enp6s0
|
Starte mal auf dem PI (VPN-Server):
sudo tcpdump -vvveni tun0 icmp
(evtl. tun0 anpassen) und mach danach vom VPN-Client einen Ping ins Internet:
ping -c 3 1.1.1.1
Was zeigt tcpdump auf dem PI, nach dem Ping von Client, an?
|
Revilum
(Themenstarter)
Anmeldungsdatum: 9. März 2018
Beiträge: 23
|
bei ping -c 3 1.1.1.1
| PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2031ms
|
und bei tcpdump -vvveni tun0 icmp | tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel
|
Nach einer Zeit habe ich dann den Prozess abgebrochen weil nichts passiert ist.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Revilum schrieb: Nach einer Zeit habe ich dann den Prozess abgebrochen weil nichts passiert ist.
Teste mal auf dem debian-Client, ob beim ping, auch die default route mit dem dev tun0 genutzt wird:
sudo tcpdump -c 50 -vvveni tun0 icmp
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Hast du Masquerading auf dem Pi aktiviert? Zeig mal auf dem Pi
iptables -t nat -nvL
|
Revilum
(Themenstarter)
Anmeldungsdatum: 9. März 2018
Beiträge: 23
|
| Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
|
|
Revilum
(Themenstarter)
Anmeldungsdatum: 9. März 2018
Beiträge: 23
|
lubux schrieb: Revilum schrieb: Nach einer Zeit habe ich dann den Prozess abgebrochen weil nichts passiert ist.
Teste mal auf dem debian-Client, ob beim ping, auch die default route mit dem dev tun0 genutzt wird:
sudo tcpdump -c 50 -vvveni tun0 icmp
also mit VPN | tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
|
ohne: | tcpdump: tun0: No such device exists
(SIOCGIFHWADDR: No such device)
|
:
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Revilum schrieb: also mit VPN | tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
|
Immer mit VPN. Dann teste mal mit VPN, ob diese 2. default route (mit ungünstiger metric)
0.0.0.0 192.168.178.1 0.0.0.0 UG 100 0 0 enp6s0
benutzt wird:
sudo tcpdump -c 40 -vvveni enp6s0 icmp and host 1.1.1.1
|
Revilum
(Themenstarter)
Anmeldungsdatum: 9. März 2018
Beiträge: 23
|
lubux schrieb: Revilum schrieb: also mit VPN | tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
|
Immer mit VPN. Dann teste mal mit VPN, ob diese 2. default route (mit ungünstiger metric)
0.0.0.0 192.168.178.1 0.0.0.0 UG 100 0 0 enp6s0
benutzt wird:
sudo tcpdump -c 40 -vvveni enp6s0 icmp and host 1.1.1.1
Langsam verstehe ich nur noch Bahnhof also ich habe einfach nur | >> tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
>>
|
eingegeben und das kam raus: | tcpdump: listening on enp6s0, link-type EN10MB (Ethernet), capture size 262144 bytes
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Revilum schrieb: ... also ich habe einfach nur | >> tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
>>
|
eingegeben und das kam raus: | tcpdump: listening on enp6s0, link-type EN10MB (Ethernet), capture size 262144 bytes
|
Das mit der Ausgabe kann nicht sein und ich habe auch nicht geschrieben, dass Du
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
eingeben sollst.
|
Revilum
(Themenstarter)
Anmeldungsdatum: 9. März 2018
Beiträge: 23
|
lubux schrieb: Revilum schrieb: ... also ich habe einfach nur | >> tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
>>
|
eingegeben und das kam raus: | tcpdump: listening on enp6s0, link-type EN10MB (Ethernet), capture size 262144 bytes
|
Das mit der Ausgabe kann nicht sein und ich habe auch nicht geschrieben, dass Du
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
eingeben sollst.
Ich bin gerade mit Copy Paste durcheinander gekommen und ich habe nochmal die letzte Stunde damit verbracht den Artikel nochmal sehr gründlich durchzulesen wodurch mir dann aufgefallen ist dass ich das Masquerading vergessend hatte (eigentlich gedacht habe dass ich das nicht brauche) ich werde aber nochmal den Thread bis morgen auflassen da ich das Gefühl habe dass ich noch ein paar weitere Fehler haben werde.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Revilum schrieb: Ich bin gerade mit Copy Paste durcheinander gekommen und ich habe nochmal die letzte Stunde damit verbracht den Artikel nochmal sehr gründlich durchzulesen wodurch mir dann aufgefallen ist dass ich das Masquerading vergessend hatte (eigentlich gedacht habe dass ich das nicht brauche) ich werde aber nochmal den Thread bis morgen auflassen da ich das Gefühl habe dass ich noch ein paar weitere Fehler haben werde.
Naja, damit das Masquerading auch wirken kann, muss auf dem Client auch das richtige gateway (bzw. die richtige default route) genutzt werden. Und das war bis jetzt (lt. den Ausgaben von tcpdump) aber nicht der Fall.
|