ניהול רוחב פס MikroTik: תורים

תקציר ניהול רוחב פס ב-MikroTik נשען על שלושה כלים: תורים פשוטים להגבלה מהירה לכל לקוח, עצי תורים להיררכיה ולעדיפות, ו-PCQ לשיתוף הוגן בין משתמשים רבים בלי ליצור תור לכל אחד. עצי תורים משתלבים עם סימוני mangle של חומת האש ומעניקים לכם הבטחות, תקרות ועדיפויות. מדריך זה מראה מתי להשתמש בכל אחד, את פקודות RouterOS, וכיצד לשמור על אותה מדיניות עקבית על פני צי של נתבים.

מהו ניהול רוחב פס ב-MikroTik?

ניהול רוחב פס ב-MikroTik הוא השימוש בתורים של RouterOS כדי לשלוט בכמה מקישור רשאי כל לקוח, תת-רשת או מחלקת תעבורה לצרוך — הגבלת קצבים, הבטחת מינימום, וקביעה מי מוותר כאשר הקישור מלא. RouterOS מממש תורים באמצעות מתזמן Hierarchical Token Bucket (HTB), החשוף בשני מקומות: תורים פשוטים, רשימה מסודרת המיושמת ברצף, ועץ התורים, היררכיה המחוברת לממשקים או לסימוני חבילות ממנגנון ה-mangle של חומת האש (תיעוד MikroTik — Queues).

ההבחנה קובעת עד כמה התכנון שלכם יתמסד. תור פשוט עונה על “הגבל את הלקוח הזה ל-50 Mbps.” עץ תורים עונה על “קישור העלייה הזה של 500 Mbps משותף ל-300 מנויים, VoIP עובר ראשון, אף אחד לא גווע ברעב, ומורידים כבדים לא הורסים את הערב.” כל ספק אינטרנט זקוק בסופו של דבר לתשובה השנייה.

שלב 1 — הגבילו לקוח אחד בתור פשוט

תורים פשוטים הם הדרך הקצרה ביותר מבעיה לפתרון. כוונו ל-IP, לתת-רשת או לממשק, קבעו את התקרה, וסיימתם:

/queue simple add name=client-101 target=10.10.0.101/32 max-limit=10M/50M

max-limit נכתב כ-upload/download מנקודת מבטו של הנתב. הכללים מוערכים לפי הסדר וההתאמה הראשונה מנצחת — כך שכלל רחב ומוקדם בולע בשקט את הכללים הספציפיים שאתם מוסיפים אחר כך. סדר זה הוא הסיבה הנפוצה ביותר לכך שתור “עובד” מפסיק לעבוד אחרי שמישהו מוסיף כלל מעליו (תיעוד MikroTik — Queues).

תורים פשוטים משתלבים גם עם אימות מנויים: שדה rate-limit בפרופיל PPPoE יוצר תור פשוט דינמי לכל סשן, כך שהתוכניות עוקבות אחר המשתמש ולא אחר ה-IP. מדריך שרת PPPoE של MikroTik לספקי אינטרנט שלנו מכסה את צד הפרופיל.

שלב 2 — סמנו תעבורה עם mangle של חומת האש

עץ התורים אינו יכול לראות “VoIP” או “לקוח 101”; הוא רואה סימוני חבילות. צרו אותם ב-mangle, בסימון החיבור תחילה והחבילות לאחר מכן, וזה זול יותר מבדיקה חוזרת של כל חבילה:

/ip firewall mangle
add chain=forward action=mark-connection new-connection-mark=voip-conn protocol=udp port=5060,10000-20000
add chain=forward action=mark-packet connection-mark=voip-conn new-packet-mark=voip-pkt passthrough=no

