y0rul3
Goto Top

Raspberry Pi als Bridge über OpenVPN

Hallo liebe Gemeinde,

ich weiß nicht mehr weiter aus diesem Grund dieser Thread.

Ich habe folgendes vor: Ich habe ein Endgerät in meinem LAN (Videorekorder einer Überwachungskamera) und möchte gerne Zugriff darauf haben. Das Problem ist mein LAN ist über das Mobilfunknetz ans Internet angeschlossen und damit ist simples Portforwarding oder NAT nicht möglich.

Meine Überlegung war: einen kleinen Linux V-Server anmieten, einen OpenVPN Server installieren -> RaspberryPi kaufen, OpenVPN Client installieren und auf den Server konfigurieren sowie ín den Autostart packen (bis hierhin komme ich alleine klappt) IP's des VPN Server werden mit 10.8.0.0/24 vergeben.

Der RasperryPi geht auch über das LTE Mobilfunk LAN ins Internet und hängt im selben LAN wie der EthernetRecorder (Port 80 fürs Webinterface).

Die Frage, die ich euch nun stelle ist: Wie schleife ich den EthernetRecorder durch den RaspberryPi auf den VPN Server durch um Ihn für andere VPN Clients (mein Smartphone, auch auf dem VPN Server) zugänglich zu machen?

Ich danke euch schon jetzt fürs lesen im voraus!

VG
Johannes

Content-Key: 476967

Url: https://administrator.de/contentid/476967

Ausgedruckt am: 28.03.2024 um 17:03 Uhr

Mitglied: Lochkartenstanzer
Lochkartenstanzer 24.07.2019 um 20:27:58 Uhr
Goto Top
Moin,

Du verbindest Dich einfach mit Deinem Client per OpenVPN zu Deinem V-Server und kannst dann direkt, auf Deine Kamera zugreifen, falls Du das routing korrekt eingestellt hast.

lks
Mitglied: y0rul3
y0rul3 24.07.2019 um 20:42:38 Uhr
Goto Top
Hi Lochkartenstanzer,

danke fürs Feedback.

Mir stellt sich folgende Frage:
Was verstehst du untern "das routing korrekt eingestellt hast?"

Ethernetdevice (Kamerarekorder): 192.168.1.150/24
Raspberry Pi (Bridge): 192.168.1.151/24 UND 10.8.0.2
ServerOVPN WANIP+ 10.8.0.1
Smartphone: 10.8.0.4

VG
Johannes
Mitglied: em-pie
em-pie 25.07.2019 um 06:45:03 Uhr
Goto Top
Moin,

Lks will dir sagen, dass du am VPN-Server eine Route setzen musst:
Pakete für das Netz 192.168.1.0/24 muss der VPN-Server an 10.8.0.2 senden.

Der Rekorder muss als Gateway dann noch die 192.168.1.151 eingetragen haben. Ggf. An relevanten Stellen noch die Firewall(s) anpassen und es sollte laufen

Gruß
em-pie
Mitglied: Lochkartenstanzer
Lochkartenstanzer 25.07.2019 aktualisiert um 07:02:53 Uhr
Goto Top
Zitat von @y0rul3:

Hi Lochkartenstanzer,

danke fürs Feedback.

Mir stellt sich folgende Frage:
Was verstehst du untern "das routing korrekt eingestellt hast?"

Ethernetdevice (Kamerarekorder): 192.168.1.150/24
Raspberry Pi (Bridge): 192.168.1.151/24 UND 10.8.0.2

Das ist ein Router und keine Bridge


ServerOVPN WANIP+ 10.8.0.1
Smartphone: 10.8.0.4


Du mußt im Openvpn-Server als statische Rozte einstellen, daß Pakete für das LAN an den Pi gehen und das Handy diese Route auch bekommt.

Am Pi mußt Du noch Routing aktivieren..

lks
Mitglied: Lochkartenstanzer
Lochkartenstanzer 25.07.2019 um 07:07:14 Uhr
Goto Top
Zitat von @em-pie:

Der Rekorder muss als Gateway dann noch die 192.168.1.151 eingetragen haben. Ggf. An relevanten Stellen noch die Firewall(s) anpassen und es sollte laufen


Es reicht eine statische Route im Internetrouter. Man muß dem Rekorder nicht gleich das gateway verbiegen.

lks
Mitglied: aqui
aqui 25.07.2019 um 10:40:33 Uhr
Goto Top
Wenn möglich sollte.man niemals bridgen über das VPN Netzwerk. OpenVPN selber rät davon ab. Route where you can, bridge where you must lautet wie immer die goldene Netzwerker Regel.
Du solltest also immer routen. Kollege LKS hat es ja schon richtig gesagt. Damit die lokalen und auch das vServer Segment in der Routing Tabelle steht musst du das entsprechend konfigurieren.
Das hiesige OpenVPN Tutorial gibt Dir entsprechende Hinweise:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
RasPi Client auch hier
Clientverbindung OpenVPN Mikrotik
Mitglied: y0rul3
y0rul3 30.07.2019 um 21:15:15 Uhr
Goto Top
Hallo nochmal es tut mir wirklich leid. Ich bin der Meinung alles durchgearbeitet zu haben und im Grunde beschreiben die Tutorials folgendes:

https://openvpn.net/community-resources/how-to/#scope

Aber ich habe das Gefühl, dass mein Szenario ein anderes ist.

Ich möchte:

Mit meinem OVPN Client (Smartphone über LTE)
über einen EXTERNEN Server (Hetzner; OpenVPN Server)
und über einen weiteren OVPN Client (Raspi) in dessen LAN ein Gerät (Ethernet Recorder) ansprechen. Und ich habe leider nicht genug Erfahrung um selber die iptables (und was auch noch dazu kommt) am raspi und OpenVPN Server zu setzen face-sad

