Satu shaper tc tidak membatasi setiap klien VPN dengan sendirinya

Instruksinya terdengar lengkap: batasi setiap klien VPN pada 20 Mbit/s. Tidak lengkap, dan satu disiplin antrean pada antarmuka tunnel tidak akan memberikannya. Per klien bisa berarti per alamat tunnel, per perangkat, atau per akun, dan setiap pilihan mengklasifikasikan paket secara berbeda. Sebelum menulis aturan apa pun, tentukan mana yang sebenarnya disebutkan persyaratan itu.

Semua di bawah ini menyangkut jarak antara kalimat itu dan sesuatu yang berfungsi.

Apa yang harus lebih dulu dimaksud «per klien»

Alamat tunnel mudah diklasifikasikan dan mudah didaur ulang. Perangkat lebih sulit, karena satu akun bisa membawa beberapa, dan satu perangkat bisa memiliki beberapa alamat, terutama dengan IPv6. Untuk kebijakan keadilan, akun adalah unit paling bermakna, dan paling sulit terlihat di header paket. Setiap definisi menyiratkan kunci penghitungannya sendiri, jadi kebijakan yang bergeser di antaranya tidak akan melakukan apa yang diklaim deskripsi.

Arah adalah kata kedua yang hilang. Unggah, unduh, dan gabungan adalah tiga persyaratan berbeda, dan satu aturan keluar pada satu antarmuka jarang mencakup kedua jalur.

Pilih titik di mana klien masih terlihat

Setiap arah didefinisikan terhadap sebuah antarmuka. Yang meninggalkan tunnel server menuju klien jarak jauh dihitung sebagai unduhan bagi klien itu; yang dikirim klien masuk ke tunnel lalu keluar menuju tujuannya. Pilih titik penjadwalan untuk setiap arah dan tanyakan bidang apa yang ada di sana. Sebelum NAT sumber, unggahan masih membawa alamat internal klien; setelah terjemahan, pencocokan sumber sederhana mungkin tidak lagi mengenalinya.

Di jalur terenkripsi, header milik transport VPN, jadi filter yang mencocokkan alamat internal tidak punya apa pun untuk dicocokkan. Sebuah desain bisa mengklasifikasikan lebih awal dan menyerahkan tanda ke penjadwal berikutnya, tetapi penyerahan itu harus disengaja: tanda paket, tanda koneksi, dan kelas penjadwal adalah keadaan berbeda, bukan satu nilai yang diteruskan.

Ember tidak muncul sendiri

Ember token yang terpasang pada antarmuka membentuk lalu lintas apa pun yang memakainya; ia tidak mencetak ember baru per alamat sumber. Desain berbasis kelas justru menyortir lalu lintas terpilih ke dalam kelas, filter menentukan keanggotaan, dan panduan HTB memisahkan laju kelas dari plafonnya ketika induk punya bandwidth sisa. Jika maksudnya batas keras, tetapkan plafon dan putuskan perilaku peminjaman dengan sengaja; jangan anggap setiap angka laju sebagai maksimum mutlak.

Ketika persyaratannya per klien, sepasang transfer yang berjalan bersamaan seharusnya berbagi satu jatah. Memberi setiap aliran laju penuh adalah kebijakan lain, dan itu bertahan pada uji apa pun yang hanya mengamati satu unduhan.

Dua perangkat, satu akun, satu jatah?

Membatasi dua alamat perangkat secara terpisah tidak pernah berjumlah menjadi satu jatah tingkat akun, bahkan ketika kedua perangkat masuk sebagai orang yang sama. Hal yang sama berlaku untuk seluruh LAN yang diterjemahkan di belakang satu peer, atau untuk alamat IPv6 tambahan yang tidak pernah diperkirakan pengklasifikasi. Jaga asosiasi alamat-identitas tetap mutakhir, dan ingat bahwa alamat stabil menyederhanakan peta tanpa mengautentikasi pemiliknya.

Tentukan juga perilaku burst dan antrean. Ember token mengizinkan burst singkat di atas rata-rata, dan buffering menambah tunda; memolisikan kelebihan dan mengantrekannya untuk nanti adalah keputusan berbeda dengan gejala berbeda.

Untuk validasi, jalankan dua transfer dari satu klien, tambahkan klien kedua, dan baca penghitung kelas di setiap arah.