16
OpenVPN, zwei OpenWRT Router verbinden und VLAN durchs VPN leiten
Hallo Ihr Lieben,
die VPN's terminieren auf einen Debian Wheezy Server. Die Verbindungen werden über TAP realisiert. Damit Broadcast und Multicast Pakete durch den Tunnel gehen. Nun möchte ich aber das ich ein VLAN (Verfügbar auf der Serverseite) auch auf der Client Seite verfügbar ist. Könnt Ihr mir einen Tipp geben wo ich mich reinlesen kann? Beigefügt die Server und eine Client Konfiguration.
server.conf
client.ovpn
Nun zu meinen Fragen. Wie bekomme Ich das VLAN durch den Tunnel? Was muss ich bei den Konfigurationen hinzufügen? Vorab herzlichen Danfür Eure Unterstützung.
Lieben Gruß von Stefan Harbich
die VPN's terminieren auf einen Debian Wheezy Server. Die Verbindungen werden über TAP realisiert. Damit Broadcast und Multicast Pakete durch den Tunnel gehen. Nun möchte ich aber das ich ein VLAN (Verfügbar auf der Serverseite) auch auf der Client Seite verfügbar ist. Könnt Ihr mir einen Tipp geben wo ich mich reinlesen kann? Beigefügt die Server und eine Client Konfiguration.
server.conf
local dstme01.xyz.de
port 1194
proto tcp
dev tap0
script-security 2
up "/etc/openvpn/up.sh br0 tap0 2360"
down "/etc/openvpn/down.sh br0 tap0"
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
<dh>
-----BEGIN DH PARAMETERS-----
...
-----END DH PARAMETERS-----
</dh>
server-bridge
push "route-gateway dhcp"
tls-server
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>
cipher DES-EDE3-CBC # Triple-DES
comp-lzo
max-clients 100
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.logdev tap
proto tcp-client
remote dstme01.xyz.de 1194
resolv-retry infinite
nobind 1
persist-key 1
persist-tun 1
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
ns-cert-type server
tls-client
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>
cipher DES-EDE3-CBC
comp-lzo yes
verb 3
route-nopull 1Lieben Gruß von Stefan Harbich
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: 321857
Url: https://administrator.de/contentid/321857
Ausgedruckt am: 25.11.2024 um 16:11 Uhr
16 Kommentare
Neuester Kommentar
und VLAN durchs VPN leiten
Technisch unmöglich ! OVPN wie auch jedes andere VPN Protokoll kann keine Frames transportieren innerhalb des Tunnels die größer als die standartisierten 1500 Bytes sind. .1q Frames ist also nicht möglich denn durch den .1q VLAN Tag sind die größer..Das wird also schon im Ansatz scheitern....
Abgesehen davon ist es ja völliger Unsinn Layer 2 durch den VPN Tunnel zu bringen. Der gesamte Broad- und Multicast Traffic der VLAN L2 Domains belastet damit deinen Tunnel und schränkt die Performance massiv ein.
Layer 2 über einen VPN Tunnel ist ein designtechnisches NoGo...weiß man aber auch als Netzwerker ! In sofern ist allein der Gedanke schon einer der in eine Sackgasse führt.
Routing ist hier also, wie immer, dein bester Freund !
Hallo aqui,
das verstehe ich. Wobei was ist denn mit MultiVLAN (Site to Site)? Dann frage ich mal anders. Ich habe zu Hause ein WLAN Netzwerk Class C (192.168.30.0/24), dass ich nun über einen Tunnel auch auf der Client Seite nutzen will. D.h. wenn ich mich am außen Standort befinde ich dort direkt online bin. Gleiche SSID und Key,. Was muss ich da berücksichtigen? Wenn es nur über Routing geht, dann kann ich ja nicht das gleiche Class C Netz am außen Standort nutzen, oder?
Lieben Gruß von Stefan Harbich
das verstehe ich. Wobei was ist denn mit MultiVLAN (Site to Site)? Dann frage ich mal anders. Ich habe zu Hause ein WLAN Netzwerk Class C (192.168.30.0/24), dass ich nun über einen Tunnel auch auf der Client Seite nutzen will. D.h. wenn ich mich am außen Standort befinde ich dort direkt online bin. Gleiche SSID und Key,. Was muss ich da berücksichtigen? Wenn es nur über Routing geht, dann kann ich ja nicht das gleiche Class C Netz am außen Standort nutzen, oder?
Lieben Gruß von Stefan Harbich
@aqui: Kurze Verständnis Frage da ich damit nicht oft zu tun habe.
Ist eine VLan Weiterleitung dann nur über MPLS Vernetzung möglich?
Ist eine VLan Weiterleitung dann nur über MPLS Vernetzung möglich?
ein WLAN Netzwerk Class C
Netzwerk Classes gibt es schon seit mehr 25 Jahren nicht mehr! Das ist tiefes IP Neantertal...https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing
was ist denn mit MultiVLAN (Site to Site)?
Was soll das sein oder was meinst du damit genau ?? Wenn ich Site to Site ein LWL liegen hab macht man Tagging an und gut iss.Wenn ich aktive Technik dazwischen habe wie Routing über WAN Topologien mit entsprechenden Encapsulation und Framing wozu auch VPN gehört geht es nicht.
Was dein WLAN anbetrifft kann man das mit Bridging über den Tunnel transparent anbinden. Damit wäre es denn am Außenstandord IP adresstechnisch gleich wie im WLAN, also alles identisch.
https://openvpn.net/index.php/open-source/documentation/miscellaneous/76 ...
Das sollte man aber nur dann machen wenn man es wirklich zwingend braucht. (Betonung auf "wirklich" !)
Meist ist das nicht der Fall oder warum genau ist dir die Transparenz des IP Netzes so wichtig ?? Das wäre mal spannend zu erfahren. Heutzutage ist alles routebar...fast alles.
Warum Bridging kontraproduktiv ist ist ja oben schon erklärt. OVPN rät ebenso davon ab.
Wenn du aber nur ne Handvoll Clients hast (Betonung auf Handvoll !) dann kann man auch ein Bridging machen, wenn man sich der Nachteile bewusst ist. 5 Clients machen nun auch nicht soviel Broad- und Multicast das der Tunnel zusammenbricht so das es bei so einer kleinen Menge tolerabel ist.
Eine sinnvolle Alternative das zu lösen ist klassisches Routing im VPN aber innerhalb davon einen VxLAN Tunnel zu etablieren der allen Layer 2 Traffic transportiert.
Wie das geht erklärt dieses Forentutorial.
Hallo aqui,
du scheinst nicht nehr auf den aktuellen Stand zu sein? Oder verstehe ich da was anders? Schau mal: MultiVLAN
Lieben Gruß von Stefan Harbich
du scheinst nicht nehr auf den aktuellen Stand zu sein? Oder verstehe ich da was anders? Schau mal: MultiVLAN
Lieben Gruß von Stefan Harbich
Ich bin schon auf dem aktuellen Stand ! 
Sorry aber DU hast da wohl gründlich was missverstanden. Bitte lies den zitierten Thread mal genau und vor allem verstehe ihn !
"You can create the Site-to-Site to allow multiple VLANs to communicate through the tunnel."
Bedeutet ja das ein ganz normales Routing über den VPN Tunnel gemacht wird um diese Netze zu verbinden !!!
Das ist klar das das funktioniert, das weiss auch jeder Azubi im ersten Lehrjahr.
Allein die IP Adressierung auf beiden Seiten konterkariert ja das was du oben willst schon im Ansatz:
local net 1: 10.1.1.0/24 -
local net 1: 192.168.10.0/24 -
local net 2: 10.0.0.0/24 -
local net 2: 192.168.11.0/24 -
Vier unterschiedliche IP Netze die sich problemlos routen lassen ohne das man irgendwelche .1q Tagging übertragen muss.
Das das mit simplen Bordmitteln geht steht vollkommen außer Frage.
Kann jeder Baumarkt Router der VPN kann.
Die Sache sähe aber anders aus wenn an Standort 1 und 2 die gleichen IP Netze wären. So versteht man ja auch deinen von dir beschriebenen Ansatz oben. Gleiche IP auf beiden Seiten, was dann ein Layer 2 Bridging erzwingt.
Das geht dann nur mit Bridging aber dann bei OVPN eben nicht für multiple VLANs sondern nur für ein einziges !
Fazit: Genau lesen und verstehen...dann posten !
Sorry aber DU hast da wohl gründlich was missverstanden. Bitte lies den zitierten Thread mal genau und vor allem verstehe ihn !
"You can create the Site-to-Site to allow multiple VLANs to communicate through the tunnel."
Bedeutet ja das ein ganz normales Routing über den VPN Tunnel gemacht wird um diese Netze zu verbinden !!!
Das ist klar das das funktioniert, das weiss auch jeder Azubi im ersten Lehrjahr.
Allein die IP Adressierung auf beiden Seiten konterkariert ja das was du oben willst schon im Ansatz:
local net 1: 10.1.1.0/24 -
local net 1: 192.168.10.0/24 -
local net 2: 10.0.0.0/24 -
local net 2: 192.168.11.0/24 -
Vier unterschiedliche IP Netze die sich problemlos routen lassen ohne das man irgendwelche .1q Tagging übertragen muss.
Das das mit simplen Bordmitteln geht steht vollkommen außer Frage.
Kann jeder Baumarkt Router der VPN kann.
Die Sache sähe aber anders aus wenn an Standort 1 und 2 die gleichen IP Netze wären. So versteht man ja auch deinen von dir beschriebenen Ansatz oben. Gleiche IP auf beiden Seiten, was dann ein Layer 2 Bridging erzwingt.
Das geht dann nur mit Bridging aber dann bei OVPN eben nicht für multiple VLANs sondern nur für ein einziges !
Fazit: Genau lesen und verstehen...dann posten !
Hallo. wie werden denn die up und down.sh. erstellt... ich finde nichts in forum.
Zitat von @aqui:
Das wird also schon im Ansatz scheitern....
Abgesehen davon ist es ja völliger Unsinn Layer 2 durch den VPN Tunnel zu bringen. Der gesamte Broad- und Multicast Traffic der VLAN L2 Domains belsatet damit deinen Tunnel und schränkt die Performance massiv ein.
Layer 2 über einen VPN Tunnel ist ein generelles NoGo...weiß man aber auch als Netzwerker ! In sofern ist allein der Gedanke schon einer der in eine Sackgasse führt.
Routing ist hier also wie immer dein Freund !
und VLAN durchs VPN leiten
Technisch unmöglich ! OVPN wie auch jedes andere VPN Protokoll kann keine Frames transportieren innerhalb des Tunnels die größer als die standartisierten 1500 Bytes sind. .1q Frames ist also nicht möglich denn durch den .1q VLAN Tag sind die größer..Das wird also schon im Ansatz scheitern....
Abgesehen davon ist es ja völliger Unsinn Layer 2 durch den VPN Tunnel zu bringen. Der gesamte Broad- und Multicast Traffic der VLAN L2 Domains belsatet damit deinen Tunnel und schränkt die Performance massiv ein.
Layer 2 über einen VPN Tunnel ist ein generelles NoGo...weiß man aber auch als Netzwerker ! In sofern ist allein der Gedanke schon einer der in eine Sackgasse führt.
Routing ist hier also wie immer dein Freund !
Das war selbst 2016 absoluter Schwachsinn! Schon mal was von gretap, vxlan, lt2pv3 usw. gehört? Es ist sehr wohl möglich VLANs nur einen VPN-Tunnel zu jagen und auch andere Protokolle, wie z.B. IPX sind kein Problem!
Zitat von @mm5533:
Zitat von @aqui:
Das wird also schon im Ansatz scheitern....
und VLAN durchs VPN leiten
Technisch unmöglich ! OVPN wie auch jedes andere VPN Protokoll kann keine Frames transportieren innerhalb des Tunnels die größer als die standartisierten 1500 Bytes sind. .1q Frames ist also nicht möglich denn durch den .1q VLAN Tag sind die größer..Das wird also schon im Ansatz scheitern....
Das war selbst 2016 absoluter Schwachsinn! Schon mal was von Gretap, VXLAN, LT2Pv3 usw. gehört? Es ist sehr wohl möglich VLANs durch einen VPN-Tunnel zu jagen. Auch andere Protokolle, wie z.B. IPX sind kein Problem und schon gar nicht die 1500er MTU.
Abgesehen davon ist es ja völliger Unsinn Layer 2 durch den VPN Tunnel zu bringen. Der gesamte Broad- und Multicast Traffic der VLAN L2 Domains belsatet damit deinen Tunnel und schränkt die Performance massiv ein.
Layer 2 über einen VPN Tunnel ist ein generelles NoGo...weiß man aber auch als Netzwerker ! In sofern ist allein der Gedanke schon einer der in eine Sackgasse führt.
Routing ist hier also wie immer dein Freund !
Ach, und warum gibts unter Netzwerken die Faustregel nicht mehr als 150 Host in einem Subnetz laufen zu lassen??
An der Broadcast Geschichte scheint doch was dran zu sein. Außer dem auch sehr gut selbst nachvollziehbar..
An der Broadcast Geschichte scheint doch was dran zu sein. Außer dem auch sehr gut selbst nachvollziehbar..
1Zitat von @Spirit-of-Eli:
Ach, und warum gibts unter Netzwerken die Faustregel nicht mehr als 150 Host in einem Subnetz laufen zu lassen??
An der Broadcast Geschichte scheint doch was dran zu sein. Außer dem auch sehr gut selbst nachvollziehbar..
Ach, und warum gibts unter Netzwerken die Faustregel nicht mehr als 150 Host in einem Subnetz laufen zu lassen??
An der Broadcast Geschichte scheint doch was dran zu sein. Außer dem auch sehr gut selbst nachvollziehbar..
Aha.. Dann würdest du also auch sagen, dass man künftig nur noch max. /25er definieren sollte, da alles andere zu groß ist und zu Problemen führt? Wäre mir neu. Oder muss künftig der Heimrouter der ein /24er Netz announced private VLANS mit Bridge oben drauf unterstützen?
Zitat von @mm5533:
Aha.. Dann würdest du also auch sagen, dass man künftig nur noch max. /25er definieren sollte, da alles andere zu groß ist und zu Problemen führt? Wäre mir neu. Oder muss künftig der Heimrouter der ein /24er Netz announced private VLANS mit Bridge oben drauf unterstützen?
Zitat von @Spirit-of-Eli:
Ach, und warum gibts unter Netzwerken die Faustregel nicht mehr als 150 Host in einem Subnetz laufen zu lassen??
An der Broadcast Geschichte scheint doch was dran zu sein. Außer dem auch sehr gut selbst nachvollziehbar..
Ach, und warum gibts unter Netzwerken die Faustregel nicht mehr als 150 Host in einem Subnetz laufen zu lassen??
An der Broadcast Geschichte scheint doch was dran zu sein. Außer dem auch sehr gut selbst nachvollziehbar..
Aha.. Dann würdest du also auch sagen, dass man künftig nur noch max. /25er definieren sollte, da alles andere zu groß ist und zu Problemen führt? Wäre mir neu. Oder muss künftig der Heimrouter der ein /24er Netz announced private VLANS mit Bridge oben drauf unterstützen?
Richtig. Außerdem bezweifele ich, dass ein Heimanwender mehr als 150 Geräte in sein Netzwerk bringen wird.
1Zitat von @Spirit-of-Eli:
Richtig. Außerdem bezweifele ich, dass ein Heimanwender mehr als 150 Geräte in sein Netzwerk bringen wird.
Zitat von @mm5533:
Aha.. Dann würdest du also auch sagen, dass man künftig nur noch max. /25er definieren sollte, da alles andere zu groß ist und zu Problemen führt? Wäre mir neu. Oder muss künftig der Heimrouter der ein /24er Netz announced private VLANS mit Bridge oben drauf unterstützen?
Zitat von @Spirit-of-Eli:
Ach, und warum gibts unter Netzwerken die Faustregel nicht mehr als 150 Host in einem Subnetz laufen zu lassen??
An der Broadcast Geschichte scheint doch was dran zu sein. Außer dem auch sehr gut selbst nachvollziehbar..
Ach, und warum gibts unter Netzwerken die Faustregel nicht mehr als 150 Host in einem Subnetz laufen zu lassen??
An der Broadcast Geschichte scheint doch was dran zu sein. Außer dem auch sehr gut selbst nachvollziehbar..
Aha.. Dann würdest du also auch sagen, dass man künftig nur noch max. /25er definieren sollte, da alles andere zu groß ist und zu Problemen führt? Wäre mir neu. Oder muss künftig der Heimrouter der ein /24er Netz announced private VLANS mit Bridge oben drauf unterstützen?
Richtig. Außerdem bezweifele ich, dass ein Heimanwender mehr als 150 Geräte in sein Netzwerk bringen wird.
Ich kenne weitaus größere Broadcast-Domänen mit bis zu 10.000 Hosts bei denen es keine Probleme gibt. Wie kann man sich sowas erklären?
Zitat von @mm5533:
Ich kenne weitaus größere Broadcast-Domänen mit bis zu 10.000 Hosts bei denen es keine Probleme gibt. Wie kann man sich sowas erklären?
Ich kenne weitaus größere Broadcast-Domänen mit bis zu 10.000 Hosts bei denen es keine Probleme gibt. Wie kann man sich sowas erklären?
Und, willst du dich jetzt battln? Fühlst du dich dadurch besser??
Sei lieber froh das es läuft. Bei vielen anderen nämlich nicht und das hat eben seine Gründe.
Btw. kenne ich auch Netze welche mit 1k Host und mehr laufen. Das auch schon seit Jahren.
Best practice ist das auf keinen Fall. Ein Admin, der sowas heute noch aufbaut hat seinen Beruf verfehlt.
1
Nein, ich will lediglich gefährliches Halbwissen und Fehlinfos aus dem Weg schaffen, das ist alles.
Zitat von @mm5533:
Nein, ich will lediglich gefährliches Halbwissen und Fehlinfos aus dem Weg schaffen, das ist alles.
Nein, ich will lediglich gefährliches Halbwissen und Fehlinfos aus dem Weg schaffen, das ist alles.
Danke für die Klarstellung, mm5533!
Es ist kaum erträglich, wie selbsternannte Experten mit wenig kontextuellem Verständnis in überheblicher und abwertender Weise Hilfesuchenden falsche Informationen liefern.
Auch wenn der Ursprung schon 8 Jahre alt ist, so sollten Fragende sich nicht von derartigen Kommentaren davon abhalten lassen, weiterhin neugierig und kritisch zu bleiben.
