Ang pagmarka sa iyong VPN port ay hindi nagbibigay-priyoridad sa mga tawag na may boses
Ang pagmarka sa VPN port bilang priyoridad ay nagtutulak sa tawag at backup sa isang tunnel. Ang boses ay nangangailangan ng klasipikasyon bago ang encryption at pila na ikaw ang kumokontrol.
Ang pagmarka sa UDP port ng VPN bilang mataas na priyoridad ay ang pinakakaraniwang pagbabago sa QoS para sa boses, at hindi nito hinihiwalay ang tawag sa paglilipat ng file na gumagamit ng parehong tunnel. Pareho silang lumalabas sa parehong naka-encrypt na socket. Sinasabi ng marka sa susunod na hop na lahat ay pantay ang halaga, na kapareho ng walang sinasabi. Ang nagpoprotekta sa tawag ay isang mapagkakatiwalaang klasipikasyon bago ang encryption at isang pila na talagang kontrolado mo.
Itinatago ng tunnel ang daloy na gusto mong klasipikahin
Pinapalitan ng encryption ang mga panloob na header ng isang panlabas na header bawat tunnel. Pagkatapos, ang boses at backup na trapiko ay nagpapakita ng parehong pinagmulan, destinasyon at port ng transportasyon, kaya ang isang tagaklasipika na nakabatay sa port ng tunnel ay hindi sila makikilala. Anumang itulak mo, itinutulak mo ito nang sabay-sabay.
Ang halaga ng DSCP na itinakda ng pinagmulang aplikasyon ay nabubuhay lamang kung may kumokopya nito palabas. Ang OpenVPN 2.6 ay may passtos, na dokumentado na may saklaw na IPv4; inilalapat ng IPsec ang sarili nitong patakaran sa pagkopya o pagmamapa sa hangganan ng tunnel. Kung wala ang hakbang na iyon, ang panlabas na packet ay mamarkahan ng anumang default na ginagamit ng interface ng tunnel, at hindi malalaman ng pila sa ibaba na may tawag sa loob.
Ang mga nakopyang marka ay karapat-dapat sa parehong paghihinala tulad ng anumang halagang ibinigay ng kliyente. Maaaring humingi ang isang workstation ng pinabilis na pagpapasa para sa isang trabahong backup, kaya ang pagtanggap at muling pagmarka sa hangganan ng pagtitiwala ay dapat nasa disenyo bago paniwalaan ang marka.
Ang priyoridad ay binibilang lamang kung saan nabubuo ang pila
Ang puspos na uplink ang nagpapalit ng magandang codec tungo sa robotic na boses, at ang pila na napupuno ay kadalasang nasa access device o sa buffer ng provider. Ang paghubog sa palabas na landas sa magagamit na bilis, binawasan ang overhead ng tunnel at link, ang nagpapanatili sa pila sa hardware na ikaw ang nangangasiwa, hindi sa buffer ng iba.
Nakakatulong ang patas na pagkakapila at aktibong pamamahala ng pila kahit walang klase ng boses, dahil pinipigilan nila ang isang malaking daloy na punuin ang buffer. Pinagsasama ng CAKE sa Linux ang paghubog, pagiging patas kada daloy at opsyonal na mga klase ng Diffserv sa isang qdisc, at ang naka-deploy na network manager ang dapat may-ari ng configuration na iyon sa halip na pangalawang nakikipagkumpitensyang pila. Kung walang paghubog, ang klase na mas mataas sa malaking trapiko ay naghihintay pa rin sa likod ng buffer na puno na.
Ang paghawak sa papasok na trapiko ay hindi walang gamit, ngunit gumagana ito matapos makatawid ang packet sa receiving link. Maaari nitong impluwensyahan ang isang tumutugong tagapagpadala at hindi nito maibabalik ang pagkaantala na nagastos na sa itaas, kaya ito ay pagpapagaan at hindi garantiya.
| Stage | What you can control | What to verify |
|---|---|---|
| Application to client | Which flows are trusted for marking | The marked packets are the ones you intended |
| Tunnel boundary | Whether the inner mark is copied outward | Outer header carries the expected value |
| Your uplink | Shaping rate and class treatment | Queue counters move for the voice class |
| Provider path | Almost nothing | Whether the service enforces the marking at all |
| Receiving side | Local policy after arrival | Delay that is already in the past |
Ano ang nabubuhay sa pampublikong internet
Ang arkitekturang Diffserv ay naglalarawan ng pagtrato sa loob ng administratibong mga domain, kaya maaaring balewalain o isulat muli ng provider ang isang marka sa hangganan. Ang kabaligtarang pag-aangkin, na laging tinatanggal ito ng bawat network, ay kasing walang batayan. Ang tapat na tanong ay kung ano ang kontraktwal at binabantayan na gawin ng partikular na landas na ito. Subukan ito gamit ang isang markadong probe sa halip na ulitin ang isang tuntuning nabasa mo sa kung saan.
Itanong kung ano ang ginagawa ng provider sa klase, pagkatapos ay sukatin. Ang markang pinapanatili ngunit hindi naka-iskedyul ay palamuti; ang landas na nag-iskedyul nang hindi nakikita ang marka ay ibang problema, at kailangan ng dalawa ng magkaibang pagtatama.
Isang planong pagsukat na naghihiwalay sa yugto
Gumawa ng isang ordinaryong tawag na may kontroladong nakikipagkumpitensyang upload, pagkatapos ay ulitin ito sa kable na link. Tingnan kung ano ang nawala sa tawag, ano ang naitala ng mga counter ng klase at gaano kalapit ang interface sa tunay nitong limitasyon kaysa sa inaanunsyong bilis ng plano.
tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.netKung mananatiling zero ang counter ng klase ng boses, sira ang klasipikasyon o pagkopya ng marka at wala kang makukuhang tulong sa anumang priyoridad. Kung gumagalaw ang counter ng klase nang lokal habang patuloy na tumataas ang pagkaantala, ang bottleneck ay lampas sa iyong gateway. Wala sa dalawang resulta ang naaayos sa pamamagitan ng pagtaas ng halaga ng priyoridad.