Å merke VPN-porten gir ikke taleanrop prioritet

Å merke UDP-porten til VPN-en som høy prioritet er den vanligste endringen av QoS for tale, og den klarer ikke å skille en samtale fra filoverføringen som bruker samme tunnel. Begge strømmene forlater den samme krypterte sockelen. Merket sier til neste hopp at alt er like viktig, og det er det samme som å ikke si noe. Det som faktisk beskytter en samtale, er pålitelig klassifisering før kryptering og en kø du selv råder over.

Tunnelen skjuler strømmen du ønsket å klassifisere

Kryptering bytter ut de indre hodene med ett ytre hode for hver tunnel. Deretter fremstår tale og sikkerhetskopitrafikk med samme kilde, mål og transportport, slik at en klassifiserer som bygger på tunnelporten ikke kan skille dem. Alt du løfter frem, løfter du frem samlet.

En DSCP-verdi fra opphavsapplikasjonen overlever bare dersom noe kopierer den ut. OpenVPN 2.6 har passtos, dokumentert med IPv4-virkeområde; IPsec bruker egne regler for kopiering eller mapping ved tunnelgrensen. Uten dette trinnet merkes den ytre pakken med den standardverdien tunnelgrensesnittet bruker, og køen lenger ned får aldri vite at en samtale ligger inni.

Kopierte merker bør mistenkes like mye som enhver verdi klienten oppgir. En arbeidsstasjon kan kreve raskere videresending for en sikkerhetskopieringsoppgave, så godkjenning og ny merking ved tillitsgrensen må være en del av designet før merket blir trodd.

Prioritet har bare betydning der køen oppstår

Det er en mettet opplastingslinje som gjør en god kodek om til en robotaktig stemme, og køen som fylles, ligger vanligvis i aksessutstyret eller i leverandørens buffer. Å forme den utgående veien til den brukbare hastigheten, fratrukket tunnel- og linjekostnader, er det som holder køen på utstyr du administrerer, ikke i en fremmed buffer.

Rettferdig køing og aktiv køstyring hjelper også uten en taleklasse, fordi de hindrer én stor strøm fra å fylle bufferen. CAKE på Linux samler forming, rettferdighet per strøm og valgfrie Diffserv-klasser i én qdisc, og den driftsatte nettverksforvalteren bør eie denne konfigurasjonen fremfor et konkurrerende køoppsett nummer to. Uten forming vil en klasse som rangerer over bulk-trafikk fortsatt vente bak en buffer som allerede er full.

Behandling av innkommende trafikk er ikke bortkastet, men den virker først etter at pakken har passert mottakslinjen. Den kan påvirke en lydhør avsender og kan ikke tilbakebetale forsinkelse som allerede er brukt oppstrøms, så det er en avbøtning og ikke en garanti.

Hva som overlever på det åpne nettet

Diffserv-arkitekturen beskriver behandling inne i administrative domener, og derfor kan en leverandør overse eller skrive om et merke ved en grense. Det motsatte påstanden, at hvert nett alltid fjerner det, er like dårlig underbygget. Det ærlige spørsmålet er hva denne bestemte veien er avtalt og kontrollert for å gjøre. Prøv det med en merket probe istedenfor å gjenta en regel du har lest et sted.

Spør hva leverandøren gjør med klassen, og mål det etterpå. Et merke som beholdes men ikke planlegges, er pynt; en vei som planlegger uten å se merket, er et annet problem, og de to krever forskjellige rettelser.

En måleplan som isolerer trinnet

Gjennomfør én vanlig samtale med en kontrollert konkurrerende opplasting, og gjenta den på en kablet linje. Se på hva samtalen tapte, hva klassetellerne registrerte, og hvor nær grensesnittet går den reelle grensen sin fremfor den annonserte hastigheten.

tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.net

Står telleren for taleklassen på null, er klassifisering eller merkekopiering ødelagt, og ingen prioritering hjelper. Beveger klassetelleren seg lokalt mens forsinkelsen fortsetter å stige, ligger flaskehalsen utenfor gatewayen din. Ingen av de to resultatene rettes opp ved å øke prioritetsverdien.