Éin tc-shaper avgrensar ikkje kvar VPN-klient av seg sjølv
Ei grense per klient krev ein teljeidentitet, to retningar og eit klassifiseringspunkt. Éin shaper på tunnelen er ikkje éin kvote per brukar.
Instruksen høyrest komplett ut: avgrens kvar VPN-klient til 20 Mbit/s. Han er ikkje komplett, og éin einaste kødisiplin på tunnelegrensesnittet leverer det ikkje. Per klient kan tyde per tunneladresse, per eining eller per konto, og kvart val klassifiserer pakkar ulikt. Før du skriv nokon regel, må du avgjere kva for ein av dei kravet eigentleg nemner.
Alt nedanfor handlar om avstanden mellom den setninga og noko som verkar.
Kva «per klient» først må tyde
Ei tunneladresse er lett å klassifisere og lett å bruke om att. Ei eining er vanskelegare, fordi éin konto kan bere fleire, og ei eining kan ha fleire adresser, særleg med IPv6. For ein rettferdspolicy er kontoen den mest meiningsfulle eininga, og den vanskelegaste å få auge på i ein pakkehode. Kvar definisjon inneber sin eigen teljenøkkel, så ein policy som driv mellom dei gjer ikkje det skildringa hevdar.
Retning er det andre manglande ordet. Opplasting, nedlasting og kombinert er tre ulike krav, og éin einaste utregel på eitt grensesnitt dekkjer sjeldan båe vegar.
Vel eit punkt der klienten framleis er synleg
Kvar retning er definert mot eit grensesnitt. Det som forlèt tunnelen til tenaren mot ein fjern klient, blir rekna som nedlasting for den klienten; det ein klient sender, går inn i tunnelen og forlèt han deretter mot målet. Vel eit planleggingspunkt for kvar retning og spør kva felt som finst der. Før kjelde-NAT ber ei opplasting framleis den indre adressa til klienten; etter omsetjing kan eit enkelt kjeldesamsvar kanskje ikkje lenger identifisere henne.
På den krypterte vegen høyrer hovuda til VPN-transporten, så eit filter som matchar indre adresser har ingenting å matche. Eit design kan klassifisere tidlegare og gje eit merke vidare til ein seinare planleggjar, men den overleveringa må vere medviten: pakkemerke, tilkoplingsmerke og planleggjar-klassar er ulik tilstand, ikkje éin verdi som blir send vidare.
Bøttene dukkar ikkje opp av seg sjølve
Ei token-bøtte knytt til eit grensesnitt formar all trafikk som brukar henne; ho lagar ikkje ei ny bøtte per kjeldeadresse. Eit klassebasert design sorterer i staden vald trafikk i klassar, filter avgjer medlemskap, og HTB-handboka skil farten til ein klasse frå taket når forelderen har ledig bandbreidde. Er hensikta eit hardt tak, set taket og avgjer låneåtferda med vilje; handsam ikkje kvart fartstal som eit absolutt maksimum.
Når kravet er per klient, bør eit par overføringar som køyrer samtidig dele éin kvote. Å gje kvar straum full fart er ein annan policy, og han overlever kvar test som berre ser éi nedlasting.
To einingar, éin konto, éin kvote?
Å avgrense to einingadresser kvar for seg summerer seg aldri til éin kontovid kvote, sjølv når båe einingane loggar inn som same person. Det same gjeld eit heilt LAN som blir omsett bak éin peer, eller ekstra IPv6-adresser som klassifiseraren aldri venta. Hald koplinga mellom adresse og identitet oppdatert, og hugs at ei stabil adresse gjer kartet enklare utan å autentisere eigaren.
Definer også burst- og køåtferd. Token-bøtter tillèt korte burst over gjennomsnittet, og buftring legg til forseinking; å politere overskot og setje det i kø for seinare er ulike avgjerder med ulike symptom.
For å validere, køyr to overføringar frå éin klient, legg til ein annan klient, og les klasseteljarane kvar veg.