Un singur shaper tc nu limitează singur fiecare client VPN

Instrucțiunea sună completă: limitează fiecare client VPN la 20 Mbit/s. Nu este completă, iar o singură disciplină de coadă pe interfața tunelului nu o va livra. Pe client poate însemna pe adresă de tunel, pe dispozitiv sau pe cont, iar fiecare alegere clasifică pachetele altfel. Înainte de a scrie orice regulă, decide pe care dintre ele o numește de fapt cerința.

Tot ce urmează privește distanța dintre acea propoziție și ceva care funcționează.

Ce trebuie să însemne mai întâi «pe client»

O adresă de tunel este ușor de clasificat și ușor de reciclat. Un dispozitiv este mai greu, pentru că un cont poate purta mai multe, iar un dispozitiv poate avea mai multe adrese, mai ales cu IPv6. Pentru o politică de echitate, contul este unitatea cea mai semnificativă și cea mai greu de observat într-un antet de pachet. Fiecare definiție implică propria cheie de numărare, așa că o politică ce oscilează între ele nu va face ce afirmă descrierea.

Direcția este al doilea cuvânt lipsă. Încărcarea, descărcarea și combinat sunt trei cerințe diferite, iar o singură regulă de ieșire pe o interfață acoperă rar ambele căi.

Alege un punct în care clientul este încă vizibil

Fiecare direcție este definită față de o interfață. Ce părăsește tunelul serverului spre un client îndepărtat contează ca descărcare pentru acel client; ce trimite un client intră în tunel și apoi iese spre destinația sa. Alege un punct de planificare pentru fiecare direcție și întreabă ce câmpuri există acolo. Înainte de NAT-ul sursă, o încărcare mai poartă adresa internă a clientului; după traducere, o simplă potrivire de sursă poate să nu-l mai identifice.

Pe calea criptată, antetele aparțin transportului VPN, așa că un filtru care potrivește adrese interne nu are ce potrivi. Un proiect poate clasifica mai devreme și poate preda o marcă unui planificator ulterior, dar această predare trebuie să fie deliberată: mărcile de pachet, mărcile de conexiune și clasele planificatorului sunt stări diferite, nu o singură valoare transmisă mai departe.

Gălețile nu apar de la sine

O găleată de jetoane atașată unei interfețe modelează orice trafic care o folosește; nu bate o găleată nouă pentru fiecare adresă sursă. Un proiect bazat pe clase sortează în schimb traficul selectat în clase, filtrele decid apartenența, iar manualul HTB separă rata unei clase de plafonul ei când părintele are lățime de bandă liberă. Dacă intenția este un plafon dur, setează plafonul și decide deliberat comportamentul de împrumut; nu trata fiecare cifră de rată ca un maxim absolut.

Când cerința este pe client, două transferuri care rulează simultan ar trebui să împartă o singură cotă. A da fiecărui flux rata completă este altă politică și supraviețuiește oricărui test care urmărește doar o descărcare.

Două dispozitive, un cont, o cotă?

Limitarea separată a două adrese de dispozitiv nu se adună niciodată într-o singură cotă la nivel de cont, chiar și când ambele dispozitive se conectează ca aceeași persoană. Același lucru este valabil pentru un întreg LAN tradus în spatele unui singur partener, sau pentru adrese IPv6 suplimentare pe care clasificatorul nu le-a așteptat niciodată. Menține actuală asocierea dintre adresă și identitate și ține minte că o adresă stabilă simplifică harta fără a-i autentifica proprietarul.

Definește și comportamentul de rafală și de coadă. Gălețile de jetoane permit rafale scurte peste medie, iar memorarea în buffer adaugă întârziere; a poliția excesul și a-l pune în coadă pentru mai târziu sunt decizii diferite cu simptome diferite.

Pentru validare, rulează două transferuri dintr-un client, adaugă un al doilea client și citește contoarele de clasă în fiecare direcție.