vpn broadcast probleme

gaw schrieb:

Der Bridge Modus ist allerdings etwas aufwendiger als es hier anklingt da mit zusätzlichen Schnittstellen (z.B br0) gearbeitet werden muss um zwischen eth0 und tun/tap eine Bridge aufzubauen. Auf dem System müssen die bridgeutils installiert sein und der Kernel muss das unterstützen.

Zum Vergrößern anklicken....

Hab ich mir zuerst auch gedacht, schlussendlich lässt es sich aber doch flott realisieren:
bridgeutils ist ein rpm - Paket
tap lässt sich ganz einfach mit einem Skript erstellen, siehe
http://fedoranews.org/contributors/florin_andrei/openvpn/
Kernel-Unterstützung: bei meinem Versuchen und auch laut Doku läufts ohne Modfikation auf allen Distros

gaw schrieb:

Und last not least müssen die Karten im Promiscuous-Mode arbeiten. Manche Karten machen das auf XP-Clients nicht automatisch und müssen extra mit netsh in diesen Modus geschaltet werden.

Zum Vergrößern anklicken....

Nein, auf Windows-Clients wird keine Änderunge benötigt, dort wird ein einges tun/tan-device vom Windows-Installer installiert und bringt so keine Konflikte mit anderen Devices mit sich (ist eine Wizard Next/Next - Installation)

gaw schrieb:

Für ein privates virtuelles Lan mit einem Freund zum Spielen sicherlich machbar. Für VPN in Firmen würde ich eher eine normalen VPN-Tunnel empfehlen.

Zum Vergrößern anklicken....

Darüber lässt es sich nicht streiten, wie über die beste Musikband
Normale VPN-Tunnel, wenn IPSec, da können viele ein Schnmerz-Liedchen von NAT-Traversal, eigenen Clients und Co erzählen. Ein interessanter Artikel dazu befindet sich unter
http://www.osnews.com/story.php?news_id=5803
Aber Achtung, sie sprechen noch Version 1.0, Version 2.0 benötigt nur mehr 1UDP/TCP - Port

gaw schrieb:

Bei aller Virtualität der angestrebten Lösungen, die Geschwindigkeit eines echten LAN's wird durch Bridging nicht hergestellt und wenn man sich überlegt was dabei herauskommt wenn ich eine achtspurige Autobahn bei Frankfurt durchsäge und über einen Feldweg tunnele (der Vergleich hinkt noch, der Unterschied zwischen LAN und Internet ist noch größer) wird nicht unbedingt zustimmen dass alles Machbare auch in die Tat umgesetzt werden muss.

Zum Vergrößern anklicken....

Die Frage war, wie kann das Problem gelöst werden, dass Broadcats nicht übertragen werden - nicht ob es sinnvoll ist Und es soll ja 10MBit DSL-Leitungen geben

olox schrieb:

der tun /tab adapter lies sich nicht so ohne weiteres an die ip binden , warum auch immer ?

Zum Vergrößern anklicken....

Vielleicht hilft das Skript, das ich weiter oben gepostet habe.

olox schrieb:

macht das bcrelay dann unnötig ? oder horcht er dann trtzdem auf eth0 um dann auf eth1 zu relayen? oder braucht er dann das nicht mehr ?

Zum Vergrößern anklicken....

Bei OpenVPN hast du das bridged device z.b. br0 dh. eth0 entspricht. An br0 sind dann die virtuellen Ports tap0 usw. "attached", über die die VPN-Verbindung reinkommt. Dh. weil br0, tap0, usw. gebridget sind, liegen sie alle im gleichen Subnetz und die Broadcasts funzen wirklich.

olox schrieb:

PS: befasse mich nun schon eine weile mit vpn , aber irgendwie bekomme ich das gefühl das die Spielehersteller genau das unterbinden wollen, das Ihre Spiele im VPN funtzen , weil dort gecrackte spiele funtzen.

Zum Vergrößern anklicken....

