Ein einzelner tc-Shaper begrenzt nicht jeden VPN-Client für sich

Die Anweisung klingt vollständig: begrenze jeden VPN-Client auf 20 Mbit/s. Sie ist es nicht, und eine einzelne Warteschlangendisziplin auf der Tunnelschnittstelle liefert das nicht. Pro Client kann pro Tunneladresse, pro Gerät oder pro Konto bedeuten, und jede Wahl klassifiziert Pakete anders. Bevor Sie eine Regel schreiben, entscheiden Sie, welche davon die Anforderung tatsächlich nennt.

Alles Folgende betrifft den Abstand zwischen diesem Satz und etwas, das funktioniert.

Was „pro Client“ zuerst bedeuten muss

Eine Tunneladresse ist leicht zu klassifizieren und leicht wiederzuverwenden. Ein Gerät ist schwieriger, weil ein Konto mehrere tragen kann und ein Gerät mehrere Adressen halten kann, besonders mit IPv6. Für eine Fairness-Richtlinie ist das Konto die sinnvollste Einheit und die am schwersten im Paketkopf zu erkennende. Jede Definition bringt ihren eigenen Zählschlüssel mit, also wird eine Richtlinie, die zwischen ihnen schwankt, nicht leisten, was die Beschreibung behauptet.

Richtung ist das zweite fehlende Wort. Upload, Download und kombiniert sind drei verschiedene Anforderungen, und eine einzelne Ausgangsregel auf einer Schnittstelle deckt selten beide Wege ab.

Wählen Sie einen Punkt, an dem der Client noch sichtbar ist

Jede Richtung wird gegen eine Schnittstelle definiert. Was den Tunnel des Servers in Richtung eines entfernten Clients verlässt, zählt für diesen Client als Download; was ein Client sendet, betritt den Tunnel und verlässt ihn dann Richtung Ziel. Wählen Sie für jede Richtung einen Planungspunkt und fragen Sie, welche Felder dort existieren. Vor dem Quell-NAT trägt ein Upload noch die innere Adresse des Clients; nach der Übersetzung kann ein einfacher Quellabgleich ihn möglicherweise nicht mehr identifizieren.

Auf dem verschlüsselten Pfad gehören die Kopfzeilen zum VPN-Transport, ein Filter auf innere Adressen hat dort also nichts zu treffen. Ein Entwurf kann früher klassifizieren und eine Markierung an einen späteren Scheduler übergeben, doch diese Übergabe muss bewusst geschehen: Paketmarken, Verbindungsmarken und Scheduler-Klassen sind unterschiedlicher Zustand, nicht ein weitergegebener Wert.

Eimer entstehen nicht von selbst

Ein Token-Eimer an einer Schnittstelle formt jeden Verkehr, der ihn nutzt; er erzeugt nicht pro Quelladresse einen frischen Eimer. Ein klassenbasierter Entwurf sortiert stattdessen ausgewählten Verkehr in Klassen, Filter entscheiden über die Zugehörigkeit, und das HTB-Handbuch trennt die Rate einer Klasse von ihrer Obergrenze, wenn der Elternteil freie Bandbreite hat. Ist eine harte Grenze gemeint, setzen Sie die Obergrenze und entscheiden Sie das Leihverhalten bewusst; behandeln Sie nicht jede Ratenzahl als absolutes Maximum.

Wenn die Anforderung pro Client gilt, sollten zwei gleichzeitig laufende Übertragungen eine einzige Quote teilen. Jeder Strömung die volle Rate zu geben ist eine andere Richtlinie, und sie besteht jeden Test, der nur einen Download beobachtet.

Zwei Geräte, ein Konto, eine Quote?

Zwei Geräteadressen getrennt zu begrenzen summiert sich nie zu einer kontoweiten Quote, selbst wenn sich beide Geräte als dieselbe Person anmelden. Dasselbe gilt für ein ganzes LAN, das hinter einem Peer übersetzt wird, oder für zusätzliche IPv6-Adressen, die der Klassifizierer nie erwartet hat. Halten Sie die Zuordnung von Adresse und Identität aktuell, und denken Sie daran, dass eine stabile Adresse die Zuordnung vereinfacht, ohne ihren Besitzer zu authentifizieren.

Definieren Sie auch Burst- und Warteschlangenverhalten. Token-Eimer erlauben kurze Bursts über dem Durchschnitt, und Puffern fügt Verzögerung hinzu; Überschuss zu polizieren und ihn später einzureihen sind verschiedene Entscheidungen mit verschiedenen Symptomen.

Starten Sie zur Validierung zwei Übertragungen von einem Client, fügen Sie einen zweiten Client hinzu und lesen Sie die Klassenzähler in jede Richtung.