VG Johannes
Mitglied: aqui
aqui 31.07.2019 um 16:15:55 Uhr
Goto Top
Du musst keinerlei IPtables setzen. Vergiss diesen Unsinn. IPtables sind so oder so per Default immer deaktiviert auf dem RasPi.
Im Grunde ist das eigentlich kinderleicht:
  • OpenVPN Server auf dem ext. Server installieren und dort alle Zertifikate für die Clients generieren. Achtung: Client any zu any Kommunikation in der Server Konfig Datei aktivieren mit: client-to-client
  • IP Adressierung des internen OpenVPN Netzes beachten !! Muss einzigartig sein !
  • OVPN Client und Zertifikat auf dem RasPi einrichten: Clientverbindung OpenVPN Mikrotik ACHTUNG: Hier auf dem RasPi Client zwingend Routing aktivieren ! (Entkommentieren der Zeile #net.ipv4.ip_forward=1 in der Datei /etc/sysctl.conf)
  • OVPN Client und Zertifikat auf dem Smartphone einrichten
  • Fertisch !
Eigentlich ein Kinderspiel was der Azubi in 30 Minuten erledigt. Wie gesagt...vergiss IPtables die sind deaktiviert am RasPi und da muss man auch nix fummeln.
Alles Steps zum Aufsetzen des OVPN Servers findest du hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
und
https://openvpn.net/community-resources/how-to/
Die Steps sind immer die gleichen egal welches Betriebssystem. Das macht OVPN deshalb so flexibel.
Soweit solltest du erstmal kommen...

Ganz wichtig danach fürs Troubleshooting hier:
Mitglied: blacksun
blacksun 21.10.2019 aktualisiert um 10:14:38 Uhr
Goto Top
Zitat von @aqui:
Wenn möglich sollte.man niemals bridgen über das VPN Netzwerk. OpenVPN selber rät davon ab. Route where you can, bridge where you must lautet wie immer die goldene Netzwerker Regel.

Würdest du das näher erläutern warum Bridging schlecht ist.
In einem anderen Forum wurde ich darauf hingewiesen dass es schlecht sei wenn bei TAP die Internetverbindung und das VPN-Ende auf der gleichen Maschine sind, also beides im gleichen Netzwerkstack passiert.

Meine Idee war dass ich transparent für sämtiche Anwendungen auf meinen Clients (z.B. Laptop, Smartphone, usw.) diese in das heimische Netz bringe. Quasi heute verbinde ich mich per WLAN mit meinem Heimnetz, und morgen verbinde ich mich mit einem Hotel-WLAN, baue eine VPN-Verbindung auf, und der Client verhält sich identisch wie am Tag zuvor (z.B. gleiche IP-Adresse, Gateway, DNS, usw.). Die Idee war dass nichts angepasst werden muss wenn ein Client über das Heimnetz oder per OpenVPN-Tunnel verbunden ist. Vom Wake on LAN angefangen über Laufwerkmappings über die IP-Adresse.

Ich habe mir auf der Projektseite die Beschreibung zu tun und tap durchgelesen, z.B. auch das hier
https://community.openvpn.net/openvpn/wiki/BridgingAndRouting

und war dann der Meinung dass Bridging das wäre was ich mir vorgestellt habe.

Nun wurde ich wie gesagt daraufh hingewiesen dass das sehr gefährlich sei, fast schon mit dem Vorwurf wie kann man nur auf die Idee kommen TAP einzusetzen.

Bridge sei nur dafür da um zwei Netzwerke miteinander zu verbinden, nicht aber um mobile Clients anzubinden.
Ich bin daher doch nun sehr verunsichert.


Zitat von @aqui:
Du musst keinerlei IPtables setzen. Vergiss diesen Unsinn. IPtables sind so oder so per Default immer deaktiviert auf dem RasPi.
Im Grunde ist das eigentlich kinderleicht.

Das dachte ich eigentlich auch.
Mitglied: aqui
aqui 21.10.2019 um 10:24:39 Uhr
Goto Top
Würdest du das näher erläutern warum Bridging schlecht ist.
Überlege dir mal selber wie eine Bridge funktioniert !!
https://de.wikipedia.org/wiki/Bridge_(Netzwerk)
Sie arbeitet rein jur auf Layer 2. Für das VPN bedeutet das das dann sämtlicher Broad- und Multicast und Unknown Unicast Traffic über den VPN Tunnel geht und zwar von beiden Netzen an den Enden.
Du hast also schon grundsätzlich ein "Grundrauschen" auf dem VPN Tunnel der ja nur eine begrenzte Bandbreite hat.
Fiktives Beispiel: Gesetzt den Fall du hast 1Gig LAN Interfaces und 500kBit Broad- ,Multicast- und Unknown Unicast Traffic in jedem Netz. Bedeutet dann 1 Mbit Traffic ohne jeglichen Produktivtraffic. Ist deine Internet Bandbreite nur 2Mbit hast du schon permanente 50% Last auf dem WAN Link.
Bridging ist also das Schelchteste und ineffizienteste was man seinem VPN antun kann. Das versteht auch jeder Laie.
und morgen verbinde ich mich mit einem Hotel-WLAN, baue eine VPN-Verbindung auf, und der Client verhält sich identisch wie am Tag zuvor
Auch das ist tückisch, denn die meisten Hotelnetz nutzen ebenso RFC 1918 IP Adressen. Eine intelligente Planung der Heimnetz IP ist also zwingend !
VPNs einrichten mit PPTP
Übrigens kannst du das ganz genau so mit einem gerouteten VPN. Die Zielnetz IPs und Namen im Heimnetz sind doch immer alle gleich. Welches IP netz dein VPN dann hat ist doch völlig Wumpe dann. Hauptsache ist eben das du NICHT im Bridging arbeitest aus den oben genannten Gründen !
Bridge sei nur dafür da um zwei Netzwerke miteinander zu verbinden, nicht aber um mobile Clients anzubinden.
Nein das ist natürlich laienhafter Quatsch. (Sorry !) Ist vermutlich deinem KnowHow geschuldet...?!
Routing ist das Gebot der Stunde ! face-wink
Mitglied: blacksun
blacksun 21.10.2019 aktualisiert um 11:15:44 Uhr
Goto Top
Danke für die schnelle Rückmeldung
Zitat von @aqui:

Würdest du das näher erläutern warum Bridging schlecht ist.
Überlege dir mal selber wie eine Bridge funktioniert !!
https://de.wikipedia.org/wiki/Bridge_(Netzwerk)

Das ist mir schon klar dass da eben alles durch den Tunnel geht. Das steht ja auch so im Vergleich TUN und TAP, mit der Bezeichnung Overhead.
Dass der Broad- und Multicast und Unknown Unicast Traffic so viel ausmacht, das habe ich nicht gedacht.

Auch das ist tückisch, denn die meisten Hotelnetz nutzen ebenso RFC 1918 IP Adressen. Eine intelligente Planung der Heimnetz IP ist also zwingend !
VPNs einrichten mit PPTP
korrekt, das ist mir bewusst und war bei mir schon immer so umgesetzt.

Übrigens kannst du das ganz genau so mit einem gerouteten VPN. Die Zielnetz IPs und Namen im Heimnetz sind doch immer alle gleich. Welches IP netz dein VPN dann hat ist doch völlig Wumpe dann.

Das ist korrekt dass man mit Namen arbeiten kann.
Ich nutze aber immer noch sehr gerne IP-Adressen für Verbindungen. Das stammt aus der Zeit des Beginn der Heimnetzwerke in den 90ern. Da hat die Namensauflösung oft nicht funktioniert.
Es ist auch richtig dass die IP-Adressen im Heimnetz gleich bleiben. Allerdings möchte ich auch die Möglichkeit für den umgekehrten Weg haben, also der Zugriff aus dem Heimnetz auf einen Client der VPN verbunden ist.
Was würdest du hier vorschlagen? Mit Namen arbeiten, mit festen IP-Adressen?


Mit dem Layer 2 und damit TAP steckt auch dahinter dass ich an WoL denke. Hier habe ich im Kopf dass das auf Layer 2 arbeitet und eben Broadcast macht. Und dass WoL auf MAC-Adressen-Ebene tätig ist.
Geht WoL tatsächlich auch über Routing?

Nicht falsch verstehen, ich hänge nicht an Bridging. Ich bin nur bei der "Konzeption" des VPN, also was womit machbar ist und worauf ich verzichten muss wenn ich TUN nehme.
Routing ist für mich durchaus sympatisch da es hierfür jede Menge Clients für Android gibt face-smile
Und das geht auch ohne Root.
Mitglied: aqui
aqui 21.10.2019 um 12:11:17 Uhr
Goto Top
so viel ausmacht, das habe ich nicht gedacht.
Warum steckst du nichtmal einen Wireshark Sniffer in dein Netz ?? Dann hättest du nicht "denken" müssen, der zeigt dir das schwarz auf weiß !
Ich nutze aber immer noch sehr gerne IP-Adressen für Verbindungen.
Was ja auch nicht falsch ist sondern durchaus richtig ! Die Ziel IP Adressen im Heimnetz ändern sich ja auch nicht wenn du mit einem gerouteten VPN zugreifst.
also der Zugriff aus dem Heimnetz auf einen Client der VPN verbunden ist.
Tja, dann musst du dir natürlich ein anderes Netz merken. Was ja aber nicht wirklich schwer ist.
Wenn du z.B. 172.24.100.0 /24 im Heimnetz hast kann man sich sicher sehr leicht merken das 172.24.101.0 /24 sein Client VPN Netz ist. face-wink
Wenn man dann noch im OpenVPN diesen Clients auf Basis ihres OpenVPN Client Common Names immer eine feste IP Adresse zuweist, hast du sogar immer quasi fixe IP Adressen im VPN Netz. Das kann man sehr bequem gestalten.
Hier habe ich im Kopf dass das auf Layer 2 arbeitet und eben Broadcast macht.
Jein. Viele nutzen IP mit UDP Port 9 (Discard). Guckst du hier:
https://www.heise.de/ct/artikel/Wake-on-WAN-221718.html
Nicht falsch verstehen, ich hänge nicht an Bridging.
Nee, letztlich kannst du ja selber machen was du willst. Wenn du unbedingt partout bridgen willst, dann machst du das halt. Geht ja nur darum dich vor einer ggf. falöschen Entscheidung zu bewahren. face-wink
Und das geht auch ohne Root.
Klar, wenn man den offiziellen OVPN Client nimmt ist es ganz egal.
Noch sinnvoller ist natürlich immer der bordeigene Client wo man dann gar nix zusätzlich verwenden muss:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Mitglied: blacksun
blacksun 21.10.2019 aktualisiert um 13:16:24 Uhr
Goto Top
Zitat von @aqui:
Warum steckst du nichtmal einen Wireshark Sniffer in dein Netz ?? Dann hättest du nicht "denken" müssen, der zeigt dir das schwarz auf weiß !
Ich war nicht in der Verlegenheit das anschauen zu müssen face-smile
Aber du hast schon recht.

Tja, dann musst du dir natürlich ein anderes Netz merken. Was ja aber nicht wirklich schwer ist.
Wenn du z.B. 172.24.100.0 /24 im Heimnetz hast kann man sich sicher sehr leicht merken das 172.24.101.0 /24 sein Client VPN Netz ist. face-wink
Wenn man dann noch im OpenVPN diesen Clients auf Basis ihres OpenVPN Client Common Names immer eine feste IP Adresse zuweist, hast du sogar immer quasi fixe IP Adressen im VPN Netz. Das kann man sehr bequem gestalten.

ok, also am besten fixe Adressen.
dass der persistent-Schalter mit IP-Adressen dann nicht mehr funktioniert, damit muss ich dann leben.
Ist die Namensauflösung heutzutage noch ein Problem wenn ein Client per VPN rein kommt? Lasse ich den Namen an den PI mit dem OpenVPN-Server melden, oder doch an die Fritzbox als Router für das Heimnetz? Sprich wer sollte DNS-Server für die VPN-Clients sein?
Ich würde sagen die Fritzbox sollte der DNS für alle Clients sein, sprich mit PUSH die IP der Fritzbox an die Clients geben. Oder habe ich da einen Denkfehler?

Hier habe ich im Kopf dass das auf Layer 2 arbeitet und eben Broadcast macht.
Jein. Viele nutzen IP mit UDP Port 9 (Discard). Guckst du hier:
https://www.heise.de/ct/artikel/Wake-on-WAN-221718.html

Wenn also WoL heute tatsächlich auf Layer 3 gut funktioniert, dann gibt es tatsächlich nicht mehr die Notwendigkeit auf Bridging.

Nee, letztlich kannst du ja selber machen was du willst. Wenn du unbedingt partout bridgen willst, dann machst du das halt. Geht ja nur darum dich vor einer ggf. falöschen Entscheidung zu bewahren. face-wink
Richtig, genau das ist der Grund warum ich hier frage.
Vielen Dank daher für Deine Tipps.

Klar, wenn man den offiziellen OVPN Client nimmt ist es ganz egal.
Noch sinnvoller ist natürlich immer der bordeigene Client wo man dann gar nix zusätzlich verwenden muss:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

Absolut richtig, allerdings ist einer meiner Hauptgründe für OpenVPN die Nachteile, die PPTP und IPSec haben
https://www.shellfire.de/blog/pptp-vs-ipsec-vs-openvpn-sind-die-untersch ...
also Blockaden umgehen und den eigentlichen Traffic verstecken.

Nur aus Interesse nochmal zum Thema Bridge.
Da gibt es das erwähnte Problem mit dem Overhead. Siehst du beim Einsatz von Bridge auch Sicherheitsbedenken die man mit Routing nicht hat?
Man verbindet sich zunächst mit einem unsicheren Trägernetz, z.B. das Hotel-WLAN, und bleibt natürlich auch ständig mit diesem verbunden. Ist es kritisch dass sich auch andere im gleichen Netz tummeln?
Mitglied: aqui
aqui 21.10.2019 aktualisiert um 14:03:37 Uhr
Goto Top
ok, also am besten fixe Adressen.
Ja, sonst kannst du die VPN Client Endgeräte ja nicht addressieren bzw. musst immer nach der aktuellen IP fragen. Das gleiche Problem hast du aber auch beim Bridging !!
Da musst du ja auch sicherstellen das die VPN Clients feste IPs bekommen wenn du auf diese Clients zugreifen willst.
Oder eben Namen wenn du es fest in die hosts oder lmhosts Datei eintragen willst um auch Namen benutzen zu können.
Ist die Namensauflösung heutzutage noch ein Problem wenn ein Client per VPN rein kommt?
Kann man so nicht beantworten. Hängt davon ab was du DNS mässig so alles nutzt.
Der Klassiker ist es statisch einzutragen:
XP-Home mit 2 Kabelgebundenen und WLAN PCs
Du kannst aber auch einen privaten DNS betreiben. Der Klassiker ist z.B. einen Raspberry mit dem fertigen PiHole Image:
Raspberry Pi Zero W als Pi-hole Adblocker
Das schützt dich dann nebenbei auch noch gegen alles Böse wie Werbung, Malware, Trojaner Phising und Co.
Eigene IPs kann man da dann auch definieren:
https://discourse.pi-hole.net/t/howto-using-pi-hole-as-lan-dns-server/53 ...
Das wäre natürlich die "deluxe" Lösung face-wink
die Nachteile, die PPTP und IPSec haben
Na gut übber PPTP braucht man eh nicht mehr reden da:
https://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.h ...
Dazu kommt das fast alle Hersteller aus diesem Grunde keine PPTP Clients mehr an Board haben.
OVPN oder das neue WireGuard ist schon nicht verkehrt.
Die Sicherheit ist die gleiche bei Routing oder Bridging. Macht man da einen Fehler ist das gefährlich. Das ist dann völlig egal ob der Unterbau Layer 2 oder Layer 3 ist.
Ist es kritisch dass sich auch andere im gleichen Netz tummeln?
Generell erstmal ja, denn so hat jeder potentiell Zugriff auf deinen Rechner.
Es gibt da aber diverse Hürden
  • In der Regel konfigurierien die öffentlichen WLAN Betreiber ihre WLANs mit der Option Private LAN oder isolated LAN was dann per se auf den APs schon einen any zu any Kommunikation unterbindet (ARP Blocking). Verlassen kann man sich aber nicht darauf. Ob das so ist hängt dann vom KnowHow des Dienstleisteres ab der der HW aufstellt. Da gibt es (leider) gravierende Unterschiede. Sinnvoll ist immer mal einen Scanner wie iNet laufen zu lassen !! Sieht man andere gibts keine Client Isolation in dem Netz !
  • Die lokale Firewall ! Logischerweise ist das WLAN dann IMMER als öffentliches Netz deklariert wo die FW dann komplett alles eingehend dicht macht.
Für seine Sicherheit ist man immer selbst verantwortlich. Auch sollte man nicht unterwegs blindlinks in jedes WLAN klicken was "Frei" in der SSID verheisst. Da lauern die meisten Gefahren.
Guckst du hier:
Netzwerk Management Server mit Raspberry Pi
Sowas kann jedes pfiffige Kiddie heute mit einem 5 Euro Tool machen:
https://github.com/spacehuhn/esp8266_deauther
Wie immer zählt der gesunde Menschneverstand und gesundes Misstrauen...und eine wasserdichte Firewall.
Mitglied: blacksun
blacksun 21.10.2019 aktualisiert um 15:46:36 Uhr
Goto Top
Zitat von @aqui:

ok, also am besten fixe Adressen.
Ja, sonst kannst du die VPN Client Endgeräte ja nicht addressieren bzw. musst immer nach der aktuellen IP fragen. Das gleiche Problem hast du aber auch beim Bridging !!

jein
Ich meine bei Bridging ist es möglich dass man für VPN-Clients den gleichen IP-Adressraum nutzt wie für das Heimnetz, und dass der DHCP, DNS, was in Heimnetzen i.d.R. die Fritzbox, ist, diese Funktionen auch für die VPN-Clients bereitstellt. Je nach Lease-Time bleibt die Adresse der MAC zugeordnet.
Mir wurde gesagt dass das bei Routing nicht möglich ist (gleicher Adress-Bereich und heimischer DHCP auch für VPN-Clients nutzen)

Oder eben Namen wenn du es fest in die hosts oder lmhosts Datei eintragen willst um auch Namen benutzen zu können.
Der Klassiker ist es statisch einzutragen:
XP-Home mit 2 Kabelgebundenen und WLAN PCs

Ich stehe gerade auf dem Schlauch. Der Client, der heute im heimischen Netz ist und morgen sich per VPN verbindet, der hat heute eine IP aus dem Heimnetz, und morgen einen VPN-IP. Wie hilft mir da ein host-Eintrag?

Du kannst aber auch einen privaten DNS betreiben. Der Klassiker ist z.B. einen Raspberry mit dem fertigen PiHole Image:
Das wäre natürlich die "deluxe" Lösung face-wink

Das war auch auf meiner ToDoListe was auf den PI soll. Ich kannte PiHole bis dahin nur aus der Beschreibung, also als ein Adblocker der für das gesamte Heimnetz nutzbar ist.
Inzwischen bin ich doch etwas ernüchtert da der PI die Filterung lediglich per DNS macht, also nicht zu vergleichen mit einem Ublock Addon im Browser welches sich Inhalte anschaut, sich z.B. Skripte anschaut.

Ist es kritisch dass sich auch andere im gleichen Netz tummeln?
Generell erstmal ja, denn so hat jeder potentiell Zugriff auf deinen Rechner.
Es gibt da aber diverse Hürden
  • Die lokale Firewall ! Logischerweise ist das WLAN dann IMMER als öffentliches Netz deklariert wo die FW dann komplett alles eingehend dicht macht.

Eine DAU-Frage: face-wink
Tut es die Windows-eigene FW?

Ich schau heute Abend mal in diversen Tutorials was da alles in die Konfig-Files für den OpenVPN-Server und die Clients gepackt wird.
Ein Fragezeichen ist aber jetzt schon vorhanden.

In jedem Konfig-File steht "server" so dass der Server weiß dass das ein Konfig-File für den Serverteil ist. In fast allen Anleitungen wird dahinter die Adresse des Servers genannt wird. Die einen schreiben dort die feste IP den PI auf dem der OpenVPN-Server läuft, evtl. sogar mit Subnetzmaske, andere schreiben da den DDNS der auf die öffentliche IP zeigt.
Wird diese Eingabe technisch überhaupt genutzt? Ich meine der Server weiß doch wer er ist. Bzw. man konfiguriert doch meist dass Verbindungen von any angenommen werden.


Sowas kann jedes pfiffige Kiddie heute mit einem 5 Euro Tool machen:
Wie immer zählt der gesunde Menschneverstand und gesundes Misstrauen...und eine wasserdichte Firewall.
das sind interessante Links. Danke dafür.

Das mit der Gefahr in öffentlichen WLAN, das beschäftigt mich doch noch.
Mal angenommen, ein Angreifer und ich sind im selben öffentlichen WLAN, die Clients sehen sich da der Admin ein any zu any eingerichtet hat.
Und gehen wir mal davon aus dass keinerlei Firewall auf dem Client installiert ist.
Ich baue eine VPN-Verbindung auf. Sämtlicher Traffic von meinem Gerät fließt dann durch den Tunnel und ist nach aussen nicht sichtbar. Der Angreifer im WLAN kann aber trotzdem auf meinen Client losgehen da dieser im WLAN-Netz erreichbar ist.
Ein Laie würde sagen es braucht dann noch einen Dienst auf dem Client der etwas anbietet, und um diesen nutzen zu können, braucht der Angreifer entweder eine Sicherheitslücke, oder er benötigt die Daten für den Zugriff auf den Dienst.
Warum ist das so falsch?
Mitglied: aqui
aqui 21.10.2019 um 16:28:17 Uhr
Goto Top
Und gehen wir mal davon aus dass keinerlei Firewall auf dem Client installiert ist.
Dann lässt jedes normale Speilkind erstmal einen nmap auf deinen Rechner los. Dann mit Kali Linux den rest.
Mal im Ernst ohne aktive Firewall geht man niemals in ein öffentliches WLAN.
Der Angreifer im WLAN kann aber trotzdem auf meinen Client losgehen da dieser im WLAN-Netz erreichbar ist.
Ja, natürlich. Würde jeder sofort machen face-wink
Auch kannst du mit ARP Spoofing den VPN Datenstrom umleiten und mal versuchen ob man da nicht doch was lesen kann...
Ja der Angreifer braucht Crednetials, ne Lücke aber ein Winblows Rechner ist ja per se löchrig wie ein Käse... Ideal wenns es noch was altes ist.
Warum ist das so falsch?
Wenn man keine Firewall hat ? Oder wenn man keine Patches eingespielt hat ? Der Satz ist unverständlich ?!
Mitglied: blacksun
blacksun 21.10.2019 um 16:54:50 Uhr
Goto Top
Zitat von @aqui:
Und gehen wir mal davon aus dass keinerlei Firewall auf dem Client installiert ist.
Mal im Ernst ohne aktive Firewall geht man niemals in ein öffentliches WLAN.

richtig, aber das bedeutet dass man kein Smartphone unterwegs nutzen kann

Auch kannst du mit ARP Spoofing den VPN Datenstrom umleiten und mal versuchen ob man da nicht doch was lesen kann...
Ja der Angreifer braucht Crednetials, ne Lücke aber ein Winblows Rechner ist ja per se löchrig wie ein Käse... Ideal wenns es noch was altes ist.
Warum ist das so falsch?
Wenn man keine Firewall hat ? Oder wenn man keine Patches eingespielt hat ? Der Satz ist unverständlich ?!

du hast es im Satz davor beantwortet. Der Angreifer benötigt eine Lücke oder Zugangsdaten. Das habe ich gemeint. Auch wenn er einen offenen Port findet und dahinter sich der passende Dienst verbirgt, kommt er ohne Lücke oder Zugangsdaten noch nicht rein.


Kannst du noch was zu dem Thema Adressangabe in der Server-Konfig sagen? Wird die technisch benötigt?
Mitglied: Lochkartenstanzer
Lochkartenstanzer 21.10.2019 um 17:02:05 Uhr
Goto Top
Zitat von @blacksun:

Zitat von @aqui:
Und gehen wir mal davon aus dass keinerlei Firewall auf dem Client installiert ist.
Mal im Ernst ohne aktive Firewall geht man niemals in ein öffentliches WLAN.

richtig, aber das bedeutet dass man kein Smartphone unterwegs nutzen kann

Naja, die meisten Smartphones sind aber vom Hersteller soweit vorkonfiguriert, daß sie nicht gleich Gott und die Welt an Ihren Innereien teilhaben lassen, sondern nur Google, Apple und Microsoft. face-smile

lks
Mitglied: aqui
aqui 22.10.2019 um 12:16:07 Uhr
Goto Top
richtig, aber das bedeutet dass man kein Smartphone unterwegs nutzen kann
Wie kommst du darauf ??
Jedes Smartphone hat auch eine lokale Firewall, oder ist das an dir vorübergegangen.
Wäre ja fatal wenn nicht, denn auch im Provider Mobilfunknetz hängt das gesamte Internet am Smartphone. Lass mal einen Paket Sniffer dort laufen, dann siehst du wie die Angriffsversuche im 500mS Takt zuschlagen...
Mitglied: platoboos
platoboos 19.11.2019 um 14:11:34 Uhr
Goto Top
Moin,

ich versuche mich gerade daran meinen Pi als OpenVPN Server laufen zu lassen.
Ich möchte diesen gerne im Bridge Mode betreiben um meinen angemieteten VServer
mit Broadcast Daten zu versorgen. Hintergrund ist, ich möchte gerne TVHeadend auf meinem
VServer Sat Tuner zur Verfügung zu stellen.

Die Verbindung scheint zu bestehen aber die Tuner werden nicht angezeigt.
Ich bin nach dieser folgender Anleitung vorgegangen

https://www.toysdesk.com/2017/11/openvpn-bridge-mode-tap-with-raspberry- ...

Beim VServer habe ich die eine client.ovpn Datei in den Client Ordner kopiert und gestartet, hier die Anmeldung am PIVPN

/etc/openvpn/client# openvpn --config vserver.ovpn
Tue Nov 19 13:57:24 2019 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Tue Nov 19 13:57:24 2019 library versions: OpenSSL 1.1.1  11 Sep 2018, LZO 2.08
Tue Nov 19 13:57:24 2019 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key  
Tue Nov 19 13:57:24 2019 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication  
Tue Nov 19 13:57:24 2019 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key  
Tue Nov 19 13:57:24 2019 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication  
Tue Nov 19 13:57:24 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]77.20.164.230:1194
Tue Nov 19 13:57:24 2019 Socket Buffers: R=[212992->212992] S=[212992->212992]
Tue Nov 19 13:57:24 2019 UDP link local: (not bound)
Tue Nov 19 13:57:24 2019 UDP link remote: [AF_INET]77.20.164.230:1194
Tue Nov 19 13:57:24 2019 TLS: Initial packet from [AF_INET]77.20.164.230:1194, sid=04abb27d 897a3b85
Tue Nov 19 13:57:24 2019 VERIFY OK: depth=1, CN=ChangeMe
Tue Nov 19 13:57:24 2019 VERIFY KU OK
Tue Nov 19 13:57:24 2019 Validating certificate extended key usage
Tue Nov 19 13:57:24 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Tue Nov 19 13:57:24 2019 VERIFY EKU OK
Tue Nov 19 13:57:24 2019 VERIFY X509NAME OK: CN=openvpn_a3ef8ff6-f639-466d-9d28-97c31aac4636
Tue Nov 19 13:57:24 2019 VERIFY OK: depth=0, CN=openvpn_a3ef8ff6-f639-466d-9d28-97c31aac4636
Tue Nov 19 13:57:24 2019 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit EC, curve: prime256v1
Tue Nov 19 13:57:24 2019 [openvpn_a3ef8ff6-f639-466d-9d28-97c31aac4636] Peer Connection Initiated with [AF_INET]77.20.164.230:1194
Tue Nov 19 13:57:25 2019 SENT CONTROL [openvpn_a3ef8ff6-f639-466d-9d28-97c31aac4636]: 'PUSH_REQUEST' (status=1)  
Tue Nov 19 13:57:25 2019 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,block-outside-dns,redirect-gateway def1,route-gateway 10.8.0.1,ping 1800,ping-restart 3600,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'  
Tue Nov 19 13:57:25 2019 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:3: block-outside-dns (2.4.4)
Tue Nov 19 13:57:25 2019 OPTIONS IMPORT: timers and/or timeouts modified
Tue Nov 19 13:57:25 2019 OPTIONS IMPORT: --ifconfig/up options modified
Tue Nov 19 13:57:25 2019 OPTIONS IMPORT: route options modified
Tue Nov 19 13:57:25 2019 OPTIONS IMPORT: route-related options modified
Tue Nov 19 13:57:25 2019 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Nov 19 13:57:25 2019 OPTIONS IMPORT: peer-id set
Tue Nov 19 13:57:25 2019 OPTIONS IMPORT: adjusting link_mtu to 1656
Tue Nov 19 13:57:25 2019 OPTIONS IMPORT: data channel crypto options modified
Tue Nov 19 13:57:25 2019 Data Channel: using negotiated cipher 'AES-256-GCM'  
Tue Nov 19 13:57:25 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Tue Nov 19 13:57:25 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Tue Nov 19 13:57:25 2019 ROUTE_GATEWAY ON_LINK IFACE=venet0 HWADDR=00:00:00:00:00:00
Tue Nov 19 13:57:25 2019 TUN/TAP device tap0 opened
Tue Nov 19 13:57:25 2019 Note: Cannot set tx queue length on tap0: Operation not permitted (errno=1)
Tue Nov 19 13:57:25 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue Nov 19 13:57:25 2019 /sbin/ip link set dev tap0 up mtu 1500
Tue Nov 19 13:57:25 2019 /sbin/ip addr add dev tap0 10.8.0.2/24 broadcast 10.8.0.255
Tue Nov 19 13:57:25 2019 /sbin/ip route add 77.20.164.230/32 dev venet0
Tue Nov 19 13:57:25 2019 /sbin/ip route add 0.0.0.0/1 via 10.8.0.1
Tue Nov 19 13:57:26 2019 /sbin/ip route add 128.0.0.0/1 via 10.8.0.1
Tue Nov 19 13:57:26 2019 Initialization Sequence Completed

