Eén tc-shaper begrenst niet elke VPN-client vanzelf

De opdracht klinkt compleet: beperk elke VPN-client tot 20 Mbit/s. Dat is hij niet, en één enkele wachtrijdiscipline op de tunnelinterface levert dat niet. Per client kan per tunneladres, per apparaat of per account betekenen, en elke keuze classificeert pakketten anders. Beslis voordat je een regel schrijft welke ervan de eis werkelijk noemt.

Alles hieronder gaat over de afstand tussen die zin en iets dat werkt.

Wat «per client» eerst moet betekenen

Een tunneladres is makkelijk te classificeren en makkelijk te hergebruiken. Een apparaat is lastiger, omdat één account er meerdere kan dragen en een apparaat meerdere adressen kan hebben, vooral met IPv6. Voor een eerlijkheidsbeleid is het account de zinvolste eenheid, en de moeilijkst zichtbare in een pakketkop. Elke definitie veronderstelt zijn eigen telsleutel, dus beleid dat daartussen zweeft doet niet wat de beschrijving beweert.

Richting is het tweede ontbrekende woord. Upload, download en gecombineerd zijn drie verschillende eisen, en één uitgaande regel op één interface dekt zelden beide paden.

Kies een punt waar de client nog zichtbaar is

Elke richting wordt tegen een interface gedefinieerd. Wat de tunnel van de server verlaat richting een externe client telt als download voor die client; wat een client stuurt komt de tunnel in en verlaat hem daarna richting zijn bestemming. Kies per richting een planningspunt en vraag welke velden daar bestaan. Vóór bron-NAT draagt een upload nog het interne adres van de client; na vertaling kan een eenvoudige bronmatch het misschien niet meer identificeren.

Op het versleutelde pad horen de koppen bij het VPN-transport, dus een filter dat interne adressen matcht heeft niets om te matchen. Een ontwerp kan eerder classificeren en een mark doorgeven aan een latere scheduler, maar die overdracht moet bewust zijn: pakketmarkeringen, verbindingsmarkeringen en schedulerklassen zijn verschillende toestand, niet één doorgegeven waarde.

Emmer ontstaan niet vanzelf

Een token-emmer aan een interface vormt al het verkeer dat hem gebruikt; hij maakt geen nieuwe emmer per bronadres. Een klassegebaseerd ontwerp sorteert in plaats daarvan geselecteerd verkeer in klassen, filters bepalen lidmaatschap, en de HTB-handleiding scheidt de snelheid van een klasse van zijn plafond wanneer de ouder vrije bandbreedte heeft. Is de bedoeling een harde limiet, stel dan het plafond in en beslis het leengedrag bewust; behandel niet elk snelheidsgetal als een absoluut maximum.

Als de eis per client is, moeten twee gelijktijdige overdrachten één toewijzing delen. Elke stroom de volle snelheid geven is ander beleid, en het overleeft elke test die maar één download bekijkt.

Twee apparaten, één account, één toewijzing?

Twee apparaatadressen apart begrenzen telt nooit op tot één accountbrede toewijzing, zelfs niet als beide apparaten als dezelfde persoon inloggen. Hetzelfde geldt voor een heel LAN dat achter één peer wordt vertaald, of voor extra IPv6-adressen die de classificeerder nooit verwachtte. Houd de koppeling tussen adres en identiteit actueel, en onthoud dat een stabiel adres de kaart vereenvoudigt zonder de eigenaar te authenticeren.

Definieer ook burst- en wachtrijgedrag. Token-emmers staan korte bursts boven het gemiddelde toe, en buffering voegt vertraging toe; overtollig verkeer begrenzen en het later in de wachtrij zetten zijn verschillende beslissingen met verschillende symptomen.

Draai ter validatie twee overdrachten vanaf één client, voeg een tweede client toe en lees de klassetellers in elke richting.