Tutorial
מדריך עדכון ותיקון MikroTik RouterOS
כיצד לעדכן ולתקן MikroTik RouterOS במערך ISP: ערוצי גרסאות, פריסה מדורגת, גיבויים, שחזור ופרצות ה-CVE של 2026.
תקציר עדכון של MikroTik RouterOS על פני מערך ISP הוא תהליך מבוקר, לא פעולה בלחיצה אחת. בחרו ערוץ גרסאות שתואם להסכמי ה-SLA שלכם, גבו כל מכשיר, אמתו על פיילוט, ואז פרסו בגלים מודעי-טופולוגיה עם נתיב שחזור ברור. בשנת 2026 זה חשוב מתמיד: פרצה בת-ניצול ציבורי ב-RouterOS (CVE-2026-7668) וגרסת stable טרייה (7.23.1) פירושן שנתבי קצה לא-מתוקנים מהווים סיכון פעיל.
מהו תיקון RouterOS עבור מערך ISP?
תיקון RouterOS הוא התהליך הממושמע של העלאת אוכלוסיית מכשירי MikroTik מגרסת RouterOS אחת לחדשה יותר כדי לתקן פרצות אבטחה, באגי יציבות ורגרסיות התנהגות — בלי לשבור את השירותים הרצים מעליהם. על נתב ביתי בודד זו משימה של שתי דקות. על פני מאות או אלפי מכשירי CPE ונתבי קצה, זה הופך לתוכנית תפעולית: דרושים לכם מדיניות ערוץ גרסאות, תקן גיבוי, שלב staging, פריסה מדורגת ותוכנית שחזור. המטרה קלה לניסוח וקשה לביצוע בקנה מידה גדול — כל מכשיר מסתיים מתוקן, ואף אחד מהם לא נכבה בדרך.
זה ראוי לזרימת עבודה אמיתית משום ששדרוג נוגע בדיוק בדבר שאינכם יכולים להגיע אליו שוב בקלות אם הוא נכשל: נתב בקצה הלקוח, לרוב מאחורי CGNAT. דחיפה כושלת שמאבדת את גישת הניהול הופכת לקריאת שירות בשטח. לכן זרימת העבודה שלהלן ממטבת תחילה לבטיחות ולנגישות, ורק לאחר מכן למהירות.
למה לתקן עכשיו: תמונת האבטחה של 2026
קצב התיקונים נשאר משימת רקע שקטה עד שפרצה כופה את הנושא, ו-2026 מספקת סיבות קונקרטיות להדק אותו. CVE-2026-7668 הוא קריאה מחוץ-לגבולות בנקודת הקצה SCEP של RouterOS עם דירוג CVSS 7.3 (גבוה); ניתן להפעיל אותו מרחוק וקיים ניצול ציבורי. התראות נפרדות במחזור זה מכסות בעיית בקרת-גישה לקויה באימות כתובת-המקור של VXLAN (תוקן ב-RouterOS 7.20 ואילך) ופרצת השחתת זיכרון בשירות SMB שתוקף לא-מאומת יכול להפעיל בעזרת חבילות מעוצבות.
ההנחיה של MikroTik עקבית: שמרו על RouterOS מעודכן ומאחורי חומת אש החוסמת רשתות לא-מהימנות. ענף ה-stable הנוכחי, RouterOS 7.23.1 (שוחרר ב-2 ביוני 2026), מתקן גם דליפת זיכרון ב-BGP ובעיית יציבות ב-DHCPv4-snooping. זו הסיבה הרגילה לכך שמערכים זקוקים לתהליך תיקון חוזר ולא לשדרוגים אד-הוק.
שלב 1 — בחרו את ערוץ הגרסאות הנכון
RouterOS מציע יותר מענף אחד, והבחירה היא החלטת מדיניות, לא העדפה. גרסאות stable יוצאות אחת לכמה חודשים עם תכונות ותיקונים נבדקים; גרסאות long-term מקבלות רק תיקונים קריטיים ותיקוני אבטחה, ומשתנות הרבה פחות בין גרסאות. עבור מערכי קצה ו-CPE של ספקי ISP שמעריכים צפיות, ענף ה-long-term הוא לרוב בחירת ברירת המחדל הנכונה, כאשר stable שמור לחומרה או לתכונות שמחייבות זאת. מה שלא תבחרו: לעולם אל תריצו גרסאות testing או development בייצור. תעדו את הענף לפי מחלקת מכשירים, כדי שההחלטה תהיה חוזרת על פני הצוות.
שלב 2 — גבו וייצאו תחילה
לעולם אל תשדרגו בלי נקודת שחזור. צרו גם גיבוי בינארי (/system backup save) וגם ייצוא תצורה קריא לבני אדם (/export file=), משום שהייצוא שורד שינויי גרסה ומאפשר לכם לבנות מחדש גם אם גיבוי בינארי לא ישוחזר על גרסה אחרת. משכו את שניהם מהמכשיר אל מערכת הניהול שלכם. אמתו שיש מספיק שטח פנוי לחבילות החדשות לפני שאתם מתחילים, והעדיפו חיבור קווי או חיבור קונסולה — שדרוג דרך Wi-Fi או חיבור רעוע הוא הדרך שבה נתבים נשרפים באמצע הכתיבה. עבור מכשירים שבהם גישת השחזור היא הדאגה האמיתית, מדריך השחזור עם Netinstall שלנו הוא הגיבוי כאשר שדרוג משתבש.
שלב 3 — בדקו על מכשיר פיילוט
שדרגו תחילה נתב מייצג אחד ועקבו אחריו. בחרו מכשיר שמשקף מחלקת ייצור — אותו דגם, אותו תפקיד, תצורה דומה — והחילו את גרסת היעד במהלך חלון תחזוקה. לאחר שהוא מתאתחל, אמתו את הגרסה, ודאו שהחבילות מופעלות, וסקרו את ה-changelog לאיתור שינויי התנהגות המשפיעים על התצורה שלכם (סמנטיקת חומת אש, שירותי ברירת מחדל, מתן שמות לממשקים). רק לאחר שהפיילוט נקי, אתם מאשרים את הפריסה הרחבה יותר. שלב בודד זה מונע את מצב הכשל היקר ביותר: גילוי רגרסיה לאחר שכבר נשלחה לאלף לקוחות.
שלב 4 — פרסו בגלים מודעי-טופולוגיה
פריסה המונית עוסקת בסדר ובקצב, לא בלחיצה על כפתור בכל מקום בבת אחת. קבצו מכשירים לפי טופולוגיה כך שנתבים משורשרים יתעדכנו ברצף — אינכם רוצים שנתב במעלה הזרם יתאתחל לפני שמכשיר במורד הזרם הספיק להוריד את חבילותיו. הגדירו גלים עם חלונות תחזוקה משלהם, ועקבו אחר כל מכשיר ברשימת התאמה, כך שכל יחידה עם בעיה תיכנס מחדש לתור ולא תישכח. כדי לחסוך ברוחב פס אינטרנט, הפנו את המכשירים לנתב מרכזי המשמש כמראת חבילות מקומית; זה גם שולט באיזו גרסה המערך רשאי להוריד.
פריסה מדורגת עובדת רק אם אתם באמת יכולים להגיע לכל מכשיר כדי לאשר שהוא חזר. זו המלכודת התפעולית עם CPE מאחורי CGNAT — וכאן ניהול מרכזי מצדיק את עצמו.
שלב 5 — אמתו, ואז שחזרו במידת הצורך
לאחר כל גל, אשרו את התוצאה: בדקו את הגרסה המדווחת, ודאו שגם קושחת ה-routerboard שודרגה היכן שרלוונטי (/system routerboard upgrade), ואמתו שהשירותים שחשובים לכם מעבירים תעבורה. אם מכשיר מתנהג בצורה שגויה, שחזרו את הגיבוי הבינארי הקודם, או בנו מחדש מייצוא ה-RSC, או התקינו מחדש את הגרסה הקודמת עם Netinstall כמוצא אחרון. תוכנית תיקון אינה „גמורה” כאשר הגרסה החדשה מותקנת — היא גמורה כאשר כל מכשיר אומת כתקין וכל חריג נעקב עד לסגירתו.
טיפים לתיקון בקנה מידה של מערך
- תקננו קו-בסיס מוקשח יחיד כדי ששדרוגים יהיו צפויים. שיטות העבודה המומלצות לאבטחת Winbox ומדריך תפעול האבטחה של device-mode שלנו מגדירים את קו-הבסיס שאליו ניתן לעקוב את מרבית בעיות השדרוג.
- הגבילו את גישת הניהול ל-VPN או לכתובות IP מהימנות לפני ואחרי שדרוגים, כך שמערך מתוקן-למחצה לעולם לא ייחשף.
- שמרו על מישור הניהול נגיש גם מאחורי CGNAT, כך שאימות ושחזור לא יחייבו ביקור באתר.
- סקרו את התראות האבטחה של MikroTik לפי לוח זמנים במקום להמתין לאירוע.
שאלות נפוצות
באיזו תדירות עליי לעדכן את RouterOS? העריכו כל גרסה מול מדיניות הענף שלכם, ותקנו מחוץ-למחזור בכל פעם שהתראה משפיעה על שירותים שאתם חושפים. אין מרווח קבוע — רק קצב המונע על ידי סיכון.
Stable או long-term עבור מערך ISP? Long-term הוא ברירת המחדל הבטוחה יותר עבור קצה ו-CPE; השתמשו ב-stable היכן שאתם זקוקים לתמיכת חומרה חדשה יותר או לתכונות, לאחר אימות ב-staging.
מה אם שדרוג שורף מכשיר מרוחק? שחזרו מגיבוי או מייצוא RSC; אם המכשיר אינו נגיש, הצילו אותו עם Netinstall. זו הסיבה שגיבוי נבדק ונתיב ניהול נגיש הם חובה לפני כל גל.
תקנו את כל המערך שלכם בלי קריאות שירות בשטח
החלק הקשה ביותר בתיקון מערך אינו השדרוג — אלא ההגעה לכל מכשיר ואימותו לאחר מכן, במיוחד CPE מאחורי CGNAT. MKController מרכז את הנראות על פני כל מערך ה-MikroTik שלכם, ו-NATCloud מעניק לכם נגישות מבפנים-החוצה ללא port forwarding, כך שפריסות מדורגות, אימות ושחזור מתרחשים כולם מרחוק.