Beim PIVPN sieht es dann so aus

pi@openvpn:~ $ pivpn -c

: NOTE : The output below is NOT real-time!
:      : It may be off by a few minutes.

::: Client Status List :::
								Bytes		Bytes	
Name			Remote IP		Virtual IP	Received	Sent		Connected Since 
vserver		81.169.152.225:45272	10.8.0.2	3,5KiB		72KiB	Nov 19 2019 - 13:57:24

Aber wie gesagt die Tuner sind nicht zu sehen.

Hat Jemand eine Idee ?

Danke und Grüße
Mitglied: aqui
aqui 19.11.2019 aktualisiert um 14:45:12 Uhr
Goto Top
Die Verbindung scheint zu bestehen
Solcherlei Aussagen sind in der IT immer denkbar schlecht !! face-sad
Scheint es so oder ist es wirklich so ?? Das solltest du schon wasserdicht klären bevor wir hier in tiefere Troubleshooting Sessions gehen !
OVPN Bridging Infos auch hier:
https://openvpn.net/community-resources/ethernet-bridging/
Generell ist von Bridging abzuraten aber wenn du zwingend Broad- und Multicasts übertragen musst hast du keine andere Wahl.
Hilfreich dazu sind immer die VPN Log Dateien UND die OVPN Konfig beider Seiten.
Log haben wir. Solltest du oben IP technisch auch etwas anonymisieren sonst weiss jeder wo du Kunde bist face-wink.
Die anonymisierte Konfig dazu wäre noch hilfreich.
Ebenso das Verfahren WIE die Tuner sich automatisch bekannt machen im Netz ! Was nutzen die dafür ?? SSDP, UPnP, mDNS oder was auch immer ? Wireshark hilft dir hier im Zweifel immer.

