Die Markierung des VPN-Ports priorisiert keine Sprachanrufe
Die Markierung des VPN-Ports als Priorität hebt Anruf und Sicherung im selben Tunnel hervor. Sprache braucht Klassifizierung vor der Verschlüsselung und eine Warteschlange, die Sie kontrollieren.
Den UDP-Port des VPN als hohe Priorität zu markieren ist die häufigste QoS-Änderung für Sprache, und sie trennt einen Anruf nicht von der Dateiübertragung, die denselben Tunnel nutzt. Beide Flüsse verlassen denselben verschlüsselten Socket. Die Markierung sagt dem nächsten Hop, dass alles gleich wichtig ist, was dasselbe ist, als würde man ihm nichts sagen. Was einen Anruf schützt, ist eine vertrauenswürdige Klassifizierung vor der Verschlüsselung plus eine Warteschlange, die Sie tatsächlich kontrollieren.
Der Tunnel verbirgt den Fluss, den Sie klassifizieren wollten
Die Verschlüsselung ersetzt die inneren Header durch einen äußeren Header pro Tunnel. Danach zeigen Sprache und Sicherungsverkehr dieselbe Quelle, dasselbe Ziel und denselben Transportport, sodass ein Klassifizierer, der am Tunnelport ansetzt, sie nicht unterscheiden kann. Was auch immer Sie bevorzugen, Sie bevorzugen es pauschal.
Ein DSCP-Wert, den die Ursprungsanwendung setzt, überlebt nur, wenn ihn etwas nach außen kopiert. OpenVPN 2.6 hat passtos, dokumentiert mit IPv4-Gültigkeit; IPsec wendet an der Tunnelgrenze seine eigene Kopier- oder Mapping-Richtlinie an. Ohne diesen Schritt wird das äußere Paket mit dem Standard markiert, den die Tunnelschnittstelle verwendet, und die Warteschlange weiter unten erfährt nie, dass ein Anruf darin steckt.
Kopierte Markierungen verdienen dasselbe Misstrauen wie jeder vom Client gelieferte Wert. Eine Workstation kann für einen Sicherungsjob beschleunigte Weiterleitung beanspruchen, deshalb gehören Zulassung und Neumarkierung an der Vertrauensgrenze ins Design, bevor der Markierung geglaubt wird.
Priorität zählt nur dort, wo die Warteschlange entsteht
Ein gesättigter Uplink macht aus einem guten Codec eine roboterhafte Stimme, und die Warteschlange, die sich füllt, sitzt meist im Zugangsgerät oder im Puffer des Anbieters. Den ausgehenden Pfad auf die nutzbare Rate zu formen, abzüglich Tunnel- und Link-Overhead, hält diese Warteschlange auf Hardware, die Sie verwalten, statt in fremdem Puffer.
Faires Queuing und aktives Warteschlangenmanagement helfen auch ohne Sprachklasse, weil sie verhindern, dass ein Massenfluss den Puffer füllt. CAKE unter Linux bündelt Formung, Fairness pro Fluss und optionale Diffserv-Klassen in einem qdisc, und der eingesetzte Netzwerkmanager sollte diese Konfiguration besitzen statt eines zweiten konkurrierenden Queue-Setups. Ohne Formung wartet eine Klasse, die Massenverkehr übertrifft, trotzdem hinter einem Puffer, der bereits voll ist.
Die Behandlung eingehender Pakete ist nicht nutzlos, aber sie wirkt erst, nachdem das Paket die Empfangsstrecke passiert hat. Sie kann einen reagierenden Sender beeinflussen und kann bereits stromaufwärts verbrauchte Verzögerung nicht zurückerstatten, ist also eine Milderung und keine Garantie.
| Stage | What you can control | What to verify |
|---|---|---|
| Application to client | Which flows are trusted for marking | The marked packets are the ones you intended |
| Tunnel boundary | Whether the inner mark is copied outward | Outer header carries the expected value |
| Your uplink | Shaping rate and class treatment | Queue counters move for the voice class |
| Provider path | Almost nothing | Whether the service enforces the marking at all |
| Receiving side | Local policy after arrival | Delay that is already in the past |
Was im öffentlichen Internet überlebt
Die Diffserv-Architektur beschreibt die Behandlung innerhalb administrativer Domänen, weshalb ein Anbieter eine Markierung an einer Grenze ignorieren oder umschreiben kann. Die Gegenbehauptung, jedes Netz entferne sie immer, ist ebenso unbelegt. Die ehrliche Frage ist, wozu dieser konkrete Pfad vertraglich verpflichtet und überwacht wird. Prüfen Sie das mit einer markierten Probe, statt eine Regel zu wiederholen, die Sie irgendwo gelesen haben.
Fragen Sie, was der Anbieter mit der Klasse tut, und messen Sie es dann. Eine Markierung, die erhalten, aber nicht eingeplant wird, ist Dekoration; ein Pfad, der plant, ohne die Markierung zu sehen, ist ein anderes Problem, und beide brauchen unterschiedliche Korrekturen.
Ein Messplan, der die Stufe isoliert
Führen Sie einen gewöhnlichen Anruf mit einem kontrollierten konkurrierenden Upload durch und wiederholen Sie ihn über eine kabelgebundene Strecke. Schauen Sie, was der Anruf verloren hat, was die Klassenzähler aufgezeichnet haben und wie nah die Schnittstelle an ihrer echten Grenze läuft statt an der beworbenen Rate des Tarifs.
tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.netBleibt der Zähler der Sprachklasse auf null, sind Klassifizierung oder Markierungskopie defekt, und keine Priorität hilft. Bewegt sich der Klassenzähler lokal, während die Verzögerung weiter steigt, liegt der Engpass jenseits Ihres Gateways. Keines der beiden Ergebnisse wird durch einen höheren Prioritätswert behoben.