OpenVPN Traffic tunneln (Packet Squirrel mit Raspberry Pi)

Ein neuer Artikel wurde veröffentlicht
  • Hallo Leute,

    Also ich hab folgende Idee und zwar möchte ich den Packet Squirrel von Hak5 mit meinem Raspberry Pi "nachbauen" (https://www.hak5.org/gear/packet-squirrel).

    Mir geht es allerdings nicht um die Funktionen des Sniffens sondern darum das es mit diesem möglich ist allen Traffic, der über einen Anschluss läuft, über einen VPN zu leiten. Gute Anleitungen, dies als WLAN Router zu realisieren gibt es schon, allerdings möchte ich keine WLAN nutzen sondern der Ein-und Ausgang soll, genau wie beim Packet Squirrel, ein LAN Kabel sein.


    Die Weiterleitung des Traffics mit iptables sollte kein Problem darstellen wobei ich jetzt nicht weiß wie genau ich nun das weitere Interface (eth1) konfigurieren muss.

    Danke für eure Hilfe:)

    Der Waldie

  • Hallo Der Waldie,


    willkommen im Forum!


    Nun ja, ich habe ehrlich gesagt ein bisschen Bauchschmerzen dabei, Dir eine höfliche und zugleich deutliche Antwort zu schreiben.

    Die höfliche Seite in mir würde schreiben: Wende Dich bitte an den Verfasser der Anleitung, der wird Dir helfen können. :denker:

    Die deutliche Seite schreit: Bitte lass den Scheiß! :no_sad:


    In Anbetracht der Möglichkeiten die zur Verfügung ständen... Verstehst Du meinen Konflikt? :angel:

  • Moin DerWaldie,


    so ganz kann ich dein Vorhaben nicht verstehen.

    Wenn du jeden Verkehr via VPN schicken willst, dann mach das doch. Wozu braucht man dazu ein zusätzliches Gerät??


    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein "Like"

  • Nicht mit jedem Gerät ist es möglich, eine VPN Verbindung aufzubauen z.B. funktioniert es mit einem SmartTV ohne große Systemeingriffe bedingt, um nicht zu sagen überhaupt nicht.

  • Also alles was du aufsetzen mußt ist lokal ein Router (laut deinem Plan ist das dann dein RPi) und deine Geräte müssen halt so konfiguriert sein, daß sie ausschließlich mit diesem Router kommunizieren. Wohin - bzw. über welche Verbindung (also bspw. ein VPN mit dem jeweiligen tun-Gerät) - der Router die Pakete schickt entscheidet danach allein der Router. Klingt wie ein nettes (und vor allem recht simples) Projekt für einen RPi. Vielleicht kannst du mit den hier gewonnenen Informationen ja ein Tutorial draus stricken.


    Kannst du das nochmal etwas detaillierter beschreiben, bitte?


    Ich hab sowas schonmal vor Jahren in der Firma aufgesetzt um mit einer Partnerfirma zu verbinden. Da hatten wir dann auch DNS-Abfragen und allen Pipapo in beide Richtungen. Ich schau mal nach wie ich das damals gemacht habe. So wie ich das sehe ist DNS für dich ja irrelevant (also bei uns ging es ja um die Namensauflösung innerhalb der jeweiligen Intranetze), weshalb du eigentlich nur eine Handvoll iptables-Regeln in den Hookskripten unter /etc/network brauchst und eben eine aufgebaute OpenVPN-Verbindung.


    Ach ja nochmal kurz zu deiner Frage mit den Netzwerkschnittstellen. Im Prinzip brauchst du nichtmal zwei Schnittstellen, denn du willst ja nicht sniffen und gleichzeitig durchleiten. Wenn du eine VPN-Verbindung aufbaust, laufen die Daten darin ja über eine tun-Schnittstelle. Solange der Router bspw. weiß daß "interner" Verkehr immer von einem bestimmten Subnetz stammt, reicht dies als Unterscheidungsmerkmal. Mehrere Schnittstellen würden nur noch was bringen mit Bonding oder so. Aber die Schnittstelle des RPi ist sowieso schon nicht die schnellste, also erwarte mal nicht allzuviel Durchsatz.

    Wenn ihr schnell hilfreiche Antworten wollt, lest bitte diesen Artikel (Fehlerberichte - wie Sie Softwarefehler melden sollten) und beherzigt die darin enthaltenen Ratschläge. Herzlichen Dank!

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von Assarbad ()

  • Also, paß uff. Habe nochmal nachgeschaut, allerdings habe ich nur die von mir damals verfaßte Doku zur Hand und nicht die eigentlichen Konfigurationsdateien und Skripte, denn die sind der Zeit zum Opfer gefallen ;)


    Bei uns hatten wir das sogar so gelöst, daß die Clients welche auf das entfernte Netz zugreifen können sollten eben einfach die Route zu dem entfernten Subnetz über besagten von mir eingerichteten Router laufen ließen. Das ist sozusagen eine Untermenge dessen was du willst.


    Also nehmen wir mal ganz keck an, daß dein eigenes Subnetz in dem irgendein DHCP-Server die IPs verteilt 192.168.1.1/24 ist. Nehmen wir weiters an, daß alles was nicht aus diesem Subnetz kommt oder in dieses Subnetz geht über deinen VPN-Tunnel gehen soll.


    Das Skript hatte ich also als Hookskript seitens OpenVPN-Client (in deinem Fall der RPi) an jener einzigen Schnittstelle zu laufen die unser Gateway damals hatte (wie schon geschrieben, eine Schnittstelle sollte auch für dein Szenario reichen).


    Die Regeln stimmen übrigens vermutlich so noch nicht für deinen Zweck. Ich warte da mal lieber nochmal auf deine Beschreibung. Bei dir könnte es nicht allein aufs Maskieren hinauslaufen.


    Einerlei, die obigen Regeln kann man für alle (gewünschten) lokalen Schnittstellen laufenlassen, da die Regeln ja nicht schnittstellenspezifisch sind, sondern subnetzspezifisch. Sprich: sie dienen Dazu Pakete aus dem Intranet für's Internet zu maskieren und umgekehrt.


    Das obige Skript hatte ich als /etc/network/vpn-fw-rules abgelegt und aus den Unterordnern /etc/network/if-down.d und /etc/network/if-up.d verlinkt (Symlink) um sie jeweils auszuführen. Alternativ (man interfaces) kann man natürlich auch den Aufruf des Skripts auf die entsprechende up/down-Zeile in der /etc/network/interfaces (nochmal siehe Handbuch!) setzen, falls man statt allen Schnittstellen (außer Loopback) speziellere Anforderungen hat.

    Wenn ihr schnell hilfreiche Antworten wollt, lest bitte diesen Artikel (Fehlerberichte - wie Sie Softwarefehler melden sollten) und beherzigt die darin enthaltenen Ratschläge. Herzlichen Dank!

  • Moin DerWaldie,

    ich habe nicht geschrieben das du jedes Grät VPN lehren sollst. Ich meinte das du alles über den RPi an VPN schicken sollst.


    Nicht mehr und nicht weniger...


    Aber Asserbad hat ja eine Lösung aufgezeigt.


    Gruss Bernd


    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein "Like"

  • Abend allerseits,

    @Assarbad danke für die Mühe :)

    Also ein Versuch das genauer zu Erklären: Grob gesagt möchte ich das ich in die eine Schnittstelle (eth1) einen z.B. Laptop, SmartTV usw. per LAN anschließen kann, in die weitere Schnittstelle (eth0) wird dann das LAN Kabel, was sonst direkt an das Gerät geht, angeschlossen. Wichtig ist das es dabei möglichst nicht an das eine Netzwerk gekoppelt sein soll, sondern flexibel auch an anderen Orten (Netzwerken) ohne groß Problemen benutzt werden kann. Ich hatte einfach an einen DHCPD-Server auf eth1 und eine Weiterleitung des Traffics auf tun0 mit iptabels gedacht, wobei ich bei der Ausführung so meine Probleme habe, da ich nicht genau weiß wie ich das jetzt konkret (am besten) umsetzen kann.

  • Also die Regeln der Firewall kannst du ja statt an IPs auch an den Schnittstellen festmachen. So sollte sich das durchaus machen lassen.


    Ich verstehe jetzt aber eine Sache noch nicht. Oder besser gesagt, vielleicht kannst du das nochmal klarstellen.

    Grob gesagt möchte ich das ich in die eine Schnittstelle (eth1) einen z.B. Laptop, SmartTV usw. per LAN anschließen kann, in die weitere Schnittstelle (eth0) wird dann das LAN Kabel, was sonst direkt an das Gerät geht, angeschlossen.

    Okay, hier sollten wir also vielleicht mal eine Art Begriffstrennung vereinbaren. Verstehe ich dich richtig, daß an eth1 beispielsweise ein Switch oder ein anderes Gerät im Intranet angeschlossen werden soll und eth0 quasi die Verbindung ins Internet (also der Uplink) sein soll?


    Dann hättest du meinem Verständnis nach mit meinem obigen Beispiel und deiner bereits laufenden Lösung mit dem dhcpd schon den überwiegenden Weg hinter dir.

    Wichtig ist das es dabei möglichst nicht an das eine Netzwerk gekoppelt sein soll, sondern flexibel auch an anderen Orten (Netzwerken) ohne groß Problemen benutzt werden kann.

    Mit Netzwerk meinst du jetzt einfach nur das Subnetz, korrekt? Das wird wohl eher nicht gehen. Denn du mußt deinen dhcpd schon auf einen Adreßbereich festlegen. Also wenn wir mal folgenden Aufbau annehmen:


    Code
    1.                                               Intranet | Internet
    2. [Laptop]-----------\                                   |
    3.                     \                                  |
    4. [Smart-TV]--------------[Billigswitch]-------[RPi(eth1)|(eth0)]------[Dein DSL-Router]

    oder auch alternativ (Weglassung des Billigswitches in deinem internen Netzwerk):

    Code
    1.                  Intranet | Internet
    2. [Smart-TV]------[RPi(eth1)|(eth0)]------[Dein DSL-Router]

    ... dann mußt du zwangsläufig jenem Subnetz welches über eth1 geroutet wird einen bestimmten Adreßbereich zuweisen und diesen über den dhcpd bedienen. Die Schnittstelle eth0 ist zwar defacto auch in deinem Heimnetz (also von deinem DSL-Router oder Kabelmodem gesehen), aber einem anderen Subnetz. Das ist eigentlich auch die einzige Bedingung, daß das Subnetz auf der eth1- und der eth0-Seite sich unterscheiden. Zumindest würde es komplizierter, wenn der RPi vom DSL-Router an eth0 eine IP zugewiesen bekommt, die im Subnetz liegt welches der RPi selbst über eth1 aufspannt. Möglich sollte aber sogar das sein.


    Kurzum, für alle Geräte die direkt oder indirekt (über einen Switch) am eth1 deines RPi hängen, übernimmt der RPi im Prinzip die Rolle welche im Heimnetz normalerweise dem DSL-Router zukommt. Dafür mußt du schon ein Subnetz auf der eth1-Seite festlegen. Auf der eth0-Seite wärst du prinzipiell nicht festgelegt, hast aber dennoch das Problem, daß du nur entweder einen DHCP-Client laufenlassen kannst oder eben eine feste Adresse vorab festlegst um zum Uplink (also bspw. deinem DSL-Router) zu verbinden. Man könnte nun ggf. über Jumper an der GPIO-Leiste oder ähnliche Methoden eine gewisse Flexibilität einbauen die auch ohne Login auf dem RPi verfügbar ist.


    Nur um es nochmal klarzustellen. Je nach Uplink-Geschwindigkeit, aber auch nach der Geschwindigkeit die du eth1-seitig als Durchsatz erreichen möchtest, dürfte der RPi aufgrund seiner recht langsamen eingebauten Ethernetschnittstelle (100 Mbps) nicht unbedingt das geeignetste Gerät für dein Projekt sein. Es ist also durchaus prinzipiell machbar, erfüllt aber möglicherweise am Ende nicht alle deine Anforderungen. Aufgrund der USB-Beschränkungen dürftest du auch bei Benutzung einer Gigabit-"Karte" auf Datenraten von nicht viel mehr als 300 Mbps kommen.


    Für Spielereien wie diese, sollte man lieber eine Hardware benutzen die den Anforderungen von 1 Gbps gewachsen ist. Also bspw. einen Asus RT-N66U oder Nachfolgemodelle. Wenn es aber um geringen Platzbedarf geht und die obigen Einschränkungen nicht stören, wäre ein Carambola 2 dem RPi für den gewünschten Einsatzzweck noch immer überlegen. Dort hättest du auch gleich zwei Ethernetports eingebaut, wenngleich auch diese auf 100 Mbps beschränkt sind. WiFi ist auch drauf. Ansonsten kannst du dich auf dem OpenWRT-Wiki nach geeigneten Geräten umschauen. Wie geschrieben, wenn die Geschwindigkeitsbegrenzung nicht stört, kannst du das allemal mit dem RPi verwirklichen. Und wenn es nur ums Lernen geht, sowieso.


    Das Prinzip vom Yoggie (Yoggie Open Firewall SOHO) war noch schnuckeliger, weil sich der Yoggie am jeweiligen Gerät als USB-Ethernetadapter angemeldet hat (leider auch 100 Mbps) und dann aller Netzverkehr über den Yoggie geleitet wurde (Dank Routingtabelle die durch den dhcpd auf dem Yoggie entsprechend gesetzt war), ohne daß das Gerät an welches man den Yoggie steckte irgendeine Änderung seiner Netzwerkkonfiguration durchführen mußte. Also eine Hardwarefirewall (die Yoggies wurden vom USB-Port gespeist) welche ohne eigene Ethernetports auskam. Die Hardware der Yoggies war meines Wissens mit der ersten Generation der Carambolas vergleichbar.

    Wenn ihr schnell hilfreiche Antworten wollt, lest bitte diesen Artikel (Fehlerberichte - wie Sie Softwarefehler melden sollten) und beherzigt die darin enthaltenen Ratschläge. Herzlichen Dank!