Gäste-Wlan mit Raspberry Pi erstellen, ohne Zugriff auf das Heimnetz zu gewähren.

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Gäste-Wlan mit Raspberry Pi erstellen, ohne Zugriff auf das Heimnetz zu gewähren.

    Das Szenario:

    Ich betreibe ein Heimnetzwerk mit dem IP-Adressraum 192.168.2.0-255. Die Adresse 192.168.2.1 gehört dem Router (ja, ein Speedport - W 724V Typ A um genau zu sein..). Daneben habe ich noch 2 AP‘s, die TK-Anlage, das NAS und den Netzwerkdrucker mit fortlaufenden festen IP-Adressen ausgestattet (192.168.2.2, ...2.3, usw.) . Die restlichen Geräte wie Chromecast, Computer, Smartphones etc. landen per DHCP im Adressbereich 192.168.2.100-199

    Da der Speedport keinen Gastzugang für Freunde und Familie bereitstellt - es sei denn, sie können WLAN TO GO nutzen - habe ich meinen Raspberry Pi 3, Modell B, 1GB RAM nach dieser Anleitung als Access Point eingerichtet. Der Raspi hat im Heimnetz die feste IP 192.168.2.10 auf eth0. Das Gastnetz über wlan0 wird über den Adressbereich 192.168.10.x realisiert, wobei wlan0 selbst die IP 192.168.10.1 bekommen hat, DHCP wurde von ...10.100 bis ...10.120 eingerichtet.

    Das Ganze funktioniert, hat aber einen Schönheitsfehler: Die Gäste können sich mit allen Geräten im Heimnetz verbinden, also mit dem Chromecast, dem NAS, der TK-Anlage usw.

    Das Ziel:

    Die Gäste sollen weiterhin ins Internet können, aber sie sollen nicht auf die Geräte in meinem Heimnetz Zugriff bekommen.

    Die Idee:

    Iptables auf dem Raspi so konfigurieren, dass es im PREROUTING auf wlan0 alle Pakete verwirft, die auf den Adressbereich 192.168.2.x anfragen. Natürlich soll das nur die Netzwerkschnittstelle wlan0 betreffen, nicht eth0., denn der Raspi selbst soll schon ins eigene Netz können. Das habe ich so realisieren können:

    Code
    sudo iptables -A PREROUTING \-t mangle -i wlan0 -m iprange --dst-range 192.168.2.0-192.168.2.255 -j DROP

    Soweit funktioniert das Ganze ja auch, doch…

    Das Problem:

    ..der konzeptionelle Ansatz ist falsch! Besser wäre es, alles zu verbieten und nur die Ausnahmen zuzulassen, die zwingend erforderlich sind. Aber Iptables ist nun mal wirklich hohes Kung-Fu und ich weiß nicht, wie ich das hinkriegen soll.

    Die Frage:

    Kann sich das mal bitte jemand ansehen, der mehr Ahnung hat? Danke für Eure Hilfe und/oder konstruktive Kritik! :thumbup:

    Gruß Jan

    PS: Bitte nicht OT!

    „Kauf Dir eine Fritz!Box.“ Danke, aber ich brauche keine Kaufberatung. Ich weiß, dass es andere Geräte gibt, die genau das, was ich suche, einrichten könnten. Aber ich hab nun mal kein anderes Gerät. Und ich möchte auch kein Neues kaufen.

    „Wenn du deinen Freunden nicht traust, lass sie nicht in dein Netzwerk.“ Danke, aber ich brauche keine Lebensberatung. Ich traue meinen Freunden, aber nicht uneingeschränkt ihren Smartphones oder Tablets. Außerdem muss es nicht immer ein Exploit sein, der lauert. Wenn plötzlich ohne erkennbaren Grund der Fernseher anspringt und ein Typ namens Logo etwas über Minecraft erzählt, weil die Freundin meiner Tochter auf ihrem Smartphone das Cast-Symbol angetippt hat, ist das zwar recht amüsant, aber irgendwie auch befremdlich. Das hat nichts damit zu tun, dass ich dem Mädel nicht traue. Ich will nur einfach nicht, dass sie das kann und fertig.

    „Denk an die Störerhaftung respektive sonstige rechtliche Fallstricke!“ Danke, aber ich brauche keine Rechtsberatung. Ich möchte nur einen Weg finden, wie ich meinen Freunden ein Gastnetz-Wlan aufspannen kann, ohne dass sie Zugriff auf mein Netzwerk bekommen.

  • Gäste-Wlan mit Raspberry Pi erstellen, ohne Zugriff auf das Heimnetz zu gewähren.? Schau mal ob du hier fündig wirst!

  • Hallo Jan.

    Schöner Beitrag. Aus Erfahrung kann ich dir sagen dass OT ziemlich sicher kommen wird. Egal was du machst, einige wollen immer schreiben. Aktuell bin ich unterwegs und habe kein Pi zur Hand wo ich deine Situation nachbauen kann. Doch fürs erste hätte ich ein Link der aus meiner Sicht die Sache einfach erklärt: https://hosting.1und1.de/digitalguide/s…kete-erstellen/

    Wenn du noch mehr Hilfe benötigst, melde dich einfach noch einmal.

    Gruss Dani

    Einmal editiert, zuletzt von Linus (22. September 2018 um 17:19)

  • Sollen die Systeme, die sich im Gastnetz befinden, überhaupt nicht in das "Hauptnetz"?

    Oder sollen vielleicht einige, besonders berechtigte Systeme, doch in das "Hauptnetz"?

    Im ersten Fall sollte es ausreichen, das "WAN" des PI, also das Interface, das im Hauptnetz steht, so einzurichten, dass es nur einen anderen Punkt in dem Netz kennt:

    Den Speedport und seine IP.

    Dazu musst du auf dem PI ein "Host-Routing" einrichten, damit das Netz des Speedport für den PI entsprechend bekannt ist.

    Das ganze wird einfacher, wenn du dem PI im Hauptnetz nicht die 192.168.2.10, sondern die IP 192.168.2.2 gibst.

    Dazu kennt der PI dann nur das Netz 192.168.2.0/30.

    Die WAN-IP des PI nicht per DHCP zuweisen, sondern am eth0 des PI fest einstellen (Ja, man könnte dem PI das Netz 192.168.2.0/28 geben, dann würden er IP über *.15 auch nicht kennen.

    Computer ..... grrrrrr

  • Gäste-Wlan mit Raspberry Pi erstellen, ohne Zugriff auf das Heimnetz zu gewähren.

    Das Szenario:

    Ich betreibe ein Heimnetzwerk mit dem IP-Adressraum 192.168.2.0-255. Die Adresse 192.168.2.1 gehört dem Router (ja, ein Speedport - W 724V Typ A um genau zu sein..). Daneben habe ich noch 2 AP‘s, die TK-Anlage, das NAS und den Netzwerkdrucker mit fortlaufenden festen IP-Adressen ausgestattet (192.168.2.2, ...2.3, usw.) . Die restlichen Geräte wie Chromecast, Computer, Smartphones etc. landen per DHCP im Adressbereich 192.168.2.100-199

    Code
    sudo iptables -A PREROUTING \-t mangle -i wlan0 -m iprange --dst-range 192.168.2.0-192.168.2.255 -j DROP

    ..der konzeptionelle Ansatz ist falsch! Besser wäre es, alles zu verbieten und nur die Ausnahmen zuzulassen, die zwingend erforderlich sind. Aber Iptables ist nun mal wirklich hohes Kung-Fu und ich weiß nicht, wie ich das hinkriegen soll.

    Ich weiss noch nicht, ob der konzeptionelle Ansatz falsch ist... ich empfinde nur die Perspektive auf das Problem etwas irritierend.

    Wenn ich das richtig sehe, hast Du 2 Netze:

    192.168.2/24 ist das Heimnetz

    192.168.10/24 ist das Gastnetz

    Und alle Clients aus dem Gastnetz sollen nicht das Heimnetz erreichen dürfen. Ich würds auf diesem Weg versuchen.... und hinterher den Effekt sorgfältig prüfen:

    iptables -t raw -A PREROUTING -s 192.168.10/24  -d 192.168.2/24  -j DROP

    RAW filtert zu einem Zeitpunkt, bevor das Paket überhaupt den Paketfilter richtig erreicht hat... noch früher geht nicht.

    Code
    # iptables -t raw -L -nv
    Chain PREROUTING (policy ACCEPT 22 packets, 4226 bytes)
    pkts bytes target     prot opt in     out     source               destination
    0     0    DROP       all  --  *      *       192.168.10.0/24      192.168.2/24
  • dll-live Danke, ich werde mir den Link mal in Ruhe durchlesen. Leider hattest Du mit Deiner Prophezeiung bezüglich OT recht..

    dreamshader doing Danke, aber ich brauche wirklich und ganz ehrlich keine Lebensberatung.

    Rasp-Berlin Die Clients im Gastnetz 192.168.10.x (wlan0) sollen gar kein Zugriff auf das Heimnetz bekommen, der Raspi selbst (eth0, 192.168.2.10) aber schon. Wenn ich den Raspi so konfiguriere, dass er nur den Router kennt (192.168.2.1) kennt er nur noch einen kleinen, aber wichtigen Teil des Heimnetzes (nämlich den Router) aber sonst nix anderes. Das hier hab ich nicht ganz verstanden, kannst Du das bitte näher erläutern?

    Zitat

    Dazu musst du auf dem PI ein "Host-Routing" einrichten, damit das Netz des Speedport für den PI entsprechend bekannt ist.Das ganze wird einfacher, wenn du dem PI im Hauptnetz nicht die 192.168.2.10, sondern die IP 192.168.2.2 gibst.

    Dazu kennt der PI dann nur das Netz 192.168.2.0/30.

    Die WAN-IP des PI nicht per DHCP zuweisen, sondern am eth0 des PI fest einstellen (Ja, man könnte dem PI das Netz 192.168.2.0/28 geben, dann würden er IP über *.15 auch nicht kennen.

    Was macht es für einen Unterschied, welche IP der Raspi bekommt? Er hat jetzt fest die IP 192.168.2.10.

    @ThomasL Ja, richtig, es sind 2 Netze. 192.168.2.x ist das Heimnetz, 192.168.10.x das Gastnetz. Warum findest Du die Perspektive auf das Problem irritierend (vielleicht mach ich einen Denkfehler..?!) Dein Ansatz ist auf jeden Fall gut!

    iptables -t raw -A PREROUTING -s 192.168.10/24  -d 192.168.2/24  -j DROP

    Code
    # iptables -t raw -L -nv
    Chain PREROUTING (policy ACCEPT 22 packets, 4226 bytes)
    pkts bytes target     prot opt in     out     source               destination
    0     0    DROP       all  --  *      *       192.168.10.0/24      192.168.2/24

    Wenn ich das richtig verstehe, dropt iptabels hier alle Pakete, die von 192.168.10.x kommen (-s) und 192.168.2.x (-d) als Ziel haben. Aber kommen dann überhaupt Pakete durch? 192.168.10.x als source ist ja gesperrt.. Oder gilt die Regel nur dann, wenn alle Bedingungen erfüllt sind (also von 192.168.10.x als source und 192.168.2.x als destination)?

    Vielen Dank, Jan

    • Offizieller Beitrag

    Och nö, echt? Jetzt auch noch die Moderatoren..?! Hmm, dann bin ich wohl im falschen Forum.

    Ich bin nur ein Moderator von mehreren und ja, ich habe meine eigene Meinung, die anderen Jungs haben evtl. eine andere Meinung... Drauf geschi**en, soll ich wirklich auf Deinen Beitrag antworten? :elektro:

  • Ich bin nur ein Moderator von mehreren und ja, ich habe meine eigene Meinung, die anderen Jungs haben evtl. eine andere Meinung... Drauf geschi**en, soll ich wirklich auf Deine Betrag antworten? :elektro:

    hyle Danke, aber ich brauche wirklich und ganz ehrlich keine Kaufberatung. Ich hab keine Fritz!Box und ich beabsichtige auch nicht, mir eine zu kaufen. Und ich dachte eigentlich, ich wäre hier im Raspberry Pi-Forum.. Also wenn Du was zum Thema zu sagen hast: Gerne! Wenn nicht, dann nicht.

  • a, richtig, es sind 2 Netze. 192.168.2.x ist das Heimnetz, 192.168.10.x das Gastnetz. Warum findest Du die Perspektive auf das Problem irritierend (vielleicht mach ich einen Denkfehler..?!)

    Nein, kein Denkfehler... die Art der Beschreibung macht es nur unnötig kompliziert... weil es eben aus einer bestimmten Perspektive heraus erfolgt. Das macht aber nix und ist auch nicht das Problem... sondern allenfalls irritierend. Du musst bei IP-Adressen zwischen Netzwerk-Anteil und Client-Anteil unterscheiden... soll heissen, eine IP-Adresse besteht immer aus 2 Teilen. Dieses Anhängsel "x" oder die Erwähnung (weiter oben) von 100-199 oder 100-120 hat mit den Netzen gar nichts zu tun, das sind nur die Clients innerhalb des Netzes.

    Das sind die Netzwerke: 192.168.2/24 und 192.168.10/24 .... ohne "X" und ohne Client-Teil. Der Client-Teil ist für die Kontrolle des Verkehrs innerhalb des Netzes erst mal irrelevant. Der Client-Teil bestimmt nur einen Empfänger innerhalb des Netzes, aber das interessiert hier nicht.

    Wenn ich das richtig verstehe, dropt iptabels hier alle Pakete, die von 192.168.10.x kommen (-s) und 192.168.2.x (-d) als Ziel haben. Aber kommen dann überhaupt Pakete durch? 192.168.10.x als source ist ja gesperrt.. Oder gilt die Regel nur dann, wenn alle Bedingungen erfüllt sind (also von 192.168.10.x als source und 192.168.2.x als destination)?

    "Wenn ich das richtig verstehe, dropt iptabels hier alle Pakete, die vom Netz 192.168.10/24 kommen (-s) und das Netz 192.168.2/24 (-d) als Ziel haben."

    Ja, so ist es. Und wenn das Ziel eines TCP-Paketes dieses Forum ist, dann hat das Paket die Zieladresse 87.230.104.104 des Netzes 87.230.104/24. Und weil in Deinem Netz 192.168.2/24 das Netzwerk 87.230.104/24 unbekannt ist, geht das TCP-Paket einfach an das Default-Gateway... das ist nämlich der Sinn und Zweck eines Default-GWs.... was eigentlich Dein DSLRouter erfüllen müsste. Also eigentlich sollte es damit funktionieren. Was vielleicht noch ein Problem darstellen könnte, wäre eine fehlende Namensauflösung, das heisst, der DSL-Router sollte den DNS-Server Deines Providers anbieten. Muss man aber einfach testen, was geht, was nicht geht und dann entsprechend darauf reagieren.

    Einmal editiert, zuletzt von WinterUnit16246 (23. September 2018 um 11:05)

  • @ThomasL Herzlichen Dank für Deine Hilfe und sorry wegen der umständlichen Beschreibung! :)Zum Glück ist Dir mein Anliegen ja doch noch klar geworden. Soweit ich es getestet habe, funktioniert es mit Deinem Vorschlag.

    Aber noch mal zur Konzeption: ich würde es besser finden, primär alle Anfragen aus dem Netz 192.168.10/24 zu verbieten und dann nur die notwendigsten Ausnahmen zuzulassen. Aber wie?

    Im Moment mache ich das ja genau anders herum: Pakete aus dem Netz 192.168.10/24 dürfen überall hin, nur nicht in das Netz 192.168.2/24. Klar, das war das Hauptanliegen, aber könnten Pakete z.B. auch an 192.168.10.1 (wlan0 des Raspi) gesendet werden und dort Dienste zum Administrieren des Raspi erreichen? Das wäre unschön.. verzwickte Lage.:conf: Vielleicht könnte man das hinbekommen, wenn man nur bestimmte Ports (80,8080, usw.) freigibt..?

    dll-live  Rasp-Berlin Danke auch Euch nochmal für die Gedanken und Anregungen zum Thema.

    Gruß, Jan

    2 Mal editiert, zuletzt von JanHJT (24. September 2018 um 00:39) aus folgendem Grund: Gedanken zur Konzeption eingefügt.

  • 192.168.10/24 dürfen überall hin, nur nicht in das Netz 192.168.2/24. Klar, das war das Hauptanliegen, aber könnten Pakete z.B. auch an 192.168.10.1 (wlan0 des Raspi) gesendet werden und dort Dienste zum Administrieren des Raspi erreichen? Das wäre unschön.. verzwickte Lage.:conf: Vielleicht könnte man das hinbekommen, wenn man nur bestimmte Ports (80,8080, usw.) freigibt..?

    Ja klar....natürlich erreichen Pakete auch den Pi... das liegt ja in der Natur der Sache... AccessPoint und Clients befinden sich nun mal im gleichen Netz. Das gleiche Problem hat ja genauso jede andere exponierte Hardware. Das Problem dabei sind unzureichend gesicherte Dienste oder unnötige Dienste.

    Vielleicht hilft dir dieser Link weiter ...in dem ich mich mit Firewalls und deren Rahmenbedingungen befasst habe:

    Die Firewall - was sie ist, oder besser: was ist sie nicht

  • Du wirst lachen, im Rahmen meiner Recherchen bin ich gerade über diesen Link gestolpert und so hier im Forum gelandet. Deshalb bereitet mir ja auch das Konzept "Alles ist erlaubt, nur der Zugriff aufs Heimnetz nicht" so Bauchweh, denn:

    Zitat

    Und die einfachste Lösung ist, erst mal alles zu verbieten und dann sukzessive nur das zu erlauben, was wirklich gebraucht wird.

    Also, ich find es trotzdem recht kompliziert.. Aber naja, ich werde mich da schon reinfuchsen und für den Anfang tut es auch die o.g. Methode.;)

    Von mir aus kann das Thema als gelöst geschlossen werden

    Gruß und erneut vielen Dank, Jan

  • "Alles ist erlaubt, nur der Zugriff aufs Heimnetz nicht" so Bauchweh, denn:

    Das ist u.a. auch das, was ich mit komplizierter Perspektive meine ....;)... denn es ist genau anders herum. Mein obiges iptables-Statement entspricht ganz genau der Direktive "es ist grundsätzlich alles im LAN verboten". Man könnte jetzt noch umständlich eine "ausdrückliche erblaubnis" fürs Internet formulieren, aber das ist Quatsch, weil das Internet sowieso als einziges noch übrig geblieben ist, was funktioniert.

    "Alles ist erlaubt, nur der der Zugiff aufs Heimnetz nicht" ist jedenfalls nicht die korrekte Interpretation des iptables-Statements.

    "Der Zugriff aufs Heimnetz ist vollständig verboten" ist die korrekte Interpretation... und da bleibt halt nur das Internet als Erlaubt übrig. Und das was nach dem Verbot als Erlaubt übrig geblieben ist, braucht nicht auch noch eine ausgesprochene Erlaubnis.

    Also, ich find es trotzdem recht kompliziert

    Richtig... aber Dir sollte bewusst sein, wenn es Dir zu kompliziert ist, entscheidest Du am Ende vielleicht nicht allein darüber, wer Deine Hardware verwendet und was er damit tut.... das ist leider die dunkle Seite der Medaille.

    Von mir aus kann das Thema als gelöst geschlossen werden

    Das musst Du selber machen.....

    Viel Erfolg bei Deinem Vorhaben.

    Einmal editiert, zuletzt von WinterUnit16246 (24. September 2018 um 19:54)

  • Ja stimmt, ich hab da eine andere Perspektive. ;)

    Eins ist klar: Ich muss nun mal einen Dienst anbieten, sonst komm ich auf den Raspi nicht drauf. Aber dieser Dienst darf nur aus dem Netz 192.168.2/24 erreichbar sein, nicht aus dem Gastnetz. Wenn ich daneben keine weiteren Dienste mehr anbiete, müsste ich - Deiner Logik folgend - nichts weiter tun. Sonstige Dienste sind nicht erreichbar, weil nicht vorhanden, also muss ich sie auch nicht explizit sperren. Ich nehme mal das als Ausgangspunkt und schaue, wo ich anlande:

    Code
    sudo iptables -A INPUT -i wlan0 -p tcp --dport 22 -j DROP

    Gruß, Jan :danke_ATDE:

    2 Mal editiert, zuletzt von JanHJT (25. September 2018 um 20:44) aus folgendem Grund: typo

  • Das funktioniert so nicht, weil du damit aus gar keinem Netz mehr SSH-Zugriff hast. Dann wär's ja fast besser, SSH ganz zu stoppen, das spart dann das gehampel mit dem PaketFilter.

    Ich würde -unabhängig vom NIC- traffic auf Port 22 nur vom Netz 192.168.2/24 erlauben und den Rest droppen... und gut isses . Das geht einfach und ist effektiv.

  • Ja., ich weiss, Du hast Recht. Ich hatte diese Regel auf meine Ansprüche projiziert... sorry, das war der Fehler... pauschal Port 22 für WLAN zu blocken macht natürlich dann auch genau das. BTW... noch ein Rat am Rande... ich empfehle Dir, den Password-Login für SSH zu deaktivieren und den Login auf Authentifizierung mit Schlüsselpaaren (Pub-Key) einzurichten. Das spart dann sogar diese Filterregel. Und sofern keine Jobs einen automatischen root-Login durchführen sollen, würde ich unbedingt auch den root-Login deaktivieren.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!