Soweit sieht der Tunnelaufbau in Ordnung aus.
Es wäre schön gewesen wenn du uns nochmal mitgeteilt hättest ob ein Ping der Komponenten über den VPN Bridge Tunnel möglich ist. Das würde ja allen hier zeigen das der Bridge Tunnel wirklich rennt und aktiv ist !
Mitglied: platoboos
platoboos 19.11.2019 aktualisiert um 15:21:44 Uhr
Goto Top
Hier ist der Ping vom Pi zum VServer

pi@openvpn:~ $ ping 81.129....
PING 81.169... (81.169..) 56(84) bytes of data.
64 bytes from 81.169....: icmp_seq=1 ttl=52 time=36.1 ms
64 bytes from 81.169....: icmp_seq=2 ttl=52 time=37.6 ms
64 bytes from 81.169....: icmp_seq=3 ttl=52 time=33.7 ms
64 bytes from 81.169....: icmp_seq=4 ttl=52 time=35.1 ms
64 bytes from 81.169....: icmp_seq=5 ttl=52 time=33.9 ms

Server.conf

dev tap0
proto udp
port 1194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/openvpn_.crt
key /etc/openvpn/easy-rsa/pki/private/openvpn_.key
dh none
topology subnet
server 10.8.0.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 8.8.8.8"  
push "dhcp-option DNS 8.8.4.4"  
# Prevent DNS leaks on Windows
push "block-outside-dns"  
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"  
client-to-client
keepalive 1800 3600
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user nobody
group nogroup
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3

