• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

vpn broadcast probleme

sEeEd

Newbie
hallo,
ich habe erfolgreich einen pptpd server eingerichtet
ich hänge direkt im lan mit dem vpn server/router
die netze sehen folgendermaßen aus

vpn netz: 10.4.1.0/24
mein netz: 10.5.1.0/24
ips des servers: 10.5.1.169, 10.4.1.254

die client können (meistens)erfolgreich eine Verbindung aufbauen, dannach sind pings in alle möglichen richtungen möglich, also mein netz ins vpn netz und umgekehrt

erstes problem ist, das broadcasts von windows clients mit der source ip der netzwerkkarte und nicht der des vpn adapters gesendet werden also zb 192.168.0.1->255.255.255.255
damit kann ich klarerweise nichts anfangen, ich habe bereits versucht mit iptables per postrouting und snat die absenderadresse zu verändern, allerdings ohne erfolg.

zweites problem ist das broadcasts, mal von der fehlerhaften source ipabgesehen, garnicht ins andere netz kommen. In diesem punkt bin ich mir jetzt nichtso sicher. Ich glaube von einer seite gings sogar mal, weiss leider nur nichtmehr ob das jetzt die aus meinem lan waren oder die aus dem vpn netz...
theoretisch sollten es die aus meinem lan sein da bcrelay eth0 gesetzt is.

drittes problem ist das manchmal keine vpn verbindung aufgebaut werden kann. da gehts nach "Benutzername und kennwort werden überprüft.." einfach nichtmehr weiter. Das einzige was mir einfallen würde ist das der provider des clients gre nicht erlaubt oder so....

ich versuch mal die letzten 2 probleme zu replizieren und die logs zu posten.

bitte helft mir ich bin echt schon am verzweifeln...
 

gaw

Hacker
Broadcast-Rufe bleiben eigentlich immer im eigenen Netz bzw. Subnetz, dazu sind sie auch da. Aus diesem Grund müssen für bestimmte Dienste die zwingend mit Broadcast arbeiten, zum Beispiel dhcp, zusätzliche Server als relay agents eingesetzt werden, die auf dem Router zwischen den beiden Netzen arbeiten und entsprechende Broadcasts weiterleiten.

Nicht der Broadcast muss konfiguriert werden sondern die Dienste müssen auf die veränderte Situation hin angepasst werden.


mfG
gaw
 
OP
S

sEeEd

Newbie
naja sowas gibts ja bei pptpd nämlich bcrelay
aber das funktioniert anscheinend nicht so wie es soll...

aber das hauptproblem liegt imo auch darin das windows die falsche source adresse an den vpn tunnel schickt

gibts solche relay agenten auch standalone?

dieses problem wird glaub ich auch hier beschrieben:
http://www.fli4l.de/german/howtos/howto-vpn_zum_fli_mit_windows.htm
http://powerforen.de/forum/showthread.php?t=156720
 

gaw

Hacker
Diskussionen in Foren sind nicht immer als Quelle geeignet. Broadcasts erreichen alle Rechner im Netz und werden in erster Linie genutzt. wenn ein Rechner im gleichen Netz zu einer IP die MAC-Nummer wissen will (arp) und wenn ein Rechner eine IP-Adresse von einem DHCP-Server benötigt . Ansonsten werden sie seltener benötigt. Das Windowsrechner mit Broadcasts nur so um sich werfen, auch oft wenn es nicht nötig ist, ist allgemein bekannt. Diese Rundrufe sind aber nicht zwingend notwendig um Dienste laufen zu lassen.

Wozu wenn man fragen darf, sollen den Broadcasts über VPN vom Notebook ins heimische Netz bzw. umgekehrt gesendet werden? Was soll damit erreicht werden, was jetzt nicht auch schon funktioniert?


mfG
gaw
 
OP
S

sEeEd

Newbie
genau dasselbe wie beim 2. link
ich will, das wenn sich ein freund in mein vpn netz einwählt ich mit ihm im lan spielen kann
aber nicht nur dass, ich bin auch einfach generell an der Lösung des Problems intressiert da ich so sicher noch einiges lernen kann =)

es handelt sich wie gesagt um haargenau daselbe probelm

PS. Es bringt auch nix wenn ich mich ins vpn einwähle da wie gesagt die source ip falsch ist und desshalb die broadcasts wohl verworfen werden als weitergeleitet zu werden.
 
OP
S

sEeEd

Newbie
ok ich hab mir jetzt bcrelay alleine mal runtergeladn und die broadcasts werden weitergeleitet =)

das heisst wenn ich jetzt einen game server eröffne der broadcasts ausschickt können die clients zu mir connecten =)

umgekehrt geht es leider nicht da wie gesagt die source ip nicht stimmt

und ich hab auch grad schon ne idee wie ich das mit dem snat hinbekomme
 

gaw

