7
Multicast und Unicast per open VPN sicher tunneln
Hallo zusammen,
ich beabsichtige eine VPN per Open VPN einzurichten. Getunnelt werden soll hauptsächlich multicast - unicast soll allerdings bei Gelegenheit auch durchgehen.
Nach einigem Lesen kam ich auf das wohl etwas veraltete Protokoll GRE, welches wohl auf pptp basiert (?) und nur mit der 128bit Verschlüsselung und preshared-Key arbeiten kann. IpSec mit Zertifikaten und 256 Bit Verschlüsselung wäre mir deutlich sympathischer, unterstützt aber kein multicast. Zudem kommt ja pptp glaube auch aus dem Hause Microsoft. Ein weiterer Minuspunkt also - zumindest für mich als Linux-Fetischist. :P
Daher ergibt sich die erste Frage: wie ließe sich durch openvpn eine auf GRE basierende VPN erstellen, die Ihrerseits in einem zu den oben beschriebenen Bedingungen durch einen IpSec Tunnel geleitet werden soll. Quasi also eine doppelte Ummantelung. Ist das so möglich? Gibt's da attraktive Alternativen?
Der open VPN-Server soll auf einem Mini-PC linuxbasiert zum laufen gebracht werden. Da ich bisher noch nicht mit open VPN gearbeitet habe gleich zur zweiten Frage:
2.1. welcher Rechenaufwand ist zu erwarten? Ließen sich bei entsprechendem Upstream 40 Mbit realisieren?
2.2. Hab ich es richtig verstanden, dass ich an der Gegenstelle am besten auch einen entsprechenden Mini-PC inklusive Client aufsetzen sollte, über den sich die entsprechenden Netzwerkgeräte über die VPN verbinden können? In meinem Szenario sind Netzwerkgeräte enthalten, auf denen sich kein VPN-Client installieren lässt. Wie ließe sich das am.besten umsetzen?
Das wäre es glaube ich für's erste. Vielen Dank euch schon mal.
ich beabsichtige eine VPN per Open VPN einzurichten. Getunnelt werden soll hauptsächlich multicast - unicast soll allerdings bei Gelegenheit auch durchgehen.
Nach einigem Lesen kam ich auf das wohl etwas veraltete Protokoll GRE, welches wohl auf pptp basiert (?) und nur mit der 128bit Verschlüsselung und preshared-Key arbeiten kann. IpSec mit Zertifikaten und 256 Bit Verschlüsselung wäre mir deutlich sympathischer, unterstützt aber kein multicast. Zudem kommt ja pptp glaube auch aus dem Hause Microsoft. Ein weiterer Minuspunkt also - zumindest für mich als Linux-Fetischist. :P
Daher ergibt sich die erste Frage: wie ließe sich durch openvpn eine auf GRE basierende VPN erstellen, die Ihrerseits in einem zu den oben beschriebenen Bedingungen durch einen IpSec Tunnel geleitet werden soll. Quasi also eine doppelte Ummantelung. Ist das so möglich? Gibt's da attraktive Alternativen?
Der open VPN-Server soll auf einem Mini-PC linuxbasiert zum laufen gebracht werden. Da ich bisher noch nicht mit open VPN gearbeitet habe gleich zur zweiten Frage:
2.1. welcher Rechenaufwand ist zu erwarten? Ließen sich bei entsprechendem Upstream 40 Mbit realisieren?
2.2. Hab ich es richtig verstanden, dass ich an der Gegenstelle am besten auch einen entsprechenden Mini-PC inklusive Client aufsetzen sollte, über den sich die entsprechenden Netzwerkgeräte über die VPN verbinden können? In meinem Szenario sind Netzwerkgeräte enthalten, auf denen sich kein VPN-Client installieren lässt. Wie ließe sich das am.besten umsetzen?
Das wäre es glaube ich für's erste. Vielen Dank euch schon mal.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 378650
Url: https://administrator.de/contentid/378650
Ausgedruckt am: 05.11.2024 um 16:11 Uhr
7 Kommentare
Neuester Kommentar
Nach einigem Lesen kam ich auf das wohl etwas veraltete Protokoll GRE, welches wohl auf pptp basiert (?) und nur mit der 128bit Verschlüsselung und preshared-Key arbeiten kann.
Bitte weiterlesen. z,B https://de.wikipedia.org/wiki/Generic_Routing_Encapsulation als einstieg.
Alt ist relativ, TCP ist viel älter aber wirklich überall im Einsatz ein ende ist da nicht in Sicht...
GRE is ein Tunnel Protokoll um alles mögliche von A nach B bringen auch Multicast.
Das hat mit Verschlüsselung erstmal nichts zu tun noch ist sie dafür Notwendig (aber sinnvoll)
Gibt's da attraktive Alternativen?
Ob Ipsec, SSL, SSH oder meinetwegen eine OnePad Datenstream Verschlüsselung ist deinemGeschmack überlassen.
Moin,
so wie es sich liest möchtest du einen TV-Kanal zuhause via Internet gucken können. Falls es das ist würde ich mir was anderes überlegen - z.B. via VLC den Stream lokal abgreifen und dann (ggf. mit nem anderem Codec) per Unicast zum Ziel jagen.
Hintergrund: Multicast hilft dir hier nicht. Das ist im lokalen Netzwerk schön - du hast 1 Sender, der sendet an den Switch und der transportiert das dann an jeden Client der nen Join gemacht hat. Du schickst das also nicht einfach an alle Ports und gleichzeitig braucht der Sender auch nicht für jeden Client einen Stream zu erzeugen. NUR: Das klappt bei dir nicht.
Du würdest via VPN einen Join senden - und dein Gerät bekommt den Stream. Im Endeffekt also Unicast. Hast du jetzt 2, 3 oder 5 Geräte im VPN dann brauchst du trotzdem X-fach die Bandbreite. Denn die sind ja alle über die Internet-Leitung angebunden. Wenn dein Sat-Gateway jetzt den reinen MPEG-TS durchs Netz jagt bist du schnell mal bei 3-8 MBit/Kanal. Und das mit vielen Hindernissen das eben dein VPN wissen muss das es ne 239.x.y.z-IP irgendwo da gibt, der Switch muss was vom VPN wissen (als Gateway),...
Wenn du jetzt 2 Netze hast bei denen du das Multicast nutzen möchtest wäre MEIN Weg das ich gucken würde: Netz A ein Gerät rein welches mir den Multicast mit nem neuen (komprimierten) Codec auf Unicast setzt. Diesen würde ich auf ein Gerät in Netz B jagen - und dort eben sagen "nimm den Unicast und jage den auf die Multicast-IP xyz". Das könnte z.B. jedesmal ne NUC, nen Raspberry oder sonstwas sein.
so wie es sich liest möchtest du einen TV-Kanal zuhause via Internet gucken können. Falls es das ist würde ich mir was anderes überlegen - z.B. via VLC den Stream lokal abgreifen und dann (ggf. mit nem anderem Codec) per Unicast zum Ziel jagen.
Hintergrund: Multicast hilft dir hier nicht. Das ist im lokalen Netzwerk schön - du hast 1 Sender, der sendet an den Switch und der transportiert das dann an jeden Client der nen Join gemacht hat. Du schickst das also nicht einfach an alle Ports und gleichzeitig braucht der Sender auch nicht für jeden Client einen Stream zu erzeugen. NUR: Das klappt bei dir nicht.
Du würdest via VPN einen Join senden - und dein Gerät bekommt den Stream. Im Endeffekt also Unicast. Hast du jetzt 2, 3 oder 5 Geräte im VPN dann brauchst du trotzdem X-fach die Bandbreite. Denn die sind ja alle über die Internet-Leitung angebunden. Wenn dein Sat-Gateway jetzt den reinen MPEG-TS durchs Netz jagt bist du schnell mal bei 3-8 MBit/Kanal. Und das mit vielen Hindernissen das eben dein VPN wissen muss das es ne 239.x.y.z-IP irgendwo da gibt, der Switch muss was vom VPN wissen (als Gateway),...
Wenn du jetzt 2 Netze hast bei denen du das Multicast nutzen möchtest wäre MEIN Weg das ich gucken würde: Netz A ein Gerät rein welches mir den Multicast mit nem neuen (komprimierten) Codec auf Unicast setzt. Diesen würde ich auf ein Gerät in Netz B jagen - und dort eben sagen "nimm den Unicast und jage den auf die Multicast-IP xyz". Das könnte z.B. jedesmal ne NUC, nen Raspberry oder sonstwas sein.
Guten Morgen, ihr Zwei!
Viel Dank für Eure schnellen Antworten und Eure Anmerkungen.
@gierig:
Klar muss man unterscheiden zwischen Tunnelprotokollen, wie eben das für mein Vorhaben favorisierte GRE, und den entsprechenden Verschlüsselungsprotokollen, wie IpSec, bzw. pptp oder die von Dir eingeworfenen Protokolle SSL und SSH. Soweit korrekt?
Nun las ich teilweise widersprüchliche Infos: mancherorts wurde behauptet, dass das GRE-Transportprotokoll eben nicht mit IpSec zur Funktion gebracht werden könnte - sondern eben beispielsweise mit pptp - welches eben eine nicht mehr zeitgemäße Absicherung darstellen soll. Dadurch kam ich auf die Idee den GRE-pptp-Stream seinerseits in einen ipsec-Tunnel zu tunneln - Transportprotkoll wäre mir in dem Fall dann wurscht.
Hab ich deinen Post richtig verstanden? GRE ist allerdings schon mit IpSec vereinbar?
Weiterhin hab ich gelesen, dass sich besonders SSL eher für Browseranwendungen zum flexiblen Einwählen von beliebigen Orten irgendwo auf der Welt eignen soll und im Gegensatz zu IpSec auf Anwendungen eher "begrenzend" wirkt. Den höheren Konfigurationsaufwand von IpSec scheue ich nicht - auch das bei IpSec im Gegensatz zu SSL ein Client benötigt wird, stört mich nicht. SSH kenne ich bisher gar nicht.
Würdest du beim Verbindungsaufbau eher zu so etwas wie AES oder doch lieber zu einer asymetrischen Lösung durch Zertifikate raten?
Wie sinnvoll ist es die Verbindung zu halten?
@maretz:
Ich würde mal sagen du hast mich semi-ertappt.
Folgende Dinge solen später möglich sein:
- Remote-Zugriff auf den VPN-Server im anderen Netz zu administrativen Zwecken - klar. Bei IpSec wohl aber nicht selbstverständlich?
- Gegenseitige Druckerfreigaben der Netzwerkdrucker. Bzw. evtl. soger nutzen der Faxfunktion, die einer der beiden Drucker kann.
- bei Bedarf vorübergehendes tunneln weiterer Geräte, um Geocast auszutricksen.
- und nun zu dem wo du hellhörig wurdest: am Netzwerk auf Clientseite soll eine iptv-box eines Internetproviders zum einsatz kommen, die zum Internetanschluss gehört, an der ich gedenke den VPN-Server einzurichten. Dortiger Upload ist derzeit 20mbit, steigt aber vermutlich nächstes Jahr auf 40mbit - mal sehen.
Daher weiß ich nicht inwiefern sich das was du mit dem VLC-Player beschreibst auf mein Szenario ummünzen lässt. Ich habe also vor das Multicast-Signal an dem einen Anschluss abzugreifen und per VPN zur zweiten Box zu senden, die das Multicastsignal dann direkt verwertet. Ich bräuchte also nur die einfache Bandbreite. Sprich bei HD-streaming so Pi * Daumen so 8mbit denke ich. Was mich vor diesem Hintergrund interessiert: gäbe es ne zweite hypothetische Box auf Clientseite, dann läge der Stream doch trotzdem nur bei ca 8mbit, wenn auf beiden Boxen der selbe Sender läuft, oder? Ist ja Multicast. Wird auf einer Box geseppt - klar, dann müsste sich der Traffic grob verdoppeln.
Vielen lieben Dank euch schon mal.
Viel Dank für Eure schnellen Antworten und Eure Anmerkungen.
@gierig:
Klar muss man unterscheiden zwischen Tunnelprotokollen, wie eben das für mein Vorhaben favorisierte GRE, und den entsprechenden Verschlüsselungsprotokollen, wie IpSec, bzw. pptp oder die von Dir eingeworfenen Protokolle SSL und SSH. Soweit korrekt?
Nun las ich teilweise widersprüchliche Infos: mancherorts wurde behauptet, dass das GRE-Transportprotokoll eben nicht mit IpSec zur Funktion gebracht werden könnte - sondern eben beispielsweise mit pptp - welches eben eine nicht mehr zeitgemäße Absicherung darstellen soll. Dadurch kam ich auf die Idee den GRE-pptp-Stream seinerseits in einen ipsec-Tunnel zu tunneln - Transportprotkoll wäre mir in dem Fall dann wurscht.
Hab ich deinen Post richtig verstanden? GRE ist allerdings schon mit IpSec vereinbar?
Weiterhin hab ich gelesen, dass sich besonders SSL eher für Browseranwendungen zum flexiblen Einwählen von beliebigen Orten irgendwo auf der Welt eignen soll und im Gegensatz zu IpSec auf Anwendungen eher "begrenzend" wirkt. Den höheren Konfigurationsaufwand von IpSec scheue ich nicht - auch das bei IpSec im Gegensatz zu SSL ein Client benötigt wird, stört mich nicht. SSH kenne ich bisher gar nicht.
Würdest du beim Verbindungsaufbau eher zu so etwas wie AES oder doch lieber zu einer asymetrischen Lösung durch Zertifikate raten?
Wie sinnvoll ist es die Verbindung zu halten?
@maretz:
Ich würde mal sagen du hast mich semi-ertappt.
Folgende Dinge solen später möglich sein:
- Remote-Zugriff auf den VPN-Server im anderen Netz zu administrativen Zwecken - klar. Bei IpSec wohl aber nicht selbstverständlich?
- Gegenseitige Druckerfreigaben der Netzwerkdrucker. Bzw. evtl. soger nutzen der Faxfunktion, die einer der beiden Drucker kann.
- bei Bedarf vorübergehendes tunneln weiterer Geräte, um Geocast auszutricksen.
- und nun zu dem wo du hellhörig wurdest: am Netzwerk auf Clientseite soll eine iptv-box eines Internetproviders zum einsatz kommen, die zum Internetanschluss gehört, an der ich gedenke den VPN-Server einzurichten. Dortiger Upload ist derzeit 20mbit, steigt aber vermutlich nächstes Jahr auf 40mbit - mal sehen.
Daher weiß ich nicht inwiefern sich das was du mit dem VLC-Player beschreibst auf mein Szenario ummünzen lässt. Ich habe also vor das Multicast-Signal an dem einen Anschluss abzugreifen und per VPN zur zweiten Box zu senden, die das Multicastsignal dann direkt verwertet. Ich bräuchte also nur die einfache Bandbreite. Sprich bei HD-streaming so Pi * Daumen so 8mbit denke ich. Was mich vor diesem Hintergrund interessiert: gäbe es ne zweite hypothetische Box auf Clientseite, dann läge der Stream doch trotzdem nur bei ca 8mbit, wenn auf beiden Boxen der selbe Sender läuft, oder? Ist ja Multicast. Wird auf einer Box geseppt - klar, dann müsste sich der Traffic grob verdoppeln.
Vielen lieben Dank euch schon mal.
IPSec kann — wenn es im Tunnelmodus betrieben wird — alles verschlüsseln, was auf Layer 3 zwischen zwei Endpunkten so gesendet wird.
Du kannst also auch ganz banal einen simplen GRE-Tunnel zwischen zwei Routern aufbauen und diese Kommunikation per IPSec dann verschlüsseln.
In GRE wiederum kannst du grundsätzlich alles kapseln und so bspw. auch einen Layer2-Transport darüber errichten (Ethernet).
Unter Linux wird das gerne als GRE-TAP bezeichnet. Aber genau so könntest du theoretisch das Netzwerk transparent so erweitern, als wenn du zwei Switches per Kabel verbindest.
Zusätzlich bräuchtest du unter Linux etwas, was IGMP-Proxy bereitstellt und Multicast-Forwarding macht.
Meine letzten Experimente dazu fanden auf Kernel 3.2.x statt und lassen sich als „desaströs“ bezeichnen — aber vermutlich hat sich dazu in der Zwischenzeit was getan.
Allerdings fällt die MTU so auf einen relativ kleinen Wert:
GRE benötigt für sich 24 Bytes im Paket, ein Ethernet-Frame hat 18 Bytes Größe, bei IPSec ist das etwas variabel, man kann aber auch da von ca. 64 Bytes im Worst Case ausgehen.
Dazu kommen die Header für IP-Pakete (bei IPv4 und IPv6 unterschiedlich), UDP-Header für den Stream...
Alles in allem sollte der Payload dann nicht mehr größer als 1360 Bytes sein um sicher durch das Konstrukt zu passen.
Ob das gegeben ist, ist fraglich. Da der vom Provider bereitgestellte Multicast-Stream keine Variationen pro Client zulässt, dürfen die einzelnen Pakete des Streams also nicht größer als diese 1360 Bytes plus 26 Bytes IPv4 und UDP-Header sein.
Ansonsten müsste man entweder beginnen zu fragmentieren oder einen Proxy hinstellen, der den Stream nimmt und (mit geringerer MTU) als Multicast weiterleitet.
Du kannst also auch ganz banal einen simplen GRE-Tunnel zwischen zwei Routern aufbauen und diese Kommunikation per IPSec dann verschlüsseln.
In GRE wiederum kannst du grundsätzlich alles kapseln und so bspw. auch einen Layer2-Transport darüber errichten (Ethernet).
Unter Linux wird das gerne als GRE-TAP bezeichnet. Aber genau so könntest du theoretisch das Netzwerk transparent so erweitern, als wenn du zwei Switches per Kabel verbindest.
Zusätzlich bräuchtest du unter Linux etwas, was IGMP-Proxy bereitstellt und Multicast-Forwarding macht.
Meine letzten Experimente dazu fanden auf Kernel 3.2.x statt und lassen sich als „desaströs“ bezeichnen — aber vermutlich hat sich dazu in der Zwischenzeit was getan.
Allerdings fällt die MTU so auf einen relativ kleinen Wert:
GRE benötigt für sich 24 Bytes im Paket, ein Ethernet-Frame hat 18 Bytes Größe, bei IPSec ist das etwas variabel, man kann aber auch da von ca. 64 Bytes im Worst Case ausgehen.
Dazu kommen die Header für IP-Pakete (bei IPv4 und IPv6 unterschiedlich), UDP-Header für den Stream...
Alles in allem sollte der Payload dann nicht mehr größer als 1360 Bytes sein um sicher durch das Konstrukt zu passen.
Ob das gegeben ist, ist fraglich. Da der vom Provider bereitgestellte Multicast-Stream keine Variationen pro Client zulässt, dürfen die einzelnen Pakete des Streams also nicht größer als diese 1360 Bytes plus 26 Bytes IPv4 und UDP-Header sein.
Ansonsten müsste man entweder beginnen zu fragmentieren oder einen Proxy hinstellen, der den Stream nimmt und (mit geringerer MTU) als Multicast weiterleitet.
In einem Bridging Design geht es natürlich auch ohne GRE skaliert aber sicher nicht. Bridging ist immer mit großer Vorsicht zu geniessen, da man damit auch zwangsweise immer den gesamten beidseitigen Broadcast Traffic am Hals hat:
https://forums.openvpn.net/viewtopic.php?t=21509
Jeder Router der PIM Routing kann würde es auch nativ über IPsec geroutet können (Cisco etc.).
Müsste man mal klären ob es eine PIM Routing Option unter Linux gibt, damit sollte es auch ohne Bridge klappen. Wäre ja verwunderlich wenn es PIM für Linux nicht geben würde
https://forums.openvpn.net/viewtopic.php?t=21509
Jeder Router der PIM Routing kann würde es auch nativ über IPsec geroutet können (Cisco etc.).
Müsste man mal klären ob es eine PIM Routing Option unter Linux gibt, damit sollte es auch ohne Bridge klappen. Wäre ja verwunderlich wenn es PIM für Linux nicht geben würde
Nun las ich teilweise widersprüchliche Infos: mancherorts wurde behauptet, dass das GRE-Transportprotokoll eben nicht mit IpSec zur Funktion gebracht werden könnte
WO steht so ein Nonsense ? Mit Ipsec abgesicherte GRE Tunnel sind Industrie Standard seit vielen Jahren
Weiterhin hab ich gelesen, dass sich besonders SSL eher für Browseranwendungen zum flexiblen Einwählen von beliebigen Orten irgendwo auf der Welt eignen soll und im Gegensatz zu IpSec auf Anwendungen eher "begrenzend" wirkt.
Wohl auf der gleichen Satiere Seite wie die wo steht das IPsec und GRE nicht zusammenpassen.
Ließ doch mal bitte in der Wikipedia (ggf die englischen Artikel dazu) was zu SSL, TLS, openVPN, Ipsec und GRE.
Wiki ist vielleicht nicht die umfangreichste Geschichte und nicht immer ist alles korrekt, gibt aber einen ggf. weiteren
einstieg und google Hilfen an die Hand.
Ich würde mal sagen du hast mich semi-ertappt.
...
...
Bitte auch verinnerlichen was Lord Gurke gesagt hat. und ggf darüber nachendenken was maretz gesagt hat....
...
WO steht so ein Nonsense ?
Vermutlich auf gutefrage.net 