Client.conf

client
dev tun
proto udp
remote openv....dyn.dns 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
tls-version-min 1.2
verify-x509-name openvpn_ name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
<ca>
-----BEGIN CERTIFICATE-----

Ich kann dir leider nicht sagen wie die Tuner sich bekannt machen.
Ich bin auch nicht sooo Fit in Linux das vielleicht noch zur Info.
Mitglied: aqui
aqui 19.11.2019 aktualisiert um 16:23:44 Uhr
Goto Top
Das ist völlig klar das das nicht funktionieren kann, denn du routest ja !! Sieh dir deine Server Konfig an. Ohne jeden Zweifel ist das eine Routing Konfig ! Die ist perfekt richtig aber natürlich NICHT das was du willst.
Über die werden dann natürlich keinerlei Broad- und Multicasts übertragen, das ist logisch, da Router Prinzipien bedingt sowas nicht weiterreichen wie man als Netzwerker weiss.
Solchen fatalen Fehler kann man aber auch selber sehen wenn man sich die offizielle Bridge Konfig von OpenVPN mal ansieht:
https://openvpn.net/community-resources/ethernet-bridging/
https://www.bauser-enterprises.com/html/openvpn_pki.php
usw.
Das die fundamental anders aussieht als deine Routing Konfig sieht auch ein völliger Laie ! Da hast du aber mindestens 2 Tomaten auf den Augen gehabt... face-wink
Fazit:
Ändere die Konfig in eine Bridging Konfig, dann rennt das auch wie es soll !
Mitglied: platoboos
platoboos 21.11.2019 um 23:36:08 Uhr
Goto Top
Kannst du vielleicht nochmal drauf schauen ? Sollte jetzt passen oder ?

