Om jou VPN-poort te merk prioritiseer nie stemoproepe nie

Om die UDP-poort van die VPN as hoë prioriteit te merk is die mees algemene stem-QoS-verandering, en dit skei nie ’n oproep van die lêeroordrag wat dieselfde tonnel deel nie. Albei vloei verlaat die dieselfde geënkripteerde sok. Die merk sê vir die volgende hop dat alles ewe belangrik is, wat dieselfde is as om niks te sê. Wat ’n oproep beskerm, is ’n betroubare klassifikasie voor enkripsie plus ’n waglyn wat jy werklik beheer.

Die tonnel verberg die vloei wat jy wou klassifiseer

Enkripsie vervang die binneste koptekste met een buitenste koptekst per tonnel. Daarna het stem- en rugsteunverkeer dieselfde bron, bestemming en vervoerpoort, so ’n klassifiseerder wat op die tonnelpoort geskoei is kan hulle nie onderskei nie. Wat jy ook al bevorder, jy bevorder dit in grootmaat.

’n DSCP-waarde wat deur die oorspronklike toepassing gestel is, oorleef net as iets dit na buite kopieer. OpenVPN 2.6 het passtos, gedokumenteer met ’n IPv4-bestek; IPsec pas sy eie kopieer- of karteringsbeleid by die tonnelgrens toe. Sonder daardie stap word die buitenste pakket gemerk met watter verstek die tonnelkoppelvlak ook al gebruik, en die waglyn stroomaf leer nooit dat ’n oproep binne is nie.

Gekopieerde merke verdien dieselfde agterdog as enige waarde wat ’n kliënt verskaf. ’n Werkstasie kan versnelde aanstuur vir ’n rugsteuntaak eis, so toelating en hermerking by die vertrouensgrens hoort in die ontwerp voordat die merk geglo word.

Prioriteit tel net waar die waglyn gevorm word

Dit is ’n versadigde opstroomkoppeling wat ’n goeie kodek in ’n robotagtige stem verander, en die waglyn wat vol word, is gewoonlik in die toegangstoestel of die diensverskaffer se buffer. Om die uitgaande pad te vorm na die bruikbare tempo, minus tonnel- en skakeloorhoof, is wat daardie waglyn op hardeware hou wat jy administreer eerder as in iemand anders se buffer.

Regverdige toue en aktiewe waglynbestuur help selfs sonder ’n stemklas, want hulle verhoed dat een grootmaatvloei die buffer vol maak. CAKE op Linux bundel vorming, regverdigheid per vloei en opsionele Diffserv-klasse in een qdisc, en die ontplooide netwerkbestuurder behoort daardie konfigurasie te besit eerder as ’n tweede mededingende waglynopstelling. Sonder vorming wag ’n klas wat grootmaatverkeer oortref steeds agter ’n buffer wat reeds vol is.

Inkomende hantering is nie nutteloos nie, maar dit tree op nadat die pakket die ontvangende skakel oorgesteek het. Dit kan ’n reagerende sender beïnvloed en dit kan nie vertraging wat reeds opstroom bestee is, terugbetaal nie, so dit is ’n versagting eerder as ’n waarborg.

Wat die publieke internet oorleef

Die Diffserv-argitektuur beskryf hantering binne administratiewe domeine, en daarom kan ’n diensverskaffer ’n merk by ’n grens ignoreer of herskryf. Die teenoorgestelde bewering, dat elke netwerk dit altyd stroop, is net so onondersteun. Die eerlike vraag is wat hierdie spesifieke pad gekontrakteer en gepoliseer is om te doen. Toets dit met ’n gemerkte probe eerder as om ’n reël te herhaal wat jy êrens gelees het.

Vra wat die diensverskaffer met die klas doen en meet dit dan. ’n Merk wat behoue bly maar nie geskeduleer word nie, is versiering; ’n pad wat skeduleer sonder om die merk te sien, is ’n ander probleem, en die twee het verskillende regstellings nodig.

’n Meetplan wat die stadium isoleer

Voer een gewone oproep uit met ’n beheerde mededingende oplaai en herhaal dit dan op ’n bedrade skakel. Kyk wat die oproep verloor het, wat die klas-tellers aangeteken het, en hoe naby die koppelvlak aan sy werklike limiet loop eerder as die plan se hoofspoed.

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

As die stemklas-teller op nul bly, is klassifikasie of merkkopiëring stukkend en geen hoeveelheid prioriteit sal help nie. As die klas-teller plaaslik beweeg terwyl vertraging steeds styg, is die knelpunt verby jou poort. Nie een van die twee uitkomste word reggestel deur die prioriteitswaarde te verhoog nie.