voidcore
Anmeldungsdatum: 17. November 2016
Beiträge: Zähle...
|
Guten Abend, ich stehe vor folgenden Problem und verstehe es selber aktuell nicht mehr. Ich habe eine PI im Netzwerk (192.168.0.127) in der FritzBox ist das port 5900 auf den PI weitergeleitet.
Wenn ich mich nun aus dem Internet via VNC Viewer verbinden möchte passt das alles. ABER: Sobald ich auf den PI einen VPN aktiviere ist der VNC nicht mehr erreichbar, x11vnc haben ich an die IP vom PI gebunden: | Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 192.168.0.127:5900 0.0.0.0:* LISTEN 1000 14174 1673/x11vnc
|
Ohne VPN:
| Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default fritz.box 0.0.0.0 UG 0 0 0 wlan0
link-local * 255.255.0.0 U 0 0 0 wlan0
192.168.0.0 * 255.255.255.0 U 0 0 0 wlan0
|
Aktuelle Routing Tabelle: (Probleme)
| Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 10.42.10.5 128.0.0.0 UG 0 0 0 tun0
default fritz.box 0.0.0.0 UG 0 0 0 wlan0
10.42.10.1 10.42.10.5 255.255.255.255 UGH 0 0 0 tun0
10.42.10.5 * 255.255.255.255 UH 0 0 0 tun0
128.0.0.0 10.42.10.5 128.0.0.0 UG 0 0 0 tun0
link-local * 255.255.0.0 U 0 0 0 wlan0
hosted-by.lease fritz.box 255.255.255.255 UGH 0 0 0 wlan0
192.168.0.0 * 255.255.255.0 U 0 0 0 wlan0
|
Sobald openvpn gestartet wird kann ich mit aufruf der externen ip (nicht die vom vpn) keine Verbindung zum vnc aufgebaut werden. im Lokalen Netzwert kann ich die 192.168.0.127:5900 aufrufen trotz aktiven vpn. Sollten andere Informationen benötigt werden einfach bescheid sagen. Es ist nicht gewollt den vnc über das vpn zu erreichen. MfG Voidcore
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Das Problem ist, dass die FritzBox den Traffic einfach nur Forwarded ohne die Verbindung von außen zu natten. Das bedeutet, sie verlässt sich darauf, dass der Traffic, der zurückkommt auch wieder über sie geroutet wird. Das ist aber bei dir nicht der Fall. Die Verbindung kommt zwar über die Fritzbox rein, geht aber über das VPN wieder nach außen, weil das die Default-Route für den PI ist. Das macht IMHO die TCP-Verbindung nicht mit, da die Antwort von einer anderen IP kommt, die nicht angefragt wurde. Ich weiß nicht, ob man in der Fritzbox einstellen kann, dass bei Port-Forwarding genattet wird, daher denke ich, du musst OpenVPN vom ändern der Default-Route abhalten. Das hat aber noch ein paar andere Implikationen, die du bedenken musst, da dadurch der Traffic des PI nicht mehr automatisch durchs VPN geht. Alternativ kannst du natürlich auch einfach VNC durchs OpenVPN tunneln.
|
voidcore
(Themenstarter)
Anmeldungsdatum: 17. November 2016
Beiträge: 9
|
Achso, wenn ich also die Internet IP der FritzBox aufrufe dann wird mein Traffic (port 5900) zum PI geleitet.
Jedoch sorgt | default 10.42.10.5 128.0.0.0 UG 0 0 0 tun0
|
das alles ankommende direkt ins VPN weiterleitet wird? Könnte man da irgendwas mit iptables machen? zb. Ankommendes von port 5900 nicht wieder weg schicken wird (routing zur lokalen ip)
Selbe problem habe ich in der Tat auch bei ssh usw. MfG Voidcore
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Dann brauchst du Policy basiertes Routing. Hier kannst du dir die Grundlagen aneignen. In deinem Fall müsste es passen alle einkommenden Pakete auf wlan0 auch dort wieder hinzurouten:
| $ echo "200 vpnfix" >> /etc/iproute2/rt_tables
$ ip rule add iif wlan0 table vpnfix
$ ip route add default dev wlan0 table vpnfix
|
Musst du mal probieren.
|
voidcore
(Themenstarter)
Anmeldungsdatum: 17. November 2016
Beiträge: 9
|
Danke für den Ansatz, hatte jetzt noch keine Zeit deinen Link zu Policy Based Routing komplett durch zu lesen (hole ich aber nach) ich habe die Table "vpnfix" angelegt und die rule und route hinzugefügt: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 | voidcore@box:~$ ip rule
0: from all lookup local
32765: from all iif wlan0 lookup vpnfix
32766: from all lookup main
32767: from all lookup default
voidcore@box:~$ ip route
0.0.0.0/1 via 10.3.10.9 dev tun0
default via 192.168.0.1 dev wlan0 proto static metric 600
10.3.10.1 via 10.3.10.9 dev tun0
10.3.10.9 dev tun0 proto kernel scope link src 10.3.10.10
46.165.210.17 via 192.168.0.1 dev wlan0
128.0.0.0/1 via 10.3.10.9 dev tun0
169.254.0.0/16 dev wlan0 scope link metric 1000
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.127 metric 600
|
Der erhoffte erfolge blieb leider aus, evtl beschreibt es aber der Link. Falls ich etwas übersehen habe, bin dankbar für alles. // Edit:
Muss ich den Pakete "markieren" mit IP Tables um später die routing zuordnung besser machen zu können?
|
voidcore
(Themenstarter)
Anmeldungsdatum: 17. November 2016
Beiträge: 9
|
Guten Tag, ich habe nun über die Option "--route-noexe" die default route von seitens openvpn deaktiviert. Somit wird der Tunnel aufgebaut jedoch nicht default genutzt.
SSH und x11vnc ist somit erstmal möglich, wie oben gepostet gibt es nun das Problem das der Pi den tun0 komplett ignoriert ☹ Gibt es die Möglichkeit zu sagen das alles was von "localhost" oder "192.168.0.127 (IP des Pi)" kommt über den tun0 (openvpn) gesendet werden soll? Danke im Vorraus.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
voidcore schrieb: ich habe nun über die Option "--route-noexe" die default route von seitens openvpn deaktiviert. Somit wird der Tunnel aufgebaut jedoch nicht default genutzt.
Dann kannst du nicht debuggen, warum die vorige Einstellung nicht gegriffen hat. Zeige mal
ip route show table vpnfix
|
voidcore
(Themenstarter)
Anmeldungsdatum: 17. November 2016
Beiträge: 9
|
| ip rule
0: from all lookup local
32765: from all iif wlan0 lookup vpnfix
32766: from all lookup main
32767: from all lookup default
ip route show table vpnfix
default dev wlan0 scope link
ping -I wlan0 google.de <- ohne erfolg
ping -I tun0 google.de <- alles schick
|
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Versuche mal die Default-Route nicht durch ein Interface zu definieren, sondern direkt durch die Fritzbox-IP:
ip route del default dev wlan0 table vpnfix
ip route add default via <Fritzbox-IP> table vpnfix
|
voidcore
(Themenstarter)
Anmeldungsdatum: 17. November 2016
Beiträge: 9
|
Leider ohne erfolg, aktuell habe ich als Workaround Teamviewer auf dem PI installiert, damit komme ich zumindest auf den PI obwohl vpn aktiv ist.
Auf SSHD und andere dienste muss der PI erstmal weiterhin verzichten. Danke dennoch für die hilfen. falls noch jemand idee hat oder links wo man sich belesen kann, dann einfach posten ☺
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Das ist wirklich sehr komisch. Versuche mal folgendes:
| # markieren der Pakete
iptables -A PREROUTING -m conntrack --ctstate NEW -i wlan0 -j CONNMARK --set-mark 0x1
# ändern der Regel, wann die Routing-Tabelle Anwendung findet
ip rule del iif wlan0 table vpnfix
ip rule add fwmark 0x1 table vpnfix
|
Zeige anschließend nochmal:
ip route table vpnfix
ip rule list
Damit sollte es dann funktionieren.
|
voidcore
(Themenstarter)
Anmeldungsdatum: 17. November 2016
Beiträge: 9
|
In dem Syntax sind fehler daher kann ich des nicht Anwenden (auch bin ich aktuell überfragt welche der andere Befehle dazu gehören. Aktuell probiere ich mehr informationen über meine "pakete" zu bekommen. Leider ist tcpdump nicht mein bester kumpel. 1
2
3
4
5
6
7
8
9
10
11
12
13 | sudo tcpdump -n "dst port 22" # VPN deaktiviert (Verbindung wird akzeptiert)
13:21:22.622844 IP 82.x.106.106.51548 > 192.168.0.128.22: Flags [S], seq 3319117182, win 65535, options [mss 1360,nop,wscale 5,nop,nop,TS val 1900307486 ecr 0,sackOK,eol], length 0
13:21:22.939656 IP 82.x.106.106.51548 > 192.168.0.128.22: Flags [.], ack 2577255610, win 4128, options [nop,nop,TS val 1900308177 ecr 115987], length 0
sudo tcpdump -n "dst port 22" # VPN aktiviert (kommt nicht am SSHD an?)
13:23:40.709342 IP 82.x.106.106.40532 > 192.168.0.128.22: Flags [S], seq 502010407, win 65535, options [mss 1360,nop,wscale 5,nop,nop,TS val 1900445906 ecr 0,sackOK,eol], length 0
13:23:41.662597 IP 82.x.106.106.40532 > 192.168.0.128.22: Flags [S], seq 502010407, win 65535, options [mss 1360,nop,wscale 5,nop,nop,TS val 1900446906 ecr 0,sackOK,eol], length 0
|
Gibt es die Möglichkeit iptables zu sagen das wenn ein Paket von "außen" kommt dieses wenn es zum port 22 zeigt auf 127.0.0.1:22 zeigt?
Somit sollte doch unterbunden werden das er die Datenpakete (insofern das noch richtig ist) wieder in den tun0 (default gateway) weiterleitet. Danke im vorraus. ps: über mehr möglichkeiten zu tcpdump wäre ich auch nicht böse ^^ vielleicht finde ich ja meine verschollene pakte ;o
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
voidcore schrieb: In dem Syntax sind fehler daher kann ich des nicht Anwenden (auch bin ich aktuell überfragt welche der andere Befehle dazu gehören.
##
# markieren der Pakete
##
iptables -t nat -A PREROUTING -m conntrack --ctstate NEW -i wlan0 -j CONNMARK --set-mark 0x1
##
# ändern der Regel, wann die Routing-Tabelle Anwendung findet
##
# dieser Befehl funktioniert natürlich nur, wenn die Regel vorhanden ist. Wenn du zwischenzeitlich rebootet hast, sind die IMHO weg
ip rule del iif wlan0 table vpnfix
ip rule add fwmark 0x1 table vpnfix tcpdump ist nicht ganz trivial; diese Optionen nutze ich oftmals:
-i <IF> Interface festlegen, auf dem gelauscht wird
-v Mehr Ausgaben
-vv Noch mehr Ausgaben
-vvv Noch viel mehr Ausgaben
-w <file> Ausgaben in eine Datei schreiben.
-c <number> Nach <number> Paketen abbrechen
Über die Filtermöglichkeiten gibt es hier einen Abschnitt, Beispiele gibts im folgenden Abschnitt. Für dich ist sicherlich -w interessant, womit tcpdump die Pakete in eine Datei schreibt. Diese Datei kannst du dann mit Wireshark analysieren.
|
voidcore
(Themenstarter)
Anmeldungsdatum: 17. November 2016
Beiträge: 9
|
So, nach dem reboot und aktiven VPN habe ich einfach mal alle sachen eingegeben und das ergebnis unten gepostet.
Verbindung kann weiterhin nicht aufgebaut werden, bin aktuell ratlose ☹ 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 |
voidcore@box:~$ ip rule list
0: from all lookup local
32765: from all fwmark 0x1 lookup vpnfix
32766: from all lookup main
32767: from all lookup default
voidcore@box:~$ ip route show table vpnfix
default via 192.168.0.1 dev eth0
voidcore@box:~$ cat /proc/sys/net/ipv4/ip_forward
1
voidcore@box:~$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
CONNMARK all -- anywhere anywhere ctstate NEW CONNMARK set 0x1
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
voidcore@box:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.59.10.5 0.0.0.0 UG 50 0 0 tun0
0.0.0.0 192.168.0.1 0.0.0.0 UG 100 0 0 eth0
10.59.10.1 10.59.10.5 255.255.255.255 UGH 50 0 0 tun0
10.59.10.5 0.0.0.0 255.255.255.255 UH 50 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 tun0
178.162.211.215 192.168.0.1 255.255.255.255 UGH 100 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
|
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
voidcore schrieb: So, nach dem reboot und aktiven VPN habe ich einfach mal alle sachen eingegeben und das ergebnis unten gepostet.
Verbindung kann weiterhin nicht aufgebaut werden, bin aktuell ratlose ☹ | voidcore@box:~$ ip rule list
0: from all lookup local
32765: from all fwmark 0x1 lookup vpnfix
32766: from all lookup main
32767: from all lookup default
|
Das sieht gut aus.
voidcore@box:~$ ip route show table vpnfix
default via 192.168.0.1 dev eth0
Das auch.
voidcore@box:~$ cat /proc/sys/net/ipv4/ip_forward
1
Auch ok.
voidcore@box:~$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
CONNMARK all -- anywhere anywhere ctstate NEW CONNMARK set 0x1
Das ist komisch. Hier sollte theoretisch wlan0 stehen. Hast du eventuell -i wlan0 vergessen? Hier wird das nochmal genauer erklärt. Was ich vergessen habe, ist diese Regel hier:
iptables -A OUTPUT -m connmark --mark 0x1 -j CONNMARK --restore-mark
Versuche mal diese noch zu setzen.
|