Marcarea portului VPN nu prioritizează apelurile vocale

Marcarea portului UDP al VPN ca prioritate ridicată este cea mai frecventă modificare QoS pentru voce și nu separă un apel de transferul de fișiere care partajează același tunel. Ambele fluxuri ies prin același socket criptat. Marcajul îi spune următorului hop că totul contează la fel, ceea ce este același lucru cu a nu-i spune nimic. Ce protejează un apel este o clasificare de încredere înainte de criptare plus o coadă pe care o controlați cu adevărat.

Tunelul ascunde fluxul pe care voiați să îl clasificați

Criptarea înlocuiește antetele interioare cu un singur antet exterior pe tunel. După aceea, vocea și traficul de copie de siguranță prezintă aceeași sursă, destinație și port de transport, așa că un clasificator bazat pe portul tunelului nu le poate distinge. Orice promovați, promovați în bloc.

O valoare DSCP setată de aplicația de origine supraviețuiește doar dacă ceva o copiază spre exterior. OpenVPN 2.6 are passtos, documentat cu domeniu IPv4; IPsec aplică propria politică de copiere sau de mapare la granița tunelului. Fără acest pas, pachetul exterior este marcat cu orice valoare implicită folosită de interfața tunelului, iar coada din aval nu află niciodată că înăuntru este un apel.

Marcajele copiate merită aceeași suspiciune ca orice valoare furnizată de client. O stație de lucru poate solicita expediere accelerată pentru o sarcină de copie de siguranță, așa că admiterea și remarkarea la granița de încredere trebuie să fie în proiect înainte ca marcajului să i se dea crezare.

Prioritatea contează doar acolo unde se formează coada

Un uplink saturat este ceea ce transformă un codec bun într-o voce robotică, iar coada care se umple este de obicei în dispozitivul de acces sau în tamponul furnizorului. Modelarea căii de ieșire la rata utilizabilă, minus suprasarcina tunelului și a legăturii, este ceea ce ține acea coadă pe hardware pe care îl administrați, nu în tamponul altcuiva.

Coada echitabilă și gestionarea activă a cozilor ajută chiar și fără o clasă de voce, pentru că împiedică un singur flux masiv să umple tamponul. CAKE pe Linux reunește modelarea, echitatea pe flux și clasele Diffserv opționale într-un singur qdisc, iar managerul de rețea implementat ar trebui să dețină acea configurație în locul unei a doua cozi concurente. Fără modelare, o clasă care depășește traficul masiv așteaptă în continuare în spatele unui tampon deja plin.

Tratarea traficului de intrare nu este inutilă, dar acționează după ce pachetul a trecut legătura de recepție. Poate influența un expeditor receptiv și nu poate restitui întârzierea deja cheltuită în amonte, așa că este o atenuare și nu o garanție.

Ce supraviețuiește pe internetul public

Arhitectura Diffserv descrie tratarea în interiorul domeniilor administrative, de aceea un furnizor poate ignora sau rescrie un marcaj la o graniță. Afirmația opusă, că fiecare rețea îl elimină mereu, este la fel de nefondată. Întrebarea onestă este la ce este obligată prin contract și supravegheată această cale anume. Testați cu o sondă marcată în loc să repetați o regulă citită undeva.

Întrebați ce face furnizorul cu clasa și apoi măsurați. Un marcaj păstrat dar neprogramat este decor; o cale care programează fără să vadă marcajul este altă problemă, iar cele două cer corecții diferite.

Un plan de măsurare care izolează etapa

Faceți un apel obișnuit cu un încărcare concurentă controlată, apoi repetați-l pe o legătură prin cablu. Uitați-vă la ce a pierdut apelul, la ce au înregistrat contoarele de clasă și la cât de aproape merge interfața de limita ei reală, nu de viteza anunțată a planului.

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

Dacă contorul clasei de voce rămâne la zero, clasificarea sau copierea marcajului este stricată și nicio prioritate nu va ajuta. Dacă contorul clasei se mișcă local în timp ce întârzierea continuă să crească, blocajul este dincolo de gateway-ul dumneavoastră. Niciunul dintre cele două rezultate nu se corectează prin creșterea valorii de prioritate.