Kann ich nur bestätigen, zumindest bei allen aktuellen EA Games.

Poste mal meine Konfig, evt. kann sie jemandem weiterhelfen:

Client:

# openvpn-client.conf
#
# Set tunnel mode
client
dev tap

# Hostname for the VPN server
remote vpn.xxxx.xx


# This end takes the client role for
# certificate exchange
tls-client

# Certificate Authority file
ca cacert.pem

# Our certificate/public key
cert thomascert.pem

# Our private key
key ironcraftkey.pem

# Try to preserve some state across restarts.
persist-key
persist-tun

comp-lzo
comp-noadapt
pull

#mtu-test
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
ping 10
verb 4

ifconfig-nowarn
ip-win32 dynamic
tap-sleep 1
mssfix
route-delay 10


Server-Konfig:
#Linux VPN server config file
# These settings are different for each user
dev tap0
server-bridge 10.0.0.1 255.255.255.0 10.0.0.3 10.0.0.10
log-append /var/log/openvpn/openvpn.log
dh /etc/CertAuth/dh1024.pem
persist-tun
persist-key
comp-lzo
comp-noadapt
user openvpn
group openvpn
verb 5
# Root certificate
ca /etc/CertAuth/cacert.pem
# Server certificate
cert /etc/CertAuth/vpnservercert.pem
# Server private key
key /etc/CertAuth/vpnserverkey.pem

# Check for revoked client certificates.
crl-verify /etc/CertAuth/crl/crl.pem
ifconfig-pool-persist /etc/openvpn/ipp.txt
client-to-client
keepalive 10 120
status /var/log/openvpn/openvpn-status.log

tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
verb 4


Ein exzellenter Artikel befindet sich hier, um einfach die notwendige PKI einzurichten:
Deploying a VPN with PKI
http://www.oreillynet.com/pub/a/security/2004/10/21/vpns_and_pki.html

War von OpenVPN soweit positiv überrascht.

Gruss
Ironcraft

gaw schrieb:

Der Bridge Modus ist allerdings etwas aufwendiger als es hier anklingt da mit zusätzlichen Schnittstellen (z.B br0) gearbeitet werden muss um zwischen eth0 und tun/tap eine Bridge aufzubauen. Auf dem System müssen die bridgeutils installiert sein und der Kernel muss das unterstützen.

Zum Vergrößern anklicken....

Hab ich mir zuerst auch gedacht, schlussendlich - nach etwas Recherche - lässt es sich aber doch flott realisieren:
bridgeutils ist ein rpm - Paket
tap lässt sich ganz einfach mit einem Skript erstellen, siehe
http://fedoranews.org/contributors/florin_andrei/openvpn/
Kernel-Unterstützung: bei meinem Versuchen und auch laut Doku läufts ohne Modfikation auf allen aktuellen Distros

gaw schrieb:

Und last not least müssen die Karten im Promiscuous-Mode arbeiten. Manche Karten machen das auf XP-Clients nicht automatisch und müssen extra mit netsh in diesen Modus geschaltet werden.

Zum Vergrößern anklicken....

Nein, auf Windows-Clients wird keine Änderunge benötigt, dort wird ein einges tun/tan-device vom Windows-Installer installiert und bringt so keine Konflikte mit anderen Devices mit sich (ist eine Wizard Next/Next - Installation)

gaw schrieb:

Für ein privates virtuelles Lan mit einem Freund zum Spielen sicherlich machbar. Für VPN in Firmen würde ich eher eine normalen VPN-Tunnel empfehlen.

Zum Vergrößern anklicken....

Darüber lässt es sich nicht streiten, wie über die beste Musikband
Normale VPN-Tunnel, wenn IPSec, da können viele ein Schnmerz-Liedchen von NAT-Traversal, eigenen Clients und Co erzählen. Ein interessanter Artikel dazu befindet sich unter
http://www.osnews.com/story.php?news_id=5803
Aber Achtung, sie sprechen noch Version 1.0, Version 2.0 benötigt nur mehr 1UDP/TCP - Port

gaw schrieb:

Bei aller Virtualität der angestrebten Lösungen, die Geschwindigkeit eines echten LAN's wird durch Bridging nicht hergestellt und wenn man sich überlegt was dabei herauskommt wenn ich eine achtspurige Autobahn bei Frankfurt durchsäge und über einen Feldweg tunnele (der Vergleich hinkt noch, der Unterschied zwischen LAN und Internet ist noch größer) wird nicht unbedingt zustimmen dass alles Machbare auch in die Tat umgesetzt werden muss.

Zum Vergrößern anklicken....

Die Frage war, wie kann das Problem gelöst werden, dass Broadcats nicht übertragen werden - nicht ob es sinnvoll ist Und es soll ja 10MBit DSL-Leitungen geben Mal abgesehen von der Response Time.

Ich weiß zwar nicht warum du so pampig reagiert, nichtsdestotrotz solltest du aber meine Beiträge richtig lesen, bevor du laut nein schreist.
Ich schrieb sinngemäß folgendes:
Manche Karten schalten auf XP-Clients nicht automatisch in den Promiscous-Mode und müssen extra mit netsh in diesen Modus geschaltet werden.

Das sage ich nicht so, sondern weil dieses Phänomen wohl häufiger aufgetreten ist, siehe Link:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q302348&ID=KB;EN-US;Q302348&

Darauf deine Antwort

Nein, auf Windows-Clients wird keine Änderunge benötigt, dort wird ein einges tun/tan-device vom Windows-Installer installiert und bringt so keine Konflikte mit anderen Devices mit sich (ist eine Wizard Next/Next - Installation)

Zum Vergrößern anklicken....

Was hat deine Antwort bitte mit dem zu tun was ich geschrieben habe? Wie kommst du dazu meine Aussage zu negieren?

Was deine anderen Antworten angeht will ich das ganze kurz zusammenfassend beantworten, gibt es einge ältere Distributionen die die Bridgeunterstützung nicht automatisch aktiviert haben und es gibt viele Anwender, die einen eigenen Kernel gebaut haben.

Das scheint dir aber nicht bewusst zu sein, offenbar gehts du davon aus dass jeder die neueste Version benutzt. Für andere, die das anders handhaben ist es aber schon wichtig zu wissen, dass diese Unterstützung aktiviert sein muss, damit der Bridgemodus aktiviert werden kann. Es arbeitet wie schon gesagt nicht jeder mit der neuesten Distribution, in vielen produktiven Umgebungen wartet man in der Regel sogar mindestens ein halbes Jahr mit dem Einsatz einer neuen Version und auch nur dann wenn diese notwendig erscheint. Das gilt besonderes im Zusammenhang mit sicherheitsrelevanten Internettechnologien wie Firewalls und VPN-Server.

Ein Anwender einer älteren SuSE 8.x oder einer stable debian der versucht den Bridgemodus ohne Kernelkonfiguration einzuschalten wird wohl scheitern. Nicht umsonst wird auf den Seiten von openvpn extra darauf hingewiesen.

Last not least ist dieses Forum bestimmt nicht nur für Zocker gedacht sondern auch für andere Anwender, so dass Empfehlungen über VPN's auch auf Sicherheit und Anwendbarkeit hinterfragt werden sollten. Auch wenn du dich offenbar nicht solchen unnötigen Ballast quälst:

Die Frage war, wie kann das Problem gelöst werden, dass Broadcats nicht übertragen werden - nicht ob es sinnvoll ist

Zum Vergrößern anklicken....

Ab einem bestimmten kognitiven Level erübrigt sich eine Erklärung warum eine solche Aussage lediglich den Verfasser in einer ersten Einschätzung seiner diesbezüglichen Leistungsfähigkeit entsprechend qualifiziert. Daher fühlt man sich zwangsläufig zu folgender Feststellung genötigt: Wir befinden uns nicht in einem Quiz in einer billigen Fernsehhow wo es darum geht viele Punkte zu sammeln und die Frage eines Quizmasters zu beantworten. Es gibt weder 1000 Punkte noch Applaus dafür. Anders formuliert: in einem Forum, in dem Netzwerkeinstellungen diskutiert werden, sollten Empfehlungen auch hinsichtlich ihrer Sinnhaftigkeit und eventuellen Risiken hin abgescheckt werden dürfen ohne dummdreiste Bemerkungen zu ernten. Wie schon erwähnt existieren eben auch auch Alternativen zu einem VPN-Server im Bridgemodus.

mfG
gaw

Tut mir leid wenn du das so aufgefasst hast, war nicht meine Absicht, aber es benötigt immer zwei, um ein Missverständis zu erzeugen :idea:

Ich vermute wir sprechen hier aneinander vorbei. Nicht unter Windows XP bridgen, sondern den Netzweradapter des VPN-Servers zu bridgen.

Das sage ich nicht so, sondern weil dieses Phänomen wohl häufiger aufgetreten ist.

Zum Vergrößern anklicken....

Um OpenVPN im Bridge-Modus zu betreiben, erzeugt man die Bridge normalerweise am Server und nicht am Windows-Client. Außer der Windows-Client ist der OpenVPN-Server, was ich aber selten gesehen habe.

Deinen restlichen Kommentaren stimme ich zu, wenn du es aber gleich zu Sprache gebracht hättest, müsste ich mich jetzt nicht so schlecht fühlen Ich hab mich auf die Home-Router bezogen, und daher keine professionallen Umgebungen angenommen, kann leider nicht alle Situationen annehmen.
Greetz
Ironcraft

Was noch ein interessanter Ansatz aus technischer Sicht sein könnte:

Need For Speed Underground 2, LAN game extender
http://www.csc.liv.ac.uk/~greg/nfsu2relay.html

und

Playing Multiplayer Games Over a VPN
http://www.bsdnews.org/01/game_vpn.php
Bezieht sich zwar auf BSD, sollte vom Konzept her aber auch funzen.

Wenn du dich schlecht fühlst kann das mehrere Ursachen habe, vielleicht hast du einfach zuviel vom Weihnachtsbraten gegessen, das wirkt sich mitunter entsprechend aus Spiele die so konzipiert worden sind, dass sie übers Internet laufen arbeiten arbeiten nicht mit Broadcasts. Die Frage nach dem Sinn ist aber auch im LAN gestattet. Ein Spiel dass ohne ein vernünftiges Netzwerkmanagement mit Broadcasts arbeitet gehört nicht nur in einem Büronetzwerk verbannt. Langfristig tun sich die Zocker keinen Gefallen damit, weil diese Spiele schon im LAN anstatt Daten zu verteilen nur mit überflüssigen Broadcasts die Netzlast erhöht. Aber es scheint in diesem Mileu ein Sakrileg zu sein schnellere Alogorithmen zu implementieren. Anstelle dessen werden Spiele implementiert die auch das heimische Netzwerk mit Broadcastrufen schnell an den Rand der Belastbarkeit pushen und man dreht lieber noch ein wenig an den Taktraten des Prozessors und wundert sich verzweifelt wenn dieser langsam dahinschmilzt oder Opa sauer wird, weil das Internet wieder so langsam wird.


mfG
gaw

omg da schaut man mal ne woche nicht rein und schon wächst der thread auf 2 seiten an =)

open vpn sieht zwar recht nett aus, ich möchte es aber trotzdem weiterhin mit dem "normalen" pptpd und bcrelay versuchen.

trotzdem, danke für eure großartige hilfe!

was genau steht eigentlich jetzt in der

ifconfig-pool-persist /etc/openvpn/ipp.txt

ipp.txt drin wenn ich fragen darf???

hab derweil die zeile mit

ifconfig 10.0.0.1 255.255.255.0

ersetzt.. scheint zu gehen..