שמרו על טקסונומיית הסימונים קטנה ויציבה. הסימונים הם אוצר המילים שהתורים שלכם דוברים, וברגע שלצי יש שלושה דורות של שמות סימון מאולתרים, אף אחד לא יכול לומר איזה נתב אוכף איזו מדיניות. כאן הביקורת וההיסטוריה של התצורות ב-MKController מצדיקות את מקומן: לראות את מצב ה-mangle והתורים של כל נתב, להשוות אותו למדיניות הרצויה, ולדחוף את הכללים המתוקנים על פני כל הצי במקום לפתוח שלושים סשני Winbox כדי למצוא את הנתב האחד שמעולם לא קיבל את השינוי.

שלב 3 — בנו את היררכיית עץ התורים

לעץ תורים יש אב אחד המחזיק את הקיבולת האמיתית של הקישור, ובנים המחלקים אותה:

/queue tree
add name=download parent=bridge-lan max-limit=500M
add name=voip parent=download packet-mark=voip-pkt limit-at=50M max-limit=100M priority=1
add name=bulk parent=download packet-mark=bulk-pkt limit-at=50M max-limit=500M priority=8

שלושה שדות עושים את העבודה. limit-at הוא ההבטחה שבן מקבל גם כאשר הקישור רווי. max-limit היא התקרה שהוא רשאי להגיע אליה כאשר יש קיבולת פנויה. priority — 1 הוא הגבוה ביותר, 8 הנמוך ביותר — קובע איזה בן מקבל את השאריות ראשון, וחל רק בין limit-at ל-max-limit (תיעוד MikroTik — Queues). קבעו את max-limit של האב לפי מה שהקישור מספק בפועל, לא לפי מה שהחוזה אומר, אחרת התור לעולם לא הופך לצוואר הבקבוק ולעולם אינו מעצב דבר.

שלב 4 — הוסיפו PCQ לשיתוף הוגן

Per Connection Queue (PCQ) הוא הסיבה ש-MikroTik מתמסד למספרי מנויים שהופכים רשימת תורים לכל משתמש לבלתי ניתנת לניהול. סוג תור PCQ מסווג תעבורה לפי שדה כתובת ויוצר תת-תור דינמי לכל ערך ייחודי, תוך החלת אותו קצב על כל אחד (תיעוד MikroTik — PCQ example):

/queue type
add name=pcq-down kind=pcq pcq-rate=20M pcq-classifier=dst-address
add name=pcq-up   kind=pcq pcq-rate=10M pcq-classifier=src-address

צרפו את pcq-down בתור ה-queue של הבן הנושא את תעבורת ההורדה של הלקוחות, וכל לקוח מקבל עד 20 Mbps, המוקצים באופן אוטומטי. קבעו pcq-rate=0 ו-PCQ מחלק את רוחב הפס של האב באופן שווה בין כל מי שפעיל — התצורה הקלאסית של “אף אחד לא גווע ברעב”. סוג תור אחד מחליף מאות רשומות שנכתבו ביד.

אותו היגיון של השוואה חל על WiFi משותף: הגבלת הקצב של התוכנית ואב PCQ עוצרים יחד אורח אחד מלצרוך את קישור העלייה של המתחם — ראו את מדריך הגדרת וואוצ’רים HotSpot של MikroTik שלנו לצד האישורים.

שלב 5 — כווננו limit-at, max-limit, burst ו-priority

רוב ה-QoS השבור אינו כלי שגוי, אלא מספרים שגויים. שמרו על סכום ה-limit-at של כל בן שווה או נמוך מ-max-limit של האב; אם ההבטחות מנצלות יתר על המידה את הקישור, HTB אינו יכול לכבד אותן והעדיפויות מפסיקות להתנהג כפי שאתם מצפים. שמרו את priority=1 לתעבורה רגישה להשהיה — VoIP, גיימינג, DNS — ותנו להעברות מרובות לחיות ב-8 עם תקרה נדיבה.

