inf1d3l
Goto Top

VOIP über VPN

Moin Dudes,

unsere MA verbinden sich über IPSec VPN mit der Firma (Vollzugriff) und telefonieren über Swyx/Netphone, also Softphone. Wie sieht es hier mit Priorisierung aus, die VOIP-Pakete werden doch in IPSec-Pakete verpackt, DSCP bringt hier dann gar nix (?), zumindest für die Strecke vom Client zur Firma? Man kann aber innerhalb des Tunnels priorisieren (der VPN-Client ist NCP). Jemand Erfahrung damit?

Merci

Content-Key: 648538

Url: https://administrator.de/contentid/648538

Ausgedruckt am: 29.03.2024 um 06:03 Uhr

Mitglied: aqui
aqui 05.02.2021 aktualisiert um 12:12:20 Uhr
Goto Top
Innerhalb es Tunnel ist ja schon priorisiert, denn deine VoIP Frames der MAs darin haben ganz sicher ein Layer 3 DSCP Setting ! Wirst du dir sicher mit dem Wireshark auch schon einmal angesehen haben ?! Hier im Beispiel das auch für Voice typische ToS 48
dscp
Das Problem ist aber das der Router in den Tunnel "reinsehen" muss um diese DHCP Werte zu lesen. Das können logischerweise nur die Tunnelendpoint Firewalls/Router, denn alle Beteiligten die dazwischen liegen können das wegen der Verschlüsselung logischerweise nicht. Welcher VPN Client ist dabei unerheblich.
Die VPN Pakete selber zu priorisieren macht aus 2 Gründen wenig Sinn:
  • Es würde dann jeglicher VPN Traffic priorisiert also auch solcher ohne Voice Content
  • Am Providernetz ist so oder so mit aller Priorisierung Schluss, denn Provider resetten diese Bits zwangsweise alle auf 0 sowohl im L2 als auch L3 Mode. Logisch, denn sonst könnte man sich einen Vorteil in seinem Netz verschaffen ohne dafür zu zahlen.
Das sind also schon mal deine Rahmenbedingungen. face-wink
Mitglied: Inf1d3l
Inf1d3l 05.02.2021 um 12:22:17 Uhr
Goto Top
Alles Klar. Swyx markiert übrigens mit EF 46 / 0x2E: https://service.swyx.net/hc/de/articles/360000007840-Unterst%C3%BCtzung- ...

Was mich interessieren würde, ist, ob jemand praktische Erfahrung (sprich Verbesserung) mit der QoS-Einstellung im NCP-Client gesammelt hat.
Mitglied: aqui
aqui 05.02.2021 um 12:41:37 Uhr
Goto Top
Auch wenn du im NCP Client die VPN Frames priorisierst besagt das noch nichts wenn diese MA mobil unterwegs sind. Der lokale Router (was auch immer das ist) der ihren VPN Traffic dann ins Internet bringt muss zwangsweise dann ein DSCP Honoring machen, sprich also überhaupt die ToS Bits lesen können und je nach lokaler QoS Policy entscheiden was er damit bzw. dem spezifischen ToS Wert macht (es gibt derer 64). Alle billigen Consumer Router, teathering Smartphones und auch sonstige Router/Firewalls ignorieren das wenn dort keine solche Policy definiert ist. Es wird dann also vermutlich egal sein was du da einstellst weil in den meisten Fällen einer mobilen Infrastruktur diese Settings eh ignoriert werden. Und wie bereits gesagt...spätestens am Internet Port dieses Routers ist dann so oder so Schluss mit jeglichem QoS weil der Provider das gleich abschneidet.
Nur das du das auf dem Radar hast bei deinen Überlegungen ! face-wink
Mitglied: Inf1d3l
Inf1d3l 05.02.2021 aktualisiert um 13:12:05 Uhr
Goto Top
Das ist schon klar. Hier geht es um die Priorisierung innerhalb des Tunnels. Beispiel: Ein stabiler VPN-Tunnel mit 20 Mbit/s. MA telefoniert und fängt an, Dateien hin und her zu kopieren (vom Laptop oder auf den Laptop). Der Kopiervorgang soll aber nicht die Bandbreite vom Voice-Traffic klauen...
Mitglied: aqui
aqui 05.02.2021 aktualisiert um 14:25:21 Uhr
Goto Top
Das ist dann eine Herausforderung und ein Problem des Task Schedulers im Client selber. Hat dann aber eher weniger was mit dem Netzwerk an sich zu tun.
Da muss der Client Rechner dann wissen und entscheiden was er von welcher Applikation bevorzugen soll zudem muss er im Congestion Fall wissen ob Voice Daten übertragen werden oder nicht um die Bandbreite zu reservieren. Und dann ist ein sehr entscheidender Faktor ob der NCP VPN Client im Split Tunneling oder im Redirect Mode rennt. Beim Redirect wird das doppelt schwierig weil ja der gesamte Datentraffic des Clients dann in den Tunnel wandert und nicht nur Firmen relevanter Traffic wie beim Split Tunneling.
Das erfordert recht tiefe Eingriffe in den Task Scheduler des jeweiligen Betriebssystemes und es ist per se fraglich ob der NCP Client sowas allein leisten kann als externe Software die niemals so tief im System verankert ist wie der bordeigene VPN Client. Z.B. ein Grund mehr um bordeigene VPN Clients zu bevorzugen.
Mitglied: Inf1d3l
Inf1d3l 05.02.2021 aktualisiert um 14:54:56 Uhr
Goto Top
Der NCP-Client installiert eigene Netzwerk-Adapter (der bordeigene Client macht auch nix anderes) und tunnelt den gesamten Traffic. Ich denke, die QoS-Option gibt es nicht umsonst in dem Client. Die Möglichkeiten vom bordeigenen VPN sind begrenzt - kann z.B. kein XAUTH. Bei uns werden Laptops hin und her gereicht, und da ist es wichtig zu wissen, wer sich wann angemeldet hat.
Mitglied: aqui
aqui 05.02.2021 um 15:04:15 Uhr
Goto Top
Der NCP-Client installiert eigene Netzwerk-Adapter
Das macht jeder VPN Client so...
und tunnelt den gesamten Traffic.
Gateway Redirect also und kein übliches Split Tunneling. OK, das hat dann in der Tat den Vorteil das der Client dann vermutlich Traffic unterscheiden kann. Man muss ihm dann nur Voice Traffic entsprechend klassifizieren lassen, da hast du Recht. Wenn der NCP Client das kann klappts natürlich. face-wink