Thu Nov 21 23:30:42 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]77.......:1194
Thu Nov 21 23:30:42 2019 Socket Buffers: R=[212992->212992] S=[212992->212992]
Thu Nov 21 23:30:42 2019 UDP link local: (not bound)
Thu Nov 21 23:30:42 2019 UDP link remote: [AF_INET]77........:1194
Thu Nov 21 23:30:42 2019 TLS: Initial packet from [AF_INET]77........:1194, sid=4e9....5 6c.....
Thu Nov 21 23:30:42 2019 VERIFY OK: depth=1, C=DE, ST=NI, L=WL, O=PC, OU=VPN, CN=....., name=....., emailAddress=......@web.de
Thu Nov 21 23:30:42 2019 VERIFY KU OK
Thu Nov 21 23:30:42 2019 Validating certificate extended key usage
Thu Nov 21 23:30:42 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Nov 21 23:30:42 2019 VERIFY EKU OK
Thu Nov 21 23:30:42 2019 VERIFY OK: depth=0, C=DE, ST=NI, L=WL, O=PC, OU=VPN, CN=server, name=......., emailAddress=.....@web.de
Thu Nov 21 23:30:42 2019 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Thu Nov 21 23:30:42 2019 [server] Peer Connection Initiated with [AF_INET]77......:1194
Thu Nov 21 23:30:43 2019 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)  
Thu Nov 21 23:30:43 2019 PUSH: Received control message: 'PUSH_REPLY,route 192.168.178.1 255.255.255.0,route-gateway 192.168.178.25,ping 10,ping-restart 120,ifconfig 192.168.178.201 255.255.255.0,peer-id 1,cipher AES-256-GCM'  
Thu Nov 21 23:30:43 2019 OPTIONS IMPORT: timers and/or timeouts modified
Thu Nov 21 23:30:43 2019 OPTIONS IMPORT: --ifconfig/up options modified
Thu Nov 21 23:30:43 2019 OPTIONS IMPORT: route options modified
Thu Nov 21 23:30:43 2019 OPTIONS IMPORT: route-related options modified
Thu Nov 21 23:30:43 2019 OPTIONS IMPORT: peer-id set
Thu Nov 21 23:30:43 2019 OPTIONS IMPORT: adjusting link_mtu to 1656
Thu Nov 21 23:30:43 2019 OPTIONS IMPORT: data channel crypto options modified
Thu Nov 21 23:30:43 2019 Data Channel: using negotiated cipher 'AES-256-GCM'  
Thu Nov 21 23:30:43 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Thu Nov 21 23:30:43 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
Thu Nov 21 23:30:43 2019 Preserving previous TUN/TAP instance: tap0
Thu Nov 21 23:30:43 2019 Initialization Sequence Completed
Mitglied: aqui
aqui 22.11.2019 aktualisiert um 16:32:52 Uhr
Goto Top
Was immer noch komisch ist ist das dort Routen gepusht werden. Das zeigt wieder auf ein Routing Design und kein Bridging Design.
Spannend ist aber mal ein ifconfig von der Kiste bei aktivem Tunnel. Leider fehlte das face-sad
Dort MUSST du ja das LAN und das virtuelle OVPN Interface in einer Bridge sehen. Ohne Bridge ists wieder Routing.
https://ctaas.de/openvpn_bridging.htm
http://gesus.in-berlin.de/openvpn/
https://www.troublenow.org/362/howto-setup-openvpn-in-bridge-mode-on-deb ...
usw.
Du siehst dort immer das brctl Kommando was essentiell wichtig ist um das tap Interface mit dem LAN zu bridgen.