Menandai porta VPN tidak memprioritaskan panggilan suara

Menandai porta UDP VPN sebagai prioritas tinggi adalah perubahan QoS suara yang paling umum, dan itu tidak memisahkan panggilan dari transfer berkas yang berbagi terowongan itu. Kedua aliran keluar melalui soket terenkripsi yang sama. Tanda memberitahu hop berikutnya bahwa semuanya sama pentingnya, yang sama dengan tidak memberitahunya apa pun. Yang melindungi panggilan adalah klasifikasi tepercaya sebelum enkripsi plus antrean yang benar-benar Anda kendalikan.

Terowongan menyembunyikan aliran yang ingin Anda klasifikasikan

Enkripsi mengganti header dalam dengan satu header luar per terowongan. Setelah itu, suara dan lalu lintas cadangan menunjukkan sumber, tujuan, dan porta transport yang sama, sehingga pengklasifikasi yang berbasis pada porta terowongan tidak dapat membedakannya. Apa pun yang Anda majukan, Anda memajukannya secara borongan.

Nilai DSCP yang ditetapkan aplikasi asal hanya bertahan jika sesuatu menyalinnya ke luar. OpenVPN 2.6 memiliki passtos, yang didokumentasikan dengan cakupan IPv4; IPsec menerapkan kebijakan salin atau pemetaannya sendiri di batas terowongan. Tanpa langkah itu, paket luar ditandai dengan nilai bawaan apa pun yang dipakai antarmuka terowongan, dan antrean di hilir tidak pernah tahu ada panggilan di dalamnya.

Tanda yang disalin layak dicurigai sama seperti nilai apa pun yang dipasok klien. Stasiun kerja dapat mengklaim penerusan dipercepat untuk tugas cadangan, jadi penerimaan dan penandaan ulang di batas kepercayaan harus ada dalam desain sebelum tanda dipercaya.

Prioritas hanya berlaku di tempat antrean terbentuk

Uplink yang jenuh adalah yang mengubah kodek bagus menjadi suara robotik, dan antrean yang terisi biasanya ada di perangkat akses atau di buffer penyedia. Membentuk jalur keluar ke laju yang dapat digunakan, dikurangi beban terowongan dan tautan, adalah yang menjaga antrean itu pada perangkat keras yang Anda kelola, bukan di buffer orang lain.

Antrean adil dan manajemen antrean aktif membantu bahkan tanpa kelas suara, karena keduanya mencegah satu aliran besar memenuhi buffer. CAKE di Linux menggabungkan pembentukan, keadilan per aliran, dan kelas Diffserv opsional dalam satu qdisc, dan manajer jaringan yang terpasang seharusnya memiliki konfigurasi itu, bukan pengaturan antrean kedua yang bersaing. Tanpa pembentukan, kelas yang melampaui lalu lintas besar tetap menunggu di belakang buffer yang sudah penuh.

Penanganan masuk tidak sia-sia, tetapi bertindak setelah paket melewati tautan penerima. Itu dapat memengaruhi pengirim yang responsif dan tidak dapat mengembalikan tunda yang sudah terpakai di hulu, jadi ini mitigasi, bukan jaminan.

Apa yang bertahan di internet publik

Arsitektur Diffserv menjelaskan perlakuan di dalam domain administratif, karena itu penyedia dapat mengabaikan atau menulis ulang tanda di batas. Klaim sebaliknya, bahwa setiap jaringan selalu menghapusnya, sama tidak berdasarannya. Pertanyaan jujurnya adalah untuk apa jalur khusus ini dikontrakkan dan diawasi. Ujilah dengan probe bertanda alih-alih mengulang aturan yang Anda baca di suatu tempat.

Tanyakan apa yang dilakukan penyedia dengan kelas itu, lalu ukurlah. Tanda yang dipertahankan tetapi tidak dijadwalkan adalah hiasan; jalur yang menjadwalkan tanpa melihat tanda adalah masalah lain, dan keduanya perlu perbaikan berbeda.

Rencana pengukuran yang mengisolasi tahap

Lakukan satu panggilan biasa dengan unggahan pesaing yang terkendali, lalu ulangi di tautan kabel. Lihat apa yang hilang dari panggilan, apa yang dicatat penghitung kelas, dan seberapa dekat antarmuka berjalan ke batas nyatanya alih-alih kecepatan utama paket.

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

Jika penghitung kelas suara tetap nol, klasifikasi atau penyalinan tanda rusak dan tidak ada prioritas yang membantu. Jika penghitung kelas bergerak secara lokal sementara tunda terus naik, hambatan ada di luar gateway Anda. Tidak ada dari kedua hasil itu yang diperbaiki dengan menaikkan nilai prioritas.