Jeden shaper tc sam nie ogranicza każdego klienta VPN

Polecenie brzmi kompletnie: ogranicz każdego klienta VPN do 20 Mbit/s. Nie jest kompletne, a jedna dyscyplina kolejki na interfejsie tunelu tego nie zapewni. Na klienta może znaczyć na adres tunelu, na urządzenie albo na konto, i każdy wybór klasyfikuje pakiety inaczej. Zanim napiszesz jakąkolwiek regułę, zdecyduj, który z nich wymaganie naprawdę nazywa.

Wszystko poniżej dotyczy odległości między tym zdaniem a czymś, co działa.

Co najpierw musi oznaczać «na klienta»

Adres tunelu łatwo klasyfikować i łatwo zawrócić do obiegu. Urządzenie jest trudniejsze, bo jedno konto może nieść kilka, a urządzenie może mieć kilka adresów, zwłaszcza z IPv6. Dla polityki uczciwości konto jest najbardziej sensowną jednostką i najtrudniej je zauważyć w nagłówku pakietu. Każda definicja niesie własny klucz zliczania, więc polityka dryfująca między nimi nie zrobi tego, co twierdzi opis.

Kierunek to drugie brakujące słowo. Wysyłanie, pobieranie i łącznie to trzy różne wymagania, a jedna reguła wyjścia na jednym interfejsie rzadko obejmuje obie ścieżki.

Wybierz punkt, w którym klient jest jeszcze widoczny

Każdy kierunek jest definiowany względem interfejsu. To, co opuszcza tunel serwera w stronę zdalnego klienta, liczy się jako pobieranie dla tego klienta; to, co klient wysyła, wchodzi do tunelu, a potem wychodzi w stronę celu. Wybierz punkt planowania dla każdego kierunku i zapytaj, jakie pola tam istnieją. Przed NAT źródłowym wysyłanie nadal niesie wewnętrzny adres klienta; po translacji proste dopasowanie źródła może już go nie identyfikować.

Na ścieżce szyfrowanej nagłówki należą do transportu VPN, więc filtr dopasowujący adresy wewnętrzne nie ma czego dopasowywać. Projekt może klasyfikować wcześniej i przekazać znacznik późniejszemu schedulerowi, ale to przekazanie musi być zamierzone: znaczniki pakietów, znaczniki połączeń i klasy schedulera to różny stan, nie jedna przekazywana wartość.

Kubły nie pojawiają się same

Kubeł tokenów przywiązany do interfejsu kształtuje dowolny ruch, który go używa; nie tworzy nowego kubła na każdy adres źródłowy. Projekt oparty na klasach zamiast tego sortuje wybrany ruch do klas, filtry decydują o przynależności, a podręcznik HTB oddziela szybkość klasy od jej pułapu, gdy rodzic ma wolne pasmo. Jeśli intencją jest twardy pułap, ustaw pułap i świadomie zdecyduj o zachowaniu pożyczania; nie traktuj każdej liczby szybkości jako absolutnego maksimum.

Gdy wymaganie jest na klienta, dwa równoczesne transfery powinny dzielić jeden limit. Dawanie każdemu strumieniowi pełnej szybkości to inna polityka i przetrwa każdy test, który obserwuje tylko jedno pobieranie.

Dwa urządzenia, jedno konto, jeden limit?

Ograniczanie dwóch adresów urządzeń osobno nigdy nie sumuje się do jednego limitu na poziomie konta, nawet gdy oba urządzenia logują się jako ta sama osoba. To samo dotyczy całej sieci LAN tłumaczonej za jednym peera albo dodatkowych adresów IPv6, których klasyfikator nigdy nie oczekiwał. Utrzymuj powiązanie adresu z tożsamością na bieżąco i pamiętaj, że stabilny adres upraszcza mapę, ale nie uwierzytelnia właściciela.

Zdefiniuj też zachowanie burstu i kolejki. Kubły tokenów pozwalają na krótkie bursty powyżej średniej, a buforowanie dodaje opóźnienie; policyjne ograniczanie nadmiaru i odkładanie go do kolejki na później to różne decyzje o różnych objawach.

Aby sprawdzić, uruchom dwa transfery z jednego klienta, dodaj drugiego klienta i odczytaj liczniki klas w każdym kierunku.