Hacker
Ähnlich wie das in dem Forum schon anklang, sind Broadcasts vermutlich nicht des Rätsels Lösung wenn das Spiel nicht läuft. Generell weiß ich das nicht, weil ich kein Zocker bin und daher kaum alle Spiele kenne. Soweit ich aber für diese besonderen Bedürfnisse Firewalls angepasst habe ist es mir bisher noch nocht untergekommen dass dazu die Weiterreichung von Broadcasts unabdingbar sind. Um welches Spiel handelt es sich denn, dass solche Forderungen stellt?

Für eine normale Server/Client Interaktion benötigt man auch keine Rundrufe. Nur wenn du das definierst, lässt sich nach einer spezifischen Lösung suchen.

Ansonsten kannst du mit iptables natürlich ankommende Pakete ummodeln, dazu ist eine einfacher Befehlsaufruf notwendig. Wie gesagt die meisten Firewallskripte machen genau das Gegenteil, sie blocken die Broadcasts


mfG
gaw
 
OP
S

sEeEd

Newbie
naja bei diablo2 war es zb möglich direkt die ip des game servers anzugeben

leider ist das bei neueren spielen wie siedler 5 oder warcraft 3 nicht mehr möglich
hier senden clients bzw server broadcasts aus auf die klarerweise server bzw clients eben warten...
ich denke es sollte nun klar sein warum ich diese broadcasts brauche.

das mit dem iptables aufruf ist aber anscheinend garnicht so einfach

ich habe vor im ip-up bzw down script vom pptpd folgende zeilen einzufügen:
Code:
up:
iptables -t nat -A POSTROUTING -i $INTERFACE -j SNAT --to-source $REMOTEIP

down:
iptables -t nat -D POSTROUTING -i $INTERFACE -j SNAT --to-source $REMOTEIP

das problem ist leider das -i beim nat nur bei PREROUTING funktioniert, im PREROUTING kann ich allerdings kein SNAT verwenden :(
würde ich statt -i <if> -src ! 10.4.1.0/24 verwenden würde die regel auf jeden client reagieren und alle würden diesselbe source ip bekommen...
 
OP
S

sEeEd

Newbie
hmm ich habs vor ner stunde ca. zu testzwecken selber einen eintrag gemacht ähnlich deinem vorschlag
aber auch wenn ich direkt die source eingebe mag er komischerweise ned o_O
ich hab alles versucht direkte source(original ip) not richtiges netz einmal ohne bedingungen und einmal sogar masquerading...
hat alles nichts genutzt
 
OP
S

sEeEd

Newbie
mit er meinte ich iptables :p
und o_O is halt wie wenn du erstaunt die augenbrauen hochziehst oder so
musst dir halt mit bisl fantasie anschaun

ich hab mir auch bissl den sourcecode von bcrelay angeschaut
is garnedmal so viel
ich hab zwar nur wenig ahnung von c++ aber ich werd mal versuchn es so umzuschreibn das die richtige source ip abgesendet wird

mir is nämlich noch was eingefallen
und zwar nimmt bcrelay die udp packet an und sendet sie dann selber weiter
das hat natürlich nichts mehr mit routing des kernels zu tun und somit sind bei iptables versuche mit -o pppX oder -i pppX eigentlich sinnlos
 

gaw

Hacker
Das ist das was ich dir die ganze Zeit zu erklären versuche. Ein Relay-Agent arbeitet im Grunde ähnlich wie ein Proxy er schreibt einfach neue Pakete, wenn eins ankommt und übergibt nur den Inhalt. Du kannst es natürlich selbst versuchen. Btw, bist du sicher dass Siedler 5 und warcraft nur mit broadcasts arbeiten? Das würde je bedeuten, dass sie als reine LAN-Spiele konzipiert wurden. Ich meine mir kann es egal sein, weil ich beschäftige mich nicht damit, aber das wäre imho etwas seltsam, weil es die Attraktivität für ächte Zocker doch erheblich senkt, oder nicht?


mfG
gaw
 
OP
S

sEeEd

Newbie
und natürlich bin ich mir sicher =)
als ich das erste mal die broadcasts im windows sniffer sah war ich schon am verzweifeln...
und ja das senkt die Attraktivität extrem.....
aber anscheinend arbeiten alle neuen spiele nach dem prinzip
ich schätze mal das ist so damit die versch. Portale der spiele hersteller auch genutzt werden wie zb. das battle net.

ps. es wäre toll wenn auch mal jemand anders als gaw mal ideen posten würde....
 

olox

Newbie
klink mich hier ma ein :),

hab leider auch das problem das Broadcasts in meinem VPN nicht ankommen wo sie sollten.
Folgende Situation :

Fli4l 2.0.8 Router als VPN Server /Samba+DNS+WinsServer

Interne Netzwerkrange 192.168.0.xxx

Vpnrange 192.168.0.xxx

Nach der Einwahl von Windowsclient alles wunderbar,Netzwerkumgebung Rechner zu sehn , Ping , Trace alles geht :)

Nun fix Herr der Ringe gestartet und in der Lan-Lobby ein Spiel erstellt :)

Ja nur leider weder Spieler noch erstelltes Spiel zu sehn ...

Hab also Netzwerksniffler angemacht und Lan lobby betreten..