burst ראוי לאזהרה. burst-limit, burst-threshold ו-burst-time מאפשרים ללקוח לחרוג מ-max-limit לזמן קצר בעוד הממוצע שלו נשאר נמוך — מצוין לבדיקות מהירות, גרוע יותר לקישור מנוצל יתר על המידה. מדדו עם /queue simple print stats או עם מוני עץ התורים בזמן שהקישור בעומס, לא ב-3 לפנות בוקר כשהכול במנוחה. אם קריאת מונים בשיא אינה מעשית, תצוגת Internet Link של MKController שומרת על אותה תמונה ברציפות — ניצול מול המהירות החוזית; השהיה כממוצע, מקסימום ו-P95; וכמה שעות כל קישור בילה מעל 90% — כך שאתם מכווננים מול היסטוריה, ולא מול תמונת מצב בת מזל.

גם הקיבולת נעה. בהגדרת גיבוי dual-WAN, ה-max-limit של האב שכווננתם עבור סיבים הוא בדיה ברגע שהתעבורה נוחתת על גיבוי ה-LTE — תכננו מדיניות שנייה.

שלב 6 — פרסו את המדיניות על פני כל הצי

נתב אחד הוא תצורה; מאה נתבים הם מבצע. המדיניות חייבת כעת להיות זהה בכל התקן, לשרוד את הטכנאי ש”זמנית” העלה את התקרה של לקוח, ולהיות ניתנת לשחזור כאשר נתב במגדל עובר netinstall. שום דבר ב-RouterOS אינו עושה זאת עבורכם.

MKController כן: דחיפות על פני כל הצי של סוגי תורים, פרופילי rate-limit וכללי חומת אש; היסטוריית תצורה, כך שתוכלו לראות מתי הגבלה השתנתה ולשחזר את הגרסה הקודמת בלחיצה אחת; גיבויים אוטומטיים לפני שינוי; וגישה מרוחקת יוצאת מאובטחת לנתבים מאחורי CGNAT או על Starlink, ללא IP ציבורי וללא הפניית פורטים — הגישה שאנו מתארים בניהול מרחוק של MikroTik מאחורי CGNAT. וניטור Internet Link שלו צופה באותם קישורי עלייה שזה עתה עיצבתם — ניצול לכל מקור מול המהירות החוזית, השהיה עם P95, וצריכה החוצה את רצועות ה-75% וה-90% על פני עד ארבעה מקורות WAN לכל נתב — כך שקישור המזדחל לעבר רוויה צף בלוח הבקרה, ו(בשילוב עם התראות Telegram) בהתראות שלכם, לפני שמנוי מתקשר. ספקי אינטרנט ו-WISP המריצים MikroTik בקנה מידה משתמשים בו כדי שמדיניות רוחב הפס תישאר החלטה אחת, לא מאה.

טיפים

• עצבו בממשק שממנו התעבורה יוצאת מהנתב; תורים שולטים ביציאה, כך שהורדות מעוצבות בצד ה-LAN והעלאות בצד ה-WAN.
• העדיפו סוג תור PCQ אחד על פני מאות תורים פשוטים ברגע שאתם עוברים כמה עשרות מנויים.
• passthrough=no בכללי mark-packet חוסך מעבר מיותר על שאר כללי ה-mangle.
• תמיד גבו לפני נגיעה בתורים בקצה ייצור, ושנו משתנה אחד בכל פעם.

הפסיקו לנחש לאן הלך רוחב הפס שלכם

תורים הם ההבדל בין למכור תוכנית ובין לספק אותה. תורים פשוטים מגבילים לקוח, עצי תורים נותנים מבנה ועדיפות, PCQ הופך את ההוגנות לאוטומטית — ו-MKController הופך את שלושתם למדיניות שאתם מיישמים פעם אחת ואוכפים בכל מקום: ניהול צי מרכזי, דחיפות rate-limit וחומת אש לכל נתב, היסטוריית תצורה עם שחזור בלחיצה אחת, גישה מרוחקת ללא IP ציבורי, וניטור Internet Link שמסמן קישור המתקרב לרוויה מול המהירות החוזית שלו לפני שהלקוחות שלכם עושים זאת.

התחילו את תקופת הניסיון החינמית של MKController