Én tc-shaper begrenser ikke hver VPN-klient av seg selv

Instruksen høres komplett ut: begrens hver VPN-klient til 20 Mbit/s. Den er ikke komplett, og én enkelt kødisiplin på tunnelegrensesnittet leverer det ikke. Per klient kan bety per tunneladresse, per enhet eller per konto, og hvert valg klassifiserer pakker ulikt. Før du skriver noen regel, må du avgjøre hvilken av dem kravet egentlig nevner.

Alt nedenfor handler om avstanden mellom den setningen og noe som virker.

Hva «per klient» først må bety

En tunneladresse er lett å klassifisere og lett å gjenbruke. En enhet er vanskeligere, fordi én konto kan bære flere, og en enhet kan ha flere adresser, særlig med IPv6. For en rettferdighetspolicy er kontoen den mest meningsfulle enheten, og den vanskeligste å få øye på i en pakkehode. Hver definisjon innebærer sin egen tellenøkkel, så en policy som driver mellom dem gjør ikke det beskrivelsen hevder.

Retning er det andre manglende ordet. Opplasting, nedlasting og kombinert er tre ulike krav, og én enkelt utregel på ett grensesnitt dekker sjelden begge veier.

Velg et punkt der klienten fortsatt er synlig

Hver retning defineres mot et grensesnitt. Det som forlater serverens tunnel mot en fjern klient, regnes som nedlasting for den klienten; det en klient sender, går inn i tunnelen og forlater den deretter mot målet. Velg et planleggingspunkt for hver retning og spør hvilke felt som finnes der. Før kilde-NAT bærer en opplasting fortsatt klientens indre adresse; etter oversettelse kan en enkel kildematch kanskje ikke lenger identifisere den.

På den krypterte veien tilhører hodene VPN-transporten, så et filter som matcher indre adresser har ingenting å matche. Et design kan klassifisere tidligere og gi et merke videre til en senere planlegger, men den overleveringen må være bevisst: pakkemerker, tilkoblingsmerker og planleggerklasser er ulik tilstand, ikke én verdi som sendes videre.

Bøttene dukker ikke opp av seg selv

En token-bøtte knyttet til et grensesnitt former all trafikk som bruker den; den lager ikke en ny bøtte per kildeadresse. Et klassebasert design sorterer i stedet valgt trafikk i klasser, filtre avgjør medlemskap, og HTB-håndboken skiller en klasses rate fra taket når forelderen har ledig båndbredde. Hvis hensikten er et hardt tak, sett taket og avgjør låneatferden med vilje; ikke behandle hvert ratetall som et absolutt maksimum.

Når kravet er per klient, bør et par overføringer som kjører samtidig dele én kvote. Å gi hver strøm full rate er en annen policy, og den overlever enhver test som bare ser én nedlasting.

To enheter, én konto, én kvote?

Å begrense to enhetsadresser hver for seg summerer seg aldri til én kontovide kvote, selv når begge enhetene logger inn som samme person. Det samme gjelder et helt LAN oversatt bak én peer, eller ekstra IPv6-adresser som klassifisereren aldri forventet. Hold adresse-til-identitet-koblingen oppdatert, og husk at en stabil adresse forenkler kartet uten å autentisere eieren.

Definer også burst- og køatferd. Token-bøtter tillater korte burst over gjennomsnittet, og bufring legger til forsinkelse; å politere overskudd og sette det i kø for senere er ulike beslutninger med ulike symptomer.

For å validere, kjør to overføringer fra én klient, legg til en annen klient, og les klassetellerne hver vei.