6
Lync-Traffic über separate WAN-Schnittstelle leiten?
Hallo zusammen,
in einem Microsoft-Netzwerk mit 10 Mitarbeitern existiert momentan eine ADSL-Leitung, über die ein Exchange-Mailserver und Internetanfragen der Mitarbeiter laufen.
Nun soll auch Microsoft Lync zum Einsatz kommen. Dafür wurde eine zweite SDSL-Standleitung bestellt, um in beide Richtungen genügend Bandbreite zu haben. Der Lync-Client ist auf den einzelnen Mitarbeiter-PCs installiert, unter Windows 7.
Die Rechner hängen an einem Windows SBS 2008.
Der Lync-Server ist ein Microsoftdienst im Internet, es wird also kein eigener Lync-Server betrieben.
Ziel ist es, dass Lync möglichst ruckelfrei läuft, egal wieviel Verkehr gerade für andere Zwecke entsteht.
Meine Ideen dazu sind folgende:
1)
Kanalbündelung beider Leitungen, Traffic-Priorisierung (QoS?) für Lync, sodass Lync-Traffic Vorrang hat.
2)
Traffic-Trennung: Internet und Mail gehen über ADSL (WAN1), Lync über SDSL (WAN2).
zur 1. Lösung konkret die Frage:
wird die Priorisierung an den Clients eingestellt, oder am Router, oder an beiden Stellen?
zur 2. Lösung konkret die Frage:
Gehe ich richtig in der Annahme, dass dafür eine anwendungsbasierte Firefall erforderlich ist? Denn die Ports (z.B. SSL/443) werden ja auch für andere Dienste wie Internet und E-Mail benutzt - da müsste man ja schon die Pakete analysieren und dementsprechend auf WAN1 oder WAN2 leiten.
Die Frage ist nun, welche Lösung die bessere und günstigere ist, und wie die beiden Lösungen umgesetzt werden müssten.
Vielen Dank vorab!
in einem Microsoft-Netzwerk mit 10 Mitarbeitern existiert momentan eine ADSL-Leitung, über die ein Exchange-Mailserver und Internetanfragen der Mitarbeiter laufen.
Nun soll auch Microsoft Lync zum Einsatz kommen. Dafür wurde eine zweite SDSL-Standleitung bestellt, um in beide Richtungen genügend Bandbreite zu haben. Der Lync-Client ist auf den einzelnen Mitarbeiter-PCs installiert, unter Windows 7.
Die Rechner hängen an einem Windows SBS 2008.
Der Lync-Server ist ein Microsoftdienst im Internet, es wird also kein eigener Lync-Server betrieben.
Ziel ist es, dass Lync möglichst ruckelfrei läuft, egal wieviel Verkehr gerade für andere Zwecke entsteht.
Meine Ideen dazu sind folgende:
1)
Kanalbündelung beider Leitungen, Traffic-Priorisierung (QoS?) für Lync, sodass Lync-Traffic Vorrang hat.
2)
Traffic-Trennung: Internet und Mail gehen über ADSL (WAN1), Lync über SDSL (WAN2).
zur 1. Lösung konkret die Frage:
wird die Priorisierung an den Clients eingestellt, oder am Router, oder an beiden Stellen?
zur 2. Lösung konkret die Frage:
Gehe ich richtig in der Annahme, dass dafür eine anwendungsbasierte Firefall erforderlich ist? Denn die Ports (z.B. SSL/443) werden ja auch für andere Dienste wie Internet und E-Mail benutzt - da müsste man ja schon die Pakete analysieren und dementsprechend auf WAN1 oder WAN2 leiten.
Die Frage ist nun, welche Lösung die bessere und günstigere ist, und wie die beiden Lösungen umgesetzt werden müssten.
Vielen Dank vorab!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 195768
Url: https://administrator.de/contentid/195768
Printed on: April 25, 2024 at 23:04 o'clock
6 Comments
Latest comment
Antwort 1:
Das kommt darauf an. Du willst vermutlich intern nicht priorisieren sondern nur auf der WAN Strecke. Folglich reicht es dann vollkommen wenn du das auf dem Router machst.
Bedenke aber das eine Link Bündelung so wie du es vorhast mit 2 separaten Routern technisch nicht möglich ist !
Wenn, dann muss das ein Dual (oder n mal) WAN Port Router sein, also ein Gerät was beide WAN Ports bedient.
Antwort 2:
Nein, da gehst du nicht oder nur halb richtig in der Annahme. Jeder nur etwas bessere Router kann ein Accesslisten basiertes Policy Base Routing machen bis Layer 4 der dann ebenso den Traffic differenzieren kann auf den Links.
Böse wird es nur wenn Lync auch Standard Ports wie 443 nutzt, denn dann musst du logischerwesie in den Content also in Layer über 4 sehen. Das kann kein Router mehr und auch keine Feld- Wald- und Wiesen Firewall, denn dafür benötigst du einen Content (Application) Switch oder einen Content based Firewall die dann auch ihren entsprechenden Preis hat den Content analyse macht man nicht mit einer Popel Consumer Hardware in Echtzeit.
Günstiger kommt dir dann Lösung 1
Generell sind aber beide Optionen machbar.
Das kommt darauf an. Du willst vermutlich intern nicht priorisieren sondern nur auf der WAN Strecke. Folglich reicht es dann vollkommen wenn du das auf dem Router machst.
Bedenke aber das eine Link Bündelung so wie du es vorhast mit 2 separaten Routern technisch nicht möglich ist !
Wenn, dann muss das ein Dual (oder n mal) WAN Port Router sein, also ein Gerät was beide WAN Ports bedient.
Antwort 2:
Nein, da gehst du nicht oder nur halb richtig in der Annahme. Jeder nur etwas bessere Router kann ein Accesslisten basiertes Policy Base Routing machen bis Layer 4 der dann ebenso den Traffic differenzieren kann auf den Links.
Böse wird es nur wenn Lync auch Standard Ports wie 443 nutzt, denn dann musst du logischerwesie in den Content also in Layer über 4 sehen. Das kann kein Router mehr und auch keine Feld- Wald- und Wiesen Firewall, denn dafür benötigst du einen Content (Application) Switch oder einen Content based Firewall die dann auch ihren entsprechenden Preis hat den Content analyse macht man nicht mit einer Popel Consumer Hardware in Echtzeit.
Günstiger kommt dir dann Lösung 1
Generell sind aber beide Optionen machbar.
Hallo!
Vielen Dank für die kompetente Antwort!
Bei Frage/Antwort2 meinten wir beide das gleiche - ich habe mich nur falsch ausgedrückt.
Kann man eine Content-Based-Firewall nicht als Softwarelösung mit ner Linuxkiste selbst umsetzen?
Oder wäre das zu großer Zauber?
Rücken wir mal Lösung 1 in den Fokus:
Klar ist, dass es sich um einen Dual-WAN-Router handeln muss, aber das ist eh geplant.
Aber auch da die Frage:
Wenn Lync und andere Anwendungen gleichzeitig z.B. Port 443 nutzen, wie greift dann die Priorisierung?
In meinem kleinen Universum stelle ich mir das so vor:
Wenn ich direkt am Client die Lync-Datenpakete schonmal für die WAN-Strecke als "Höchstpriorität" markiere, braucht der Router/die Firewall die fertig markierten Pakete nur noch annehmen und kann die dann vorrangig ins WAN weiterleiten.
Wenn die aber unmarkiert dort ankommen, woher weiss der Router dann, welche Pakete von Lync kommen und somit zu priorisieren sind?
Vielen Dank für die kompetente Antwort!
Bei Frage/Antwort2 meinten wir beide das gleiche - ich habe mich nur falsch ausgedrückt.
Kann man eine Content-Based-Firewall nicht als Softwarelösung mit ner Linuxkiste selbst umsetzen?
Oder wäre das zu großer Zauber?
Rücken wir mal Lösung 1 in den Fokus:
Klar ist, dass es sich um einen Dual-WAN-Router handeln muss, aber das ist eh geplant.
Aber auch da die Frage:
Wenn Lync und andere Anwendungen gleichzeitig z.B. Port 443 nutzen, wie greift dann die Priorisierung?
In meinem kleinen Universum stelle ich mir das so vor:
Wenn ich direkt am Client die Lync-Datenpakete schonmal für die WAN-Strecke als "Höchstpriorität" markiere, braucht der Router/die Firewall die fertig markierten Pakete nur noch annehmen und kann die dann vorrangig ins WAN weiterleiten.
Wenn die aber unmarkiert dort ankommen, woher weiss der Router dann, welche Pakete von Lync kommen und somit zu priorisieren sind?
Wenn Lync und andere Anwendungen gleichzeitig z.B. Port 443 nutzen und die die Priorisierung nur auf Portbasis machst dann gilt die Priorisierung für alle diese Pakete. Ist doch logisch.
Was sollte auch anderes passieren wenn der Router nur im Layer 4 auf den TCP Port sieht oder dachtest du da wär noch etwas "Magie" im Spiel ?? Du hast also Recht, das kann der Router nicht wissen !
Wenn, dann müsste man die ACL auf die Lync IPs UND den Port erweitern, dann filterst du dediziert NUR die Lync User raus und priorisierst nur die.
Ist aber ne Milchmädchenrechnung, denn wenn das ein PC ist greift auch das nicht. Da hast du also immer andere Anwendungen als Trittbrettfahrer.
Besser ist es dann in der Tat wenn die Applikation selber die Pakete klassifizieren kann. Sprich also das die Lync Applikation gleich selber eine DiffServ Priorisierung (DSCP Setting) macht.
Dann kannst du dediziert diese Pakete priorisieren am Router und das gilt dann einzig nur für Lync.
Winblows kann das aber m.E. nicht am Client, also fällt das also aus obwohl es das sinnvollste wäre.
Ggf. haben aber die Lync Pakete per se schon ein entsprechendes DSCP QoS Setting das müsste man aber in der Doku nachlesen..
Was sollte auch anderes passieren wenn der Router nur im Layer 4 auf den TCP Port sieht oder dachtest du da wär noch etwas "Magie" im Spiel ?? Du hast also Recht, das kann der Router nicht wissen !
Wenn, dann müsste man die ACL auf die Lync IPs UND den Port erweitern, dann filterst du dediziert NUR die Lync User raus und priorisierst nur die.
Ist aber ne Milchmädchenrechnung, denn wenn das ein PC ist greift auch das nicht. Da hast du also immer andere Anwendungen als Trittbrettfahrer.
Besser ist es dann in der Tat wenn die Applikation selber die Pakete klassifizieren kann. Sprich also das die Lync Applikation gleich selber eine DiffServ Priorisierung (DSCP Setting) macht.
Dann kannst du dediziert diese Pakete priorisieren am Router und das gilt dann einzig nur für Lync.
Winblows kann das aber m.E. nicht am Client, also fällt das also aus obwohl es das sinnvollste wäre.
Ggf. haben aber die Lync Pakete per se schon ein entsprechendes DSCP QoS Setting das müsste man aber in der Doku nachlesen..
Ah ok - dann werde ich das mal checken und dann feedback geben.
Vielen Dank für Deine Hilfe soweit!
Vielen Dank für Deine Hilfe soweit!
Für alle Mitleser - ich hab mich soweit durchgelesen, als dass es wohl mit Gruppenrichtlinien möglich ist, die Pakete von Lync zu priorisieren.
Hilfreiche Links:
http://technet.microsoft.com/en-us/library/gg405414%28v=ocs.14%29.aspx
http://www.msxfaq.de/uc/qoslync.htm
http://www.msxfaq.de/uc/qoswin.htm
Wenns läuft melde ich mich nochmal. Kann allerdings 2-3 Wochen dauern, bis ich dazu komme.
Vielen Dank nochmal an Peter soweit!
Hilfreiche Links:
http://technet.microsoft.com/en-us/library/gg405414%28v=ocs.14%29.aspx
http://www.msxfaq.de/uc/qoslync.htm
http://www.msxfaq.de/uc/qoswin.htm
Wenns läuft melde ich mich nochmal. Kann allerdings 2-3 Wochen dauern, bis ich dazu komme.
Vielen Dank nochmal an Peter soweit!
Feedback obs klappt wäre aber wirklich mal interessant dazu... !
