Маркіроўка порта VPN не дае прыярытэту галасавым выклікам

Маркіроўка UDP-порта VPN як высокапрыярытэтнага — самая распаўсюджаная змена QoS для голасу, і яна не аддзяляе выклік ад перадачы файлаў, што дзеліць гэты ж тунель. Абодва патоку выходзяць праз той самы шыфраваны сокет. Марка паведамляе наступнаму хопу, што ўсё аднолькава важнае, а гэта тое ж самае, што не сказаць нічога. Выклік абараняе надзейная класіфікацыя да шыфравання плюс чарга, якой вы сапраўды кіруеце.

Тунель хавае паток, які вы хацелі класіфікаваць

Шыфраванне замяняе ўнутраныя загалоўкі адным вонкавым загалоўкам на кожны тунель. Пасля гэтага голас і рэзервовы трафік маюць аднолькавыя крыніцу, прызначэнне і транспартны порт, таму класіфікатар, які абапіраецца на порт тунеля не можа іх адрозніць. Што б вы ні прасоўвалі, вы прасоўваеце гэта ўсё разам.

Значэнне DSCP, устаноўленае зыходным праграмным забеспячэннем, захоўваецца, толькі калі нешта капіюе яго вонкава. У OpenVPN 2.6 ёсць passtos, дакументаваны з вобласцю IPv4; IPsec прымяняе сваю ўласную палітыку капіравання або адлюстравання на мяжы тунеля. Без гэтага кроку вонкавы пакет пазначаецца любым значэннем па змаўчанні, якое выкарыстоўвае інтэрфейс тунеля, і чарга ніжэй па цячэнні ніколі не даведаецца, што ўнутры ёсць выклік.

Скапіяваныя маркі заслугоўваюць такога ж недаверу, як любое значэнне, дадзенае кліентам. Працоўная станцыя можа патрабаваць паскоранай перасылкі для задачы рэзервовага капіявання, таму допуск і перамаркіроўка на мяжы даверу павінны быць у праекце раней, чым марцы павераць.

Прыярытэт мае значэнне толькі там, дзе ўтвараецца чарга

Насычанае ўзыходнае злучэнне — гэта тое, што ператварае добры кодэк у рабатызаваны голас, і чарга, якая запаўняецца, звычайна знаходзіцца ў прыладзе доступу або ў буферы пастаўшчыка. Фармаванне зыходнага шляху да даступнай хуткасці, мінус накладныя выдаткі тунеля і канала, — гэта тое, што трымае гэтую чаргу на абсталяванні, якім вы кіруеце, а не ў чужым буферы.

Справядлівае чаргаванне і актыўнае кіраванне чаргамі дапамагаюць нават без класа голасу, бо яны не дазваляюць аднаму буйнаму патоку запоўніць буфер. CAKE у Linux аб'ядноўвае фармаванне, справядлівасць па патоках і неабавязковыя класы Diffserv у адным qdisc, і разгорнуты кіраўнік сеткі павінен валодаць гэтай канфігурацыяй, а не другой канкуруючай наладай чаргі. Без фармавання клас, які стаіць вышэй за буйны трафік, усё роўна чакае за буферам, які ўжо поўны.

Апрацоўка ўваходнага трафіку не бескарысная, але яна дзейнічае пасля таго, як пакет перасёк прыёмны канал. Яна можа паўплываць на чуйнага адпраўніка і не можа вярнуць затрымку, ужо выдаткаваную вышэй па цячэнні, таму гэта памякчэнне, а не гарантыя.

Што выжывае ў публічным інтэрнэце

Архітэктура Diffserv апісвае апрацоўку ўнутры адміністрацыйных даменаў, і менавіта таму пастаўшчык можа ігнараваць або перапісваць марку на мяжы. Супрацьлеглае сцвярджэнне, што кожная сетка заўсёды яе выдаляе, гэтак жа неабгрунтаванае. Сумленнае пытанне — што менавіта гэты шлях абавязаны рабіць па дамове і пад кантролем. Праверце гэта пазначаным зондам, а не паўтарэннем правіла, прачытанага недзе.

Спытайцеся, што пастаўшчык робіць з класам, потым вымерайце гэта. Марка, якая захоўваецца, але не плануецца, — гэта ўпрыгожанне; шлях, які плануе, не бачачы маркі, — іншая праблема, і дзве яны патрабуюць розных выпраўленняў.

План вымярэння, які ізалюе этап

Зрабіце адзін звычайны выклік з кантраляваным канкурэнтным запампоўваннем, затым паўтарыце яго на правадным канале. Паглядзіце, што страціў выклік, што запісалі лічыльнікі класа і наколькі блізка інтэрфейс працуе да сваёй рэальнай мяжы, а не да рэкламнай хуткасці плана.

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

Калі лічыльнік класа голасу застаецца на нулі, класіфікацыя або капіраванне маркі зламаныя, і ніякі прыярытэт не дапаможа. Калі лічыльнік класа рухаецца лакальна, а затрымка ўсё расце, вузкае месца знаходзіцца за вашым шлюзам. Ні адзін з вынікаў не выпраўляецца павышэннем значэння прыярытэту.