En enda tc-shaper begränsar inte varje VPN-klient av sig själv

Instruktionen låter komplett: begränsa varje VPN-klient till 20 Mbit/s. Den är inte komplett, och en enda ködisciplin på tunnelgränssnittet levererar det inte. Per klient kan betyda per tunneladress, per enhet eller per konto, och varje val klassificerar paket olika. Innan du skriver någon regel måste du avgöra vilken av dem kravet egentligen nämner.

Allt nedan handlar om avståndet mellan den meningen och något som fungerar.

Vad «per klient» först måste betyda

En tunneladress är lätt att klassificera och lätt att återanvända. En enhet är svårare, eftersom ett konto kan bära flera och en enhet kan ha flera adresser, särskilt med IPv6. För en rättvisepolicy är kontot den mest meningsfulla enheten, och den svåraste att upptäcka i ett pakethuvud. Varje definition förutsätter sin egen räkningsnyckel, så en policy som driver mellan dem gör inte det beskrivningen påstår.

Riktning är det andra saknade ordet. Uppladdning, nedladdning och kombinerat är tre olika krav, och en enda utgående regel på ett gränssnitt täcker sällan båda vägarna.

Välj en punkt där klienten fortfarande syns

Varje riktning definieras mot ett gränssnitt. Det som lämnar serverns tunnel mot en fjärrklient räknas som nedladdning för den klienten; det en klient skickar går in i tunneln och lämnar den sedan mot sitt mål. Välj en planeringspunkt för varje riktning och fråga vilka fält som finns där. Före käll-NAT bär en uppladdning fortfarande klientens inre adress; efter översättning kan en enkel källmatchning kanske inte längre identifiera den.

På den krypterade vägen tillhör huvudena VPN-transporten, så ett filter som matchar inre adresser har inget att matcha. En design kan klassificera tidigare och lämna ett märke vidare till en senare schemaläggare, men den överlämningen måste vara medveten: paketmärken, anslutningsmärken och schemaläggarklasser är olika tillstånd, inte ett enda värde som skickas vidare.

Hinkarna dyker inte upp av sig själva

En tokenhink kopplad till ett gränssnitt formar all trafik som använder den; den präglar inte en ny hink per källadress. En klassbaserad design sorterar i stället vald trafik i klasser, filter avgör medlemskap, och HTB-handboken skiljer en klass hastighet från dess tak när föräldern har ledig bandbredd. Om avsikten är ett hårt tak, sätt taket och avgör lånebeteendet medvetet; behandla inte varje hastighetssiffra som ett absolut maximum.

När kravet är per klient bör ett par överföringar som körs samtidigt dela en enda kvot. Att ge varje flöde full hastighet är en annan policy, och den överlever varje test som bara tittar på en nedladdning.

Två enheter, ett konto, en kvot?

Att begränsa två enhetsadresser var för sig summerar aldrig till en kontobred kvot, även när båda enheterna loggar in som samma person. Samma sak gäller ett helt LAN som översätts bakom en enda peer, eller extra IPv6-adresser som klassificeraren aldrig väntade sig. Håll adress-till-identitet-kopplingen uppdaterad, och kom ihåg att en stabil adress förenklar kartan utan att autentisera ägaren.

Definiera också burst- och köbeteende. Tokenhinkar tillåter korta burstar över genomsnittet, och buffring lägger till fördröjning; att polisa överskott och sätta det i kö för senare är olika beslut med olika symptom.

För att validera, kör två överföringar från en klient, lägg till en andra klient och läs klasstäljarna i varje riktning.