Én tc-shaper begrænser ikke hver VPN-klient af sig selv

Instruksen lyder komplet: begræns hver VPN-klient til 20 Mbit/s. Den er ikke komplet, og én enkelt kødisciplin på tunnelegrænsefladen leverer det ikke. Pr. klient kan betyde pr. tunneladresse, pr. enhed eller pr. konto, og hvert valg klassificerer pakker forskelligt. Inden du skriver nogen regel, skal du afgøre, hvilken af dem kravet egentlig nævner.

Alt nedenfor handler om afstanden mellem den sætning og noget, der virker.

Hvad »pr. klient« først skal betyde

En tunneladresse er let at klassificere og let at genbruge. En enhed er sværere, fordi én konto kan bære flere, og en enhed kan have flere adresser, især med IPv6. For en fairnesspolitik er kontoen den mest meningsfulde enhed og den sværeste at få øje på i en pakkehoved. Hver definition indebærer sin egen tællenøgle, så en politik, der driver mellem dem, gør ikke det, beskrivelsen hævder.

Retning er det andet manglende ord. Upload, download og kombineret er tre forskellige krav, og én enkelt udgående regel på én grænseflade dækker sjældent begge veje.

Vælg et punkt, hvor klienten stadig er synlig

Hver retning defineres i forhold til en grænseflade. Det, der forlader serverens tunnel mod en fjern klient, tæller som download for den klient; det, en klient sender, går ind i tunnelen og forlader den derefter mod sin destination. Vælg et planlægningspunkt for hver retning, og spørg hvilke felter der findes der. Før kilde-NAT bærer en upload stadig klientens indre adresse; efter oversættelse kan et simpelt kildematch måske ikke længere identificere den.

På den krypterede vej tilhører hovederne VPN-transporten, så et filter, der matcher indre adresser, har intet at matche. Et design kan klassificere tidligere og give et mærke videre til en senere planlægger, men den overdragelse skal være bevidst: pakkemærker, forbindelsesmærker og planlæggerklasser er forskellig tilstand, ikke én værdi, der sendes videre.

Spande opstår ikke af sig selv

En token-spand knyttet til en grænseflade former den trafik, der bruger den; den laver ikke en ny spand pr. kildeadresse. Et klassebaseret design sorterer i stedet den valgte trafik i klasser, filtre afgør medlemskab, og HTB-manualen adskiller en klasses hastighed fra dens loft, når forælderen har ledig båndbredde. Hvis hensigten er et hårdt loft, sæt loftet og beslut låneadfærden med vilje; behandl ikke hvert hastighedstal som et absolut maksimum.

Når kravet er pr. klient, bør et par overførsler, der kører samtidigt, dele én kvote. At give hver strøm den fulde hastighed er en anden politik, og den overlever enhver test, der kun ser én download.

To enheder, én konto, én kvote?

At begrænse to enhedsadresser hver for sig lægger sig aldrig sammen til én kvote på kontoniveau, selv når begge enheder logger ind som samme person. Det samme gælder et helt LAN oversat bag én peer, eller yderligere IPv6-adresser, som klassificeringen aldrig forventede. Hold adresse-til-identitet-koblingen opdateret, og husk, at en stabil adresse forenkler kortet uden at autentificere ejeren.

Definér også burst- og køadfærd. Token-spande tillader korte bursts over gennemsnittet, og buffering tilføjer forsinkelse; at begrænse overskud og sætte det i kø til senere er forskellige beslutninger med forskellige symptomer.

Kør to overførsler fra én klient, tilføj en anden klient, og læs klasse-tællerne i hver retning for at validere.