Yksi tc-muotoilija ei rajoita jokaista VPN-asiakasta itsestään

Ohje kuulostaa täydelliseltä: rajoita jokainen VPN-asiakas 20 Mbit/s:iin. Se ei ole täydellinen, eikä yksi jonokuri tunnelin rajapinnalla tuota sitä. Asiakaskohtainen voi tarkoittaa tunneliosoitetta, laitetta tai tiliä kohden, ja jokainen valinta luokittelee paketit eri tavoin. Ennen minkään säännön kirjoittamista päätä, minkä niistä vaatimus todella nimeää.

Kaikki alla koskee etäisyyttä tuon lauseen ja toimivan asian välillä.

Mitä «asiakaskohtainen» on ensin merkittävä

Tunneliosoite on helppo luokitella ja helppo kierrättää. Laite on vaikeampi, koska yksi tili voi kantaa useita ja laitteella voi olla useita osoitteita, erityisesti IPv6:n kanssa. Reiluuspolitiikalle tili on mielekkäin yksikkö ja vaikein havaita paketin otsikosta. Jokainen määritelmä edellyttää oman laskenta-avaimensa, joten niiden välillä ajelehtiva käytäntö ei tee sitä, mitä kuvaus väittää.

Suunta on toinen puuttuva sana. Ylöslataus, alalataus ja yhdistetty ovat kolme eri vaatimusta, ja yksi lähtevä sääntö yhdellä rajapinnalla kattaa harvoin molemmat polut.

Valitse piste, jossa asiakas on vielä näkyvissä

Jokainen suunta määritellään rajapintaa vasten. Se, mikä lähtee palvelimen tunnelista etäasiakasta kohti, lasketaan kyseisen asiakkaan alalataukseksi; se, mitä asiakas lähettää, tulee tunneliin ja lähtee sitten kohti kohdettaan. Valitse jokaiselle suunnalle aikataulutuspiste ja kysy, mitkä kentät siellä ovat olemassa. Ennen lähde-NATia ylöslataus kantaa yhä asiakkaan sisäistä osoitetta; käännöksen jälkeen yksinkertainen lähdeosuma ei ehkä enää tunnista sitä.

Salatulla polulla otsikot kuuluvat VPN-siirtoon, joten sisäisiä osoitteita vastaavalla suodattimella ei ole mitään vastattavaa. Suunnittelu voi luokitella aikaisemmin ja antaa merkin myöhemmälle ajoittajalle, mutta tuon siirron on oltava tarkoituksellinen: pakettimerkit, yhteyksien merkit ja ajoittajan luokat ovat eri tilaa, ei yksi eteenpäin annettava arvo.

Ämpärit eivät ilmesty itsestään

Rajapintaan kiinnitetty token-ämpäri muotoilee mitä tahansa liikennettä, joka sitä käyttää; se ei lyö uutta ämpäriä jokaista lähdeosoitetta kohden. Luokkapohjainen suunnittelu sen sijaan lajittelee valitun liikenteen luokkiin, suodattimet päättävät jäsenyydestä, ja HTB:n käsikirja erottaa luokan nopeuden sen katosta, kun vanhemmalla on vapaata kaistanleveyttä. Jos tarkoitus on kova yläraja, aseta katto ja päätä lainauskäyttäytyminen tarkoituksella; älä kohtele jokaista nopeuslukua absoluuttisena maksimina.

Kun vaatimus on asiakaskohtainen, kahden samanaikaisen siirron pitäisi jakaa yksi kiintiö. Sen antaminen jokaiselle virralle täytenä nopeutena on toinen käytäntö, ja se kestää minkä tahansa testin, joka katsoo vain yhtä alalatausta.

Kaksi laitetta, yksi tili, yksi kiintiö?

Kahden laiteosoitteen erillinen rajoittaminen ei koskaan summaudu yhdeksi tilikohtaiseksi kiintiöksi, vaikka molemmat laitteet kirjautuisivat samana henkilönä. Sama koskee koko lähiverkkoa, joka käännetään yhden vertaislaitteen taakse, tai ylimääräisiä IPv6-osoitteita, joita luokittelija ei koskaan odottanut. Pidä osoitteen ja identiteetin yhteys ajan tasalla ja muista, että vakaa osoite yksinkertaistaa karttaa ilman omistajan todentamista.

Määrittele myös purskeen ja jonon käyttäytyminen. Token-ämpärit sallivat lyhyitä purskeita keskiarvon yläpuolella, ja puskurointi lisää viivettä; ylijäämän valvonta ja sen myöhemmäksi jonoon asettaminen ovat eri päätöksiä eri oirein.

Vahvista ajamalla kaksi siirtoa yhdeltä asiakkaalta, lisää toinen asiakas ja lue luokkalaskurit kumpaankin suuntaan.