Broadcasts gehn zwar wunderbar von 192.168.0.101:8086 auf 255.255.255.255:8086 raus aber es kommen keine Anfragen vom Vpn-client am Gameserver an.

Habe auch schon bcrelay aufm fli4l drauf und Port 8086 *relayed*
Nix...

seltsam is das der broadcast auch die ports von 8086-8093 benutzt, sieht also so aus

Source Destination Pr. SourceP. Dest.Port
192.168.0.101 255.255.255.255 UDP 8086 8086

Source Destination Pr. SourceP. Dest.Port
192.168.0.101 255.255.255.255 UDP 8086 8087

Source Destination Pr. SourceP. Dest.Port
192.168.0.101 255.255.255.255 UDP 8086 8088

(laufen zeitlich auch alle nacheinander)

und das halt weiter bis Dest. Port 8093

Naja mal im internen Lan ein Spiel aufgemacht und gesniffelt ..

da war dann noch erfolgreichen Connecten eines Lan-Clients folgender Eintrag im sniffler zu sehn

Source Destination Pr. SourceP. Dest.Port
192.168.0.101 192.168.0.106 UDP 8086 8094

Also *unterhalten* die sich dann im spiel auf port 8094

Na ich werd mal den Port auch relayen...

Wobei ich vermute das es an den windowsclients liegt , wie hier schon mal geschrieben:

denke das windoof einfach die interne ip adresse zum broadcasten benutzt und die vpn-ip aussen vorbleibt ...

evtl könnte mann ja ein route befehl ausführen ?

hab da ma was gelesen so in form route add 192.168.0.0 mask 255.255.255.0 192.168.100.vpn ip ...

sozusagen mit aller gewalt :)
würd ja so gerne weiterrumconfigen aber meine kumpels sind schon alle genervt...lol*
 

olox

Newbie
Auf den Windows clients die auf dem Gameserver connecten wollen , denke ich, ist aber wie gesagt nur eine idee
 

Ironcraft

Newbie
Hi,

nach langem Leidensweg bzgl. Broadcasts und VPN geb ich auch mal meine Best-Practice dazu ab, wenn ich darf :D

Die beste Möglichkeit um das Broadcast - Problem bei VPNs zu umgehen - ohne irgendwelche Relay-Agents zu benötigen, die meistens eh nicht funktionieren - ist der Betrieb von OpenVPN.
(http://openvpn.sourceforge.net/, Version 2.0)

Warum sollen nun Broadcasts mit OpenVPN funktionieren, wird man sich fragen ? OpenVPN kann im Bridged - Modus betrieben werden, dh. ALLE Clients befinden sich im gleichen Subnetz. Broad/Multicasts werden problemlos übertragen, am einfachsten daran zu erkennen, dass die NetBIOS - Namensauflösung von Windows/Samba funktioniert.
OpenVPN ist relativ einfach zu konfigurieren, sicherer als PPTP da mit SSL/TLS/RSA gearbeitet wird und hat ebenso keine Probleme mit NAT wie sie IPSec/L2TP hat. Zusätzlich lässt sich der Aufbau mit Zertifikaten realisieren, die sich auch auf eine Sperrliste setzen lassen. Die Geschwindigkeit ist recht ordentlich, es wird nur 1 UDP oder TCP-Port am Server benötigt, Echtzeit-Komprimierung, klappt auch mit DHCP-Clients, NAT, simpel zu installierender Windows-Client, uvm. Ich kann es nur empfehlen.

Und das Problem, dass Windows nicht die IP des VPN-Adapters verwendet lässt, wenn es Broadcasts schickt, sich auch umgehen.

Gruss
Thomas
 

olox

Newbie
Jo open VPN is ne gute Sache, hab auch schon viel gutes von dem Server gehört/gelesen .
hatte auch schon mal nen versuch gestartet der dann im sande verlief weil die configs nicht ohne sind!!!

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

und das zweite prob war das ich und mein kumpel jeweils ein fli4l router vor dem windows haben und dadurch wieder probleme entstehen.

Desweiteren wollt ich mal loswerden das mein fli4l auch bridged* ist , heisst alle im gleichen subnetz .

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 ?


steine steine steine ...

naja hab gesehn das es jetzt auch openvpn für fli4l gibst , aber leider nur für die entwickler version...

naja wenn du zeit hast Ironcraft dann poste doch ma bidde deine config von openvpn für beide verbindungen , vielleicht blick ich ja was ich falsch gemacht habe...


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.

:)
 

gaw

Hacker
OpenVPN im normalen Tunnelbetrieb einzurichten ist eine relativ einfache Sache, wesentlich einfacher als zum Beispiel ipsec.

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. 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.

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.

Die Frage ist sicherlich auch, ob man Spiele unterstützen sollte die die Netzlast mit unsinnigen Broadcastabfragen belasten. Oder ob es sinnvoll ist, Spiele die auf schnelle Pingzeiten und/oder großen Transfervolumen angewiesen sind unbedingt übers Internet spielen muss. 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. ;)


mfG
gaw
 
Oben