יסודות של ניתוב סטטי ב-Mikrotik RouterOS

ניתוב הוא תהליך מציאת הנתיב הטוב ביותר להעברת מנות דרך רשתות TCP/IP. כל מכשיר המחובר לרשת IPv4 מכיל תהליך וטבלאות ניתוב.

מאמר זה אינו HOWTO, הוא מתאר ניתוב סטטי ב-RouterOS עם דוגמאות, השמטתי בכוונה את שאר ההגדרות (למשל, srcnat לגישה לאינטרנט), כך שהבנת החומר דורשת רמה מסוימת של ידע ברשתות ו-RouterOS.

מיתוג וניתוב

מיתוג הוא תהליך של החלפת מנות בתוך מקטע Layer2 אחד (Ethernet, ppp, ...). אם המכשיר רואה שהמקבל של החבילה נמצא באותה רשת Ethernet איתו, הוא לומד את כתובת ה-mac באמצעות פרוטוקול arp ומשדר את החבילה ישירות, תוך עקיפת הנתב. לחיבור ppp (נקודה לנקודה) יכולים להיות רק שני משתתפים והמנה נשלחת תמיד לכתובת אחת 0xff.

ניתוב הוא תהליך העברת מנות בין מקטעי Layer2. אם מכשיר רוצה לשלוח חבילה שהנמען שלה נמצא מחוץ לקטע ה-Ethernet, הוא מסתכל בטבלת הניתוב שלו ומעביר את החבילה לשער, שיודע לאן לשלוח את החבילה הבא (או שלא יודע, השולח המקורי של החבילה לא מודע לזה).

הדרך הקלה ביותר לחשוב על נתב היא כמכשיר המחובר לשני מקטעי Layer2 או יותר ומסוגל להעביר מנות ביניהם על ידי קביעת המסלול הטוב ביותר מטבלת הניתוב.

אם אתה מבין הכל, או שכבר ידעת את זה, אז המשך לקרוא. לכל השאר, אני ממליץ לך בחום להכיר קובץ קטן, אך רב עוצמה מאמרים.

ניתוב ב-RouterOS ו-PacketFlow

כמעט כל הפונקציונליות הקשורה לניתוב סטטי נמצאת בחבילה מערכת. שקית פלסטיק ניתוב מוסיף תמיכה באלגוריתמי ניתוב דינמיים (RIP, OSPF, BGP, MME), מסנני ניתוב ו-BFD.

תפריט ראשי להגדרת ניתוב: [IP]->[Route]. תוכניות מורכבות עשויות לדרוש חבילות להיות מתויגות מראש עם סימן ניתוב ב: [IP]->[Firewall]->[Mangle] (שרשראות PREROUTING и OUTPUT).

ישנם שלושה מקומות ב-PacketFlow שבהם מתקבלות החלטות ניתוב מנות IP:

1. מנות מנות שהתקבלו על ידי הנתב. בשלב זה מחליטים האם החבילה תעבור לתהליך המקומי או תישלח הלאה לרשת. חבילות טרנזיט מקבלים ממשק פלט
2. ניתוב מנות יוצאות מקומיות. קבלת מנות יוצאות ממשק פלט
3. שלב ניתוב נוסף עבור מנות יוצאות, מאפשר לך לשנות את החלטת הניתוב פנימה [Output|Mangle]

• נתיב החבילה בבלוקים 1, 2 תלוי בכללים ב [IP]->[Route]
• נתיב החבילה בנקודות 1, 2 ו-3 תלוי בכללים ב [IP]->[Route]->[Rules]
• ניתן להשפיע על נתיב החבילה בבלוקים 1, 3 באמצעות [IP]->[Firewall]->[Mangle]

RIB, FIB, מטמון ניתוב

בסיס מידע ניתוב
הבסיס בו נאספים מסלולים מפרוטוקולי ניתוב דינמיים, מסלולים מ-ppp ו-dhcp, מסלולים סטטיים ומקושרים. מסד נתונים זה מכיל את כל המסלולים, מלבד אלו שסוננו על ידי המנהל.

בתנאי, אנו יכולים להניח זאת [IP]->[Route] מציג RIB.

בסיס מידע להעברת מידע

הבסיס בו נאספים המסלולים הטובים ביותר מ-RIB. כל המסלולים ב-FIB פעילים ומשמשים להעברת מנות. אם המסלול הופך ללא פעיל (מושבת על ידי המנהל (מערכת), או שהממשק שדרכו יש לשלוח את החבילה אינו פעיל), המסלול מוסר מה-FIB.

כדי לקבל החלטת ניתוב, טבלת FIB משתמשת במידע הבא על חבילת IP:

• כתובת המקור
• כתובת יעד
• ממשק מקור
• סימן ניתוב
• ToS (DSCP)

הכניסה לחבילת FIB עוברת את השלבים הבאים:

• האם החבילה מיועדת לתהליך נתב מקומי?
• האם החבילה כפופה לחוקי PBR של המערכת או המשתמש?
  • אם כן, החבילה נשלחת לטבלת הניתוב שצוינה
• החבילה נשלחת לטבלה הראשית

בתנאי, אנו יכולים להניח זאת [IP]->[Route Active=yes] מציג FIB.

מטמון ניתוב
מנגנון שמירה במטמון של מסלול. הנתב זוכר לאן נשלחו החבילות ואם יש כאלה דומות (ככל הנראה מאותו חיבור) הוא נותן להן לעבור באותו מסלול, מבלי לבדוק ב-FIB. מטמון המסלול מנוקה מעת לעת.

עבור מנהלי RouterOS, הם לא יצרו כלים לצפייה וניהול של מטמון הניתוב, אלא כאשר ניתן להשבית אותו ב [IP]->[Settings].

מנגנון זה הוסר מ-Linux 3.6, אבל RouterOS עדיין משתמש ב-Line 3.3.5, אולי ניתוב cahce הוא אחת הסיבות.

דו-שיח הוסף מסלול

[IP]->[Route]->[+]

1. רשת משנה שעבורה ברצונך ליצור נתיב (ברירת מחדל: 0.0.0.0/0)
2. שער IP או ממשק שאליו תישלח החבילה (ייתכנו כמה, ראה ECMP להלן)
3. בדיקת זמינות שער
4. סוג הקלטה
5. מרחק (מטרי) למסלול
6. טבלת ניתוב
7. IP עבור מנות יוצאות מקומיות דרך נתיב זה
8. המטרה של היקף והיקף יעד נכתבת בסוף המאמר.

דגלי מסלול

• X - המסלול מושבת על ידי מנהל המערכת (disabled=yes)
• ת - המסלול משמש לשליחת מנות
• D - מסלול נוסף באופן דינמי (BGP, OSPF, RIP, MME, PPP, DHCP, מחובר)
• C - רשת המשנה מחוברת ישירות לנתב
• S - מסלול סטטי
• r,b,o,m - מסלול נוסף על ידי אחד מפרוטוקולי הניתוב הדינמיים
• B,U,P - מסלול סינון (מפיל מנות במקום שידור)

מה לציין בשער: כתובת ip או ממשק?

המערכת מאפשרת לציין את שניהם, בעוד שהיא לא מקללת ולא נותנת רמזים אם עשית משהו לא בסדר.

כתובת IP
כתובת השער חייבת להיות נגישה דרך Layer2. עבור Ethernet, זה אומר שלנתב חייבת להיות כתובת מאותה רשת משנה באחד מממשקי ה-IP הפעילים, עבור ppp, שכתובת השער מצוינת באחד הממשקים הפעילים ככתובת רשת המשנה.
אם לא מתקיים תנאי הנגישות של Layer2, המסלול נחשב ללא פעיל ואינו נכנס ל-FIB.

ממשק
הכל יותר מסובך והתנהגות הנתב תלויה בסוג הממשק:

• חיבור PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) מניח שני משתתפים בלבד והמנה תישלח תמיד לשער לשידור, אם השער יזהה שהנמען הוא עצמו, אז הוא יעביר את החבילה ל התהליך המקומי שלו.
  
• Ethernet מניח נוכחות של משתתפים רבים וישלח בקשות לממשק arp עם הכתובת של מקבל החבילה, זו התנהגות צפויה ודי נורמלית עבור מסלולים מחוברים.
  אך כאשר תנסו להשתמש בממשק כמסלול עבור תת-רשת מרוחקת, תקבלו את המצב הבא: המסלול פעיל, פינג לשער עובר, אך אינו מגיע לנמען מרשת המשנה שצוינה. אם תסתכל על הממשק דרך סניפר, תראה בקשות arp עם כתובות מרשת משנה מרוחקת.
  

נסה לציין את כתובת ה-IP כשער במידת האפשר. היוצא מן הכלל הוא מסלולים מחוברים (נוצרים אוטומטית) וממשקי PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*).

OpenVPN אינו מכיל כותרת PPP, אך אתה יכול להשתמש בשם ממשק OpenVPN כדי ליצור מסלול.

מסלול ספציפי יותר

כלל ניתוב בסיסי. המסלול המתאר את רשת המשנה הקטנה יותר (עם מסכת רשת המשנה הגדולה ביותר) מקבל עדיפות בהחלטת הניתוב של החבילה. מיקום הערכים בטבלת הניתוב אינו רלוונטי לבחירה - הכלל העיקרי הוא More Specific.

כל המסלולים מהתכנית שצוינה פעילים (ממוקמים ב-FIB). מצביעים על רשתות משנה שונות ואינן מתנגשות זו עם זו.

אם אחד השערים לא יהיה זמין, המסלול המשויך ייחשב כלא פעיל (הוסר מה-FIB) ויחפשו מנות מהמסלולים הנותרים.

המסלול עם רשת המשנה 0.0.0.0/0 זוכה לפעמים למשמעות מיוחדת והוא נקרא "מסלול ברירת המחדל" או "שער המוצא האחרון". למעשה, אין בו שום דבר קסום והוא פשוט כולל את כל כתובות ה-IPv4 האפשריות, אבל השמות הללו מתארים היטב את המשימה שלו – הוא מציין את השער לאן להעביר מנות שאין להן מסלולים אחרים ומדויקים יותר.

מסכת רשת המשנה המרבית האפשרית עבור IPv4 היא /32, מסלול זה מצביע על מארח ספציפי וניתן להשתמש בו בטבלת הניתוב.

הבנת נתיב ספציפי יותר היא בסיסית לכל מכשיר TCP/IP.

מֶרְחָק

מרחקים (או מדדים) נדרשים עבור סינון ניהולי של מסלולים לרשת משנה אחת הנגישה דרך שערים מרובים. מסלול עם מדד נמוך יותר נחשב בעדיפות וייכלל ב-FIB. אם מסלול עם מדד נמוך יותר מפסיק להיות פעיל, אזי הוא יוחלף במסלול עם מדד גבוה יותר ב-FIB.

אם ישנם מספר מסלולים לאותה תת-רשת עם אותו מדד, הנתב יוסיף רק אחד מהם לטבלת FIB, בהנחיית ההיגיון הפנימי שלו.

המדד יכול לקחת ערך מ-0 עד 255:

• 0 - מדד למסלולים מחוברים. לא ניתן להגדיר מרחק 0 על ידי מנהל המערכת
• 1-254 - מדדים זמינים למנהל המערכת להגדרת מסלולים. למדדים עם ערך נמוך יותר יש עדיפות גבוהה יותר
• 255 - מדד זמין למנהל להגדרת מסלולים. שלא כמו 1-254, מסלול עם מדד של 255 תמיד נשאר לא פעיל ואינו נכנס ל-FIB
• מדדים ספציפיים. למסלולים הנגזרים מפרוטוקולי ניתוב דינמיים יש ערכים מטריים סטנדרטיים

לבדוק שער

Check gateway הוא הרחבה של MikroTik RoutesOS לבדיקת זמינות השער באמצעות icmp או arp. אחת ל-10 שניות (לא ניתן לשנות), נשלחת בקשה לשער, אם התגובה לא מתקבלת פעמיים, המסלול נחשב כלא זמין ומוסר מה-FIB. אם שער הבדיקה הושבת, מסלול הבדיקה ממשיך והמסלול יחזור להיות פעיל לאחר בדיקה אחת מוצלחת.

Check gateway משבית את הערך שבו הוא מוגדר ואת כל הערכים האחרים (בכל טבלאות הניתוב ובנתיבי ecmp) עם השער שצוין.

באופן כללי, בדוק שער עובד בסדר כל עוד אין בעיות עם אובדן מנות לשער. Check gateway לא יודע מה קורה עם תקשורת מחוץ לשער המסומן, זה דורש כלים נוספים: סקריפטים, ניתוב רקורסיבי, פרוטוקולי ניתוב דינמיים.

רוב פרוטוקולי ה-VPN והמנהרות מכילים כלים מובנים לבדיקת פעילות החיבור, הפעלת שער הבדיקה עבורם מהווה עומס נוסף (אך קטן מאוד) על הרשת והביצועים של המכשיר.

מסלולי ECMP

Equal-Cost Multi-Path - שליחת מנות לנמען באמצעות מספר שערים בו זמנית באמצעות אלגוריתם Round Robin.

נתיב ECMP נוצר על ידי המנהל על ידי ציון שערים מרובים עבור רשת משנה אחת (או אוטומטית, אם יש שני מסלולי OSPF שווים).

ECMP משמש לאיזון עומסים בין שני ערוצים, בתיאוריה, אם יש שני ערוצים במסלול ecmp, אז עבור כל חבילה הערוץ היוצא צריך להיות שונה. אבל מנגנון ה-Roting cache שולח מנות מהחיבור לאורך המסלול שהחבילה הראשונה עברה, כתוצאה מכך, אנו מקבלים מעין איזון המבוסס על חיבורים (איזון טעינה לפי חיבור).

אם תשבית את מטמון הניתוב, אז החבילות במסלול ה-ECMP ישותפו כהלכה, אבל יש בעיה עם NAT. כלל ה-NAT מעבד רק את החבילה הראשונה מהחיבור (השאר מעובדים אוטומטית), ומסתבר שמנות עם אותה כתובת מקור משאירות ממשקים שונים.

בדוק שהשער אינו פועל בנתיבי ECMP (באג של RouterOS). אבל אתה יכול לעקוף את המגבלה הזו על ידי יצירת מסלולי אימות נוספים שישביתו ערכים ב-ECMP.

סינון באמצעות ניתוב

האפשרות Type קובעת מה לעשות עם החבילה:

• unicast - שלח לשער שצוין (ממשק)
• blackhole - לזרוק חבילה
• אסור, בלתי ניתן להשגה - השלך את החבילה ושלח הודעת icmp לשולח

בדרך כלל משתמשים בסינון כאשר יש צורך לאבטח את שליחת מנות בנתיב הלא נכון, כמובן שניתן לסנן זאת דרך חומת האש.

כמה דוגמאות

כדי לאחד את הדברים הבסיסיים על ניתוב.

ראוטר ביתי טיפוסי

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1

1. מסלול סטטי ל-0.0.0.0/0 (מסלול ברירת מחדל)
2. מסלול מחובר בממשק עם הספק
3. מסלול מחובר בממשק LAN

נתב ביתי טיפוסי עם PPPoE

1. נתיב סטטי למסלול ברירת מחדל, נוסף אוטומטית. זה מצוין במאפייני החיבור
2. מסלול מחובר לחיבור PPP
3. מסלול מחובר בממשק LAN

נתב ביתי טיפוסי עם שני ספקים ויתירות

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

1. נתיב סטטי למסלול ברירת מחדל דרך הספק הראשון עם מדד 1 ובדיקת זמינות שער
2. נתיב סטטי למסלול ברירת מחדל דרך ספק שני עם מדד 2
3. מסלולים מחוברים

התנועה ל-0.0.0.0/0 עוברת דרך 10.10.10.1 בזמן שהשער הזה זמין, אחרת היא עוברת ל-10.20.20.1

תכנית כזו יכולה להיחשב כהזמנת ערוץ, אך היא אינה נטולת חסרונות. אם מתרחשת הפסקה מחוץ לשער הספק (לדוגמה, בתוך הרשת של המפעיל), הנתב שלך לא יידע על כך וימשיך להתייחס למסלול כפעיל.

נתב ביתי טיפוסי עם שני ספקים, יתירות ו-ECMP

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.10.10.1,10.20.20.1 distance=1

1. מסלולים סטטיים לבדיקת שער צ'אק
2. מסלול ECMP
3. מסלולים מחוברים

המסלולים לבדיקה הם כחולים (הצבע של מסלולים לא פעילים), אבל זה לא מפריע לשער הבדיקה. הגרסה הנוכחית (6.44) של RoS נותנת עדיפות אוטומטית למסלול ECMP, אך עדיף להוסיף מסלולי בדיקה לטבלאות ניתוב אחרות (אפשרות routing-mark)

ב-Speedtest ובאתרים דומים אחרים, לא תהיה עלייה במהירות (ECMP מחלק את התעבורה לפי חיבורים, לא לפי מנות), אבל אפליקציות p2p אמורות להוריד מהר יותר.

סינון באמצעות ניתוב

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1
add dst-address=192.168.200.0/24 gateway=10.30.30.1 distance=1
add dst-address=192.168.200.0/24 gateway=10.10.10.1 distance=2 type=blackhole

1. נתיב סטטי למסלול ברירת מחדל
2. מסלול סטטי ל-192.168.200.0/24 מעל מנהרת ipip
3. אוסר על נתיב סטטי ל-192.168.200.0/24 דרך נתב ISP

אפשרות סינון שבה תעבורת מנהרה לא תעבור לנתב של הספק כאשר ממשק ipip מושבת. תוכניות כאלה נדרשות לעתים רחוקות, כי אתה יכול ליישם חסימה דרך חומת האש.

לולאת ניתוב
לולאת ניתוב - מצב שבו חבילה פועלת בין נתבים לפני שה-ttl פג. בדרך כלל זה תוצאה של שגיאת תצורה, ברשתות גדולות זה מטופל על ידי יישום של פרוטוקולי ניתוב דינמיים, בקטנות - בזהירות.

זה נראה בערך כך:

דוגמה (הפשוטה ביותר) כיצד להשיג תוצאה דומה:

הדוגמה של לולאת הניתוב אינה מועילה בפועל, אך היא מראה שלנתבים אין מושג לגבי טבלת הניתוב של שכניהם.

ניתוב בסיס מדיניות וטבלאות ניתוב נוספות

בעת בחירת מסלול, הנתב משתמש רק בשדה אחד מכותרת החבילה (Dst. Address) - זהו ניתוב בסיסי. ניתוב המבוסס על תנאים אחרים, כגון כתובת מקור, סוג תעבורה (ToS), איזון ללא ECMP, שייך ל-Policy Base Routing (PBR) ומשתמש בטבלאות ניתוב נוספות.

מסלול ספציפי יותר הוא כלל בחירת המסלול העיקרי בטבלת הניתוב.

כברירת מחדל, כל כללי הניתוב מתווספים לטבלה הראשית. המנהל יכול ליצור מספר שרירותי של טבלאות ניתוב נוספות ולנתב אליהן מנות. כללים בטבלאות שונות אינם מתנגשים זה עם זה. אם החבילה לא מוצאת כלל מתאים בטבלה שצוינה, היא תעבור לטבלה הראשית.

דוגמה להפצה באמצעות חומת אש:

• 192.168.100.10 -> 8.8.8.8
  1. תנועה מ-192.168.100.10 מקבלת תווית via-isp1 в [Prerouting|Mangle]
  2. בשלב הניתוב בטבלה via-isp1 מחפש מסלול ל-8.8.8.8
  3. נתיב נמצא, התנועה נשלחת לשער 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. תנועה מ-192.168.200.20 מקבלת תווית via-isp2 в [Prerouting|Mangle]
  2. בשלב הניתוב בטבלה via-isp2 מחפש מסלול ל-8.8.8.8
  3. נתיב נמצא, התנועה נשלחת לשער 10.20.20.1
• אם אחד השערים (10.10.10.1 או 10.20.20.1) לא יהיה זמין, החבילה תעבור לטבלה ראשי ויחפש שם מסלול מתאים

בעיות טרמינולוגיה

ל-RouterOS יש בעיות טרמינולוגיה מסוימות.
כשעובדים עם כללים ב [IP]->[Routes] טבלת הניתוב מצוינת, למרות שכתוב שהתווית:

В [IP]->[Routes]->[Rule] הכל נכון, במצב התווית בפעולת הטבלה:

כיצד לשלוח חבילה לטבלת ניתוב ספציפית

RouterOS מספק מספר כלים:

• שולט ב [IP]->[Routes]->[Rules]
• סמני מסלול (action=mark-routing) ב [IP]->[Firewall]->[Mangle]
• VRF

תקנות [IP]->[Route]->[Rules]
כללים מעובדים ברצף, אם החבילה תואמת את תנאי הכלל, היא לא עוברת הלאה.

כללי ניתוב מאפשרים לך להרחיב את אפשרויות הניתוב, תוך הסתמכות לא רק על כתובת הנמען, אלא גם על כתובת המקור והממשק שעליו התקבלה החבילה.

כללים מורכבים מתנאים ומפעולה:

• תנאים. חזור למעשה על רשימת הסימנים שלפיהם החבילה נבדקת ב-FIB, רק ToS חסר.
• פעילות
  • חיפוש - שלח חבילה לטבלה
  • חפש רק בטבלה - נעל את החבילה בטבלה, אם המסלול לא נמצא, החבילה לא תעבור לטבלה הראשית
  • drop - זרוק חבילה
  • בלתי ניתנת להשגה - השליכו את החבילה עם הודעת השולח

ב-FIB, התעבורה לתהליכים מקומיים מעובדת תוך עקיפת הכללים [IP]->[Route]->[Rules]:

סימון [IP]->[Firewall]->[Mangle]
תוויות ניתוב מאפשרות לך להגדיר את השער עבור מנה כמעט בכל תנאי חומת אש:

למעשה, כי לא כולם הגיוניים, וחלקם עשויים לעבוד בצורה לא יציבה.

ישנן שתי דרכים לתייג חבילה:

• מיד לשים סימן ניתוב
• שים קודם סימן חיבור, אז מבוסס על סימן חיבור לשים סימן ניתוב

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

דוגמאות לשימוש

בואו נעבור לדוגמאות של שימוש ב-Policy Base Routing, הרבה יותר קל להראות מדוע כל זה נחוץ.

MultiWAN ותנועה יוצאת חוזרת (פלט).
בעיה נפוצה בתצורת MultiWAN: Mikrotik זמין מהאינטרנט רק דרך ספק "פעיל".

לנתב לא אכפת לאיזה ip הגיעה הבקשה, בעת יצירת תגובה, הוא יחפש מסלול בטבלת הניתוב שבו המסלול דרך isp1 פעיל. יתרה מכך, סביר להניח שחבילה כזו תסונן בדרך אל הנמען.

עוד נקודה מעניינת. אם קוד מקור "פשוט" מוגדר בממשק ether1: /ip fi nat add out-interface=ether1 action=masquerade החבילה תעבור לאינטרנט עם src. address=10.10.10.100, מה שמחמיר עוד יותר.

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

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping distance=2
add dst-address=0.0.0.0/0 gateway=10.10.10.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 routing-mark=over-isp2

להשתמש [IP]->[Route]->[Rules]
ציין את טבלת הניתוב שתשמש עבור מנות עם ה-IP המקור שצוין.

/ip route rule
add src-address=10.10.10.100/32 action=lookup-only-in-table table=over-isp1
add src-address=10.20.20.200/32 action=lookup-only-in-table table=over-isp2

ניתן להשתמש action=lookup, אך עבור תעבורה יוצאת מקומית, אפשרות זו מוציאה לחלוטין חיבורים מהממשק הלא נכון.

• המערכת מייצרת חבילת תגובה עם Src. כתובת: 10.20.20.200
• שלב בדיקת החלטת הניתוב(2). [IP]->[Routes]->[Rules] והחבילה נשלחת לטבלת הניתוב over-isp2
• על פי טבלת הניתוב, יש לשלוח את החבילה לשער 10.20.20.1 דרך ממשק ether2

שיטה זו אינה דורשת Connection Tracker עובד, בניגוד לשימוש בטבלת Mangle.

להשתמש [IP]->[Firewall]->[Mangle]
החיבור מתחיל עם חבילה נכנסת, אז אנחנו מסמנים אותה (action=mark-connection), עבור מנות יוצאות מחיבור מסומן, הגדר את תווית הניתוב (action=mark-routing).

/ip firewall mangle
#Маркировка входящих соединений
add chain=input in-interface=ether1 connection-state=new action=mark-connection new-connection-mark=from-isp1
add chain=input in-interface=ether2 connection-state=new action=mark-connection new-connection-mark=from-isp2
#Маркировка исходящих пакетов на основе соединений
add chain=output connection-mark=from-isp1 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=output connection-mark=from-isp2 action=mark-routing new-routing-mark=over-isp2 passthrough=no

אם מוגדרים מספר IPS בממשק אחד, אתה יכול להוסיף לתנאי dst-address כדי להיות בטוח.

• חבילה פותחת את החיבור בממשק ether2. החבילה נכנסת [INPUT|Mangle] שאומר לסמן את כל החבילות מהחיבור בתור מ-isp2
• המערכת מייצרת חבילת תגובה עם Src. כתובת: 10.20.20.200
• בשלב החלטת הניתוב(2), החבילה, בהתאם לטבלת הניתוב, נשלחת לשער 10.20.20.1 דרך ממשק ether1. אתה יכול לאמת זאת על ידי כניסה לחבילות [OUTPUT|Filter]
• בשלב [OUTPUT|Mangle] תווית החיבור מסומנת מ-isp2 והחבילה מקבלת תווית מסלול over-isp2
• שלב התאמת ניתוב (3) בודק את נוכחותה של תווית ניתוב ושולח אותה לטבלת הניתוב המתאימה
• על פי טבלת הניתוב, יש לשלוח את החבילה לשער 10.20.20.1 דרך ממשק ether2

MultiWAN והחזרת תעבורת dst-nat

דוגמה יותר מסובכת, מה לעשות אם יש שרת (לדוגמה, אינטרנט) מאחורי הנתב ברשת משנה פרטית ואתה צריך לספק גישה אליו דרך כל אחד מהספקים.

/ip firewall nat
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether1 action=dst-nat to-address=192.168.100.100
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether2 action=dst-nat to-address=192.168.100.100

מהות הבעיה תהיה זהה, הפתרון דומה לאפשרות Firewall Mangle, רק רשתות אחרות ישמשו:

/ip firewall mangle
add chain=prerouting connection-state=new in-interface=ether1 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp1
add chain=prerouting connection-state=new in-interface=ether2 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp2
add chain=prerouting connection-mark=web-input-isp1 in-interface=ether3 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting connection-mark=web-input-isp2 in-interface=ether3 action=mark-routing new-routing-mark=over-isp2 passthrough=no

התרשים לא מראה NAT, אבל אני חושב שהכל ברור.

MultiWAN וחיבורים יוצאים

אתה יכול להשתמש ביכולות PBR כדי ליצור חיבורי VPN מרובים (SSTP בדוגמה) מממשקי נתב שונים.

טבלאות ניתוב נוספות:

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.100.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 routing-mark=over-isp3

add dst-address=0.0.0.0/0 gateway=192.168.100.1 distance=1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 distance=2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 distance=3

סימוני חבילה:

/ip firewall mangle
add chain=output dst-address=10.10.10.100 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp1 passtrough=no
add chain=output dst-address=10.10.10.101 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp2 passtrough=no
add chain=output dst-address=10.10.10.102 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp3 passtrough=no

חוקי NAT ​​פשוטים, אחרת החבילה תעזוב את הממשק עם ה-Src הלא נכון. כתובת:

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade
add chain=srcnat out-interface=ether2 action=masquerade
add chain=srcnat out-interface=ether3 action=masquerade

ניתוח:

• הנתב יוצר שלושה תהליכי SSTP
• בשלב החלטת הניתוב (2) נבחר מסלול לתהליכים אלו על סמך טבלת הניתוב הראשית. מאותו מסלול, החבילה מקבלת את Src. כתובת קשורה לממשק ether1
• В [Output|Mangle] מנות מחיבורים שונים מקבלים תוויות שונות
• מנות נכנסות לטבלאות המתאימות לתוויות בשלב התאמת ניתוב ומקבלות מסלול חדש לשליחת מנות
• אבל לחבילות עדיין יש Src. כתובת מ-ether1, על הבמה [Nat|Srcnat] הכתובת מוחלפת בהתאם לממשק

מעניין שבנתב תראה את טבלת החיבורים הבאה:

Connection Tracker עובד מוקדם יותר [Mangle] и [Srcnat], כך שכל החיבורים מגיעים מאותה כתובת, אם אתה מסתכל יותר בפירוט, אז פנימה Replay Dst. Address יהיו כתובות אחרי NAT:

בשרת ה-VPN (יש לי אחד על ספסל הבדיקה), אתה יכול לראות שכל החיבורים מגיעים מהכתובות הנכונות:

תחזיק מעמד
יש דרך קלה יותר, אתה יכול פשוט לציין שער ספציפי עבור כל אחת מהכתובות:

/ip route
add dst-address=10.10.10.100 gateway=192.168.100.1
add dst-address=10.10.10.101 gateway=192.168.200.1
add dst-address=10.10.10.102 gateway=192.168.0.1

אבל מסלולים כאלה ישפיעו לא רק על התנועה היוצאת אלא גם על התחבורה הציבורית. בנוסף, אם אתה לא צריך תעבורה לשרת ה-vpn כדי לעבור בערוצי תקשורת לא מתאימים, תצטרך להוסיף עוד 6 כללים [IP]->[Routes]с type=blackhole. בגרסה הקודמת - 3 כללים ב [IP]->[Route]->[Rules].

הפצת חיבורי משתמשים לפי ערוצי תקשורת

משימות יומיומיות פשוטות. שוב, יהיה צורך בטבלאות ניתוב נוספות:

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2

שימוש [IP]->[Route]->[Rules]

/ip route rules
add src-address=192.168.100.0/25 action=lookup-only-in-table table=over-isp1
add src-address=192.168.100.128/25 action=lookup-only-in-table table=over-isp2

אם השימוש action=lookup, אז כאשר אחד מהערוצים מושבת, התעבורה תעבור לטבלה הראשית ותעבור בערוץ העבודה. האם זה נחוץ או לא תלוי במשימה.

שימוש בסימונים ב [IP]->[Firewall]->[Mangle]
דוגמה פשוטה עם רשימות של כתובות IP. באופן עקרוני, ניתן להשתמש כמעט בכל תנאי. האזהרה היחידה של שכבה 7, אפילו בשילוב עם תוויות חיבור, אולי נראה שהכל עובד כמו שצריך, אבל חלק מהתנועה עדיין תלך לא נכון.

/ip firewall mangle
add chain=prerouting src-address-list=users-over-isp1 dst-address-type=!local action=mark-routing new-routing-mark=over-isp1
add chain=prerouting src-address-list=users-over-isp2 dst-address-type=!local action=mark-routing new-routing-mark=over-isp2

אתה יכול "לנעול" משתמשים בטבלת ניתוב אחת דרך [IP]->[Route]->[Rules]:

/ip route rules
add routing-mark=over-isp1 action=lookup-only-in-table table=over-isp1
add routing-mark=over-isp2 action=lookup-only-in-table table=over-isp2

או דרך [IP]->[Firewall]->[Filter]:

/ip firewall filter
add chain=forward routing-mark=over-isp1 out-interface=!ether1 action=reject
add chain=forward routing-mark=over-isp2 out-interface=!ether2 action=reject

מקצוען נסיגה dst-address-type=!local
תנאי נוסף dst-address-type=!local יש צורך שתעבורה ממשתמשים תגיע לתהליכים המקומיים של הנתב (dns, winbox, ssh, ...). אם מספר רשתות משנה מקומיות מחוברות לנתב, יש צורך לוודא שהתעבורה ביניהן לא תעבור לאינטרנט, למשל באמצעות dst-address-table.

בדוגמה באמצעות [IP]->[Route]->[Rules] אין חריגים כאלה, אבל התעבורה מגיעה לתהליכים מקומיים. העובדה היא שהכניסה לחבילת FIB מסומנת [PREROUTING|Mangle] בעל תווית מסלול ונכנס לטבלת ניתוב שאינה main, שבה אין ממשק מקומי. במקרה של Routing Rules, תחילה בודקים האם החבילה מיועדת לתהליך מקומי ורק בשלב User PBR היא עוברת לטבלת הניתוב שצוינה.

שימוש [IP]->[Firewall]->[Mangle action=route]
הפעולה הזו עובדת רק ב [Prerouting|Mangle] ומאפשר לך להפנות תעבורה לשער שצוין מבלי להשתמש בטבלאות ניתוב נוספות, על ידי ציון כתובת השער ישירות:

/ip firewall mangle
add chain=prerouting src-address=192.168.100.0/25 action=route gateway=10.10.10.1
add chain=prerouting src-address=192.168.128.0/25 action=route gateway=10.20.20.1

אפקט route יש עדיפות נמוכה יותר מכללי ניתוב ([IP]->[Route]->[Rules]). במקרה של סימני מסלול, הכל תלוי במיקום הכללים, אם הכלל עם action=route שווה יותר מ action=mark-route, אז הוא ישמש (ללא קשר לדגל passtrough), אחרת סימון המסלול.
יש מעט מאוד מידע בוויקי על פעולה זו וכל המסקנות התקבלו בניסוי, בכל מקרה, לא מצאתי אפשרויות כאשר השימוש באפשרות זו נותן יתרונות על פני אחרים.

איזון דינמי מבוסס PPC

Per Connection Classifier - הוא אנלוגי גמיש יותר של ECMP. בניגוד ל-ECMP, הוא מחלק את התעבורה לפי חיבורים בצורה קפדנית יותר (ECMP לא יודע דבר על חיבורים, אבל כאשר משולבים ל-Roting Cache, מתקבל משהו דומה).

PCC לוקח שדות שצוינו מכותרת ה-ip, ממיר אותם לערך של 32 סיביות ומחלק ב מְכַנֶה. שאר החלוקה מושווה עם המפורט היתרה ואם הם תואמים, הפעולה שצוינה תוחל. קרא עוד. נשמע מטורף, אבל זה עובד.

דוגמה עם שלוש כתובות:

192.168.100.10: 192+168+100+10 = 470 % 3 = 2
192.168.100.11: 192+168+100+11 = 471 % 3 = 0
192.168.100.12: 192+168+100+12 = 472 % 3 = 1

דוגמה להפצה דינמית של תעבורה לפי src.address בין שלושה ערוצים:

#Таблица маршрутизации
/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=3 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=1 routing-mark=over-isp3

#Маркировка соединений и маршрутов
/ip firewall mangle
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/0 action=mark-connection new-connection-mark=conn-over-isp1
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/1 action=mark-connection new-connection-mark=conn-over-isp2
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/2 action=mark-connection new-connection-mark=conn-over-isp3

add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp1 action=mark-routing new-routing-mark=over-isp1
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp2 action=mark-routing new-routing-mark=over-isp2
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp3 action=mark-routing new-routing-mark=over-isp3

בסימון מסלולים יש תנאי נוסף: in-interface=br-lan, בלי זה מתחת action=mark-routing תעבורת תגובה מהאינטרנט תקבל ובהתאם לטבלאות הניתוב תחזור לספק.

החלפת ערוצי תקשורת

Check ping הוא כלי טוב, אבל הוא בודק רק את החיבור עם עמית ה-IP הקרוב ביותר, רשתות ספקים מורכבות בדרך כלל ממספר רב של נתבים וניתוק חיבור יכול להתרחש מחוץ לעמית הקרוב, ואז יש מפעילי טלקום עמוד השדרה שעלולים גם יש בעיות, באופן כללי בדיקת פינג לא תמיד מציגה מידע עדכני על גישה לרשת הגלובלית.
אם לספקים ותאגידים גדולים יש את פרוטוקול הניתוב הדינמי BGP, אזי המשתמשים הביתיים והמשרדיים צריכים להבין באופן עצמאי כיצד לבדוק גישה לאינטרנט דרך ערוץ תקשורת ספציפי.

בדרך כלל משתמשים בסקריפטים שבאמצעות ערוץ תקשורת מסוים בודקים את זמינות כתובת ה-IP באינטרנט, תוך בחירת משהו אמין, למשל, google dns: 8.8.8.8. 8.8.4.4. אבל בקהילת מיקרוטיק הותאם לכך כלי מעניין יותר.

כמה מילים על ניתוב רקורסיבי
ניתוב רקורסיבי הכרחי בעת בניית Multihop BGP peering ונכנס למאמר על היסודות של ניתוב סטטי רק עקב משתמשי MikroTik ערמומיים שהבינו כיצד להשתמש במסלולים רקורסיביים בשילוב עם שער בדיקה כדי להחליף ערוצי תקשורת ללא סקריפטים נוספים.

זה הזמן להבין את אפשרויות ההיקף / היעד במונחים כלליים וכיצד המסלול קשור לממשק:

1. המסלול מחפש ממשק כדי לשלוח את החבילה בהתבסס על ערך ה-scope שלה וכל הערכים בטבלה הראשית עם ערכי היקף יעד שווים או פחותים
2. מהממשקים שנמצאו, נבחר זה שדרכו ניתן לשלוח מנה לשער שצוין
3. הממשק של הערך המחובר שנמצא נבחר כדי לשלוח את החבילה לשער

בנוכחות מסלול רקורסיבי, הכל קורה אותו דבר, אבל בשני שלבים:

• 1-3 נוסף נתיב אחד נוסף למסלולים המחוברים, דרכו ניתן להגיע לשער שצוין
• 4-6 מציאת המסלול המחובר לשער "הבינוני".

כל המניפולציות עם החיפוש הרקורסי מתרחשות ב-RIB, ורק התוצאה הסופית מועברת ל-FIB: 0.0.0.0/0 via 10.10.10.1 on ether1.

דוגמה לשימוש בניתוב רקורסיבי כדי להחליף מסלולים

תְצוּרָה:

/ip route
add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1 target-scope=10
add dst-address=8.8.8.8 gateway=10.10.10.1 scope=10
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

אתה יכול לבדוק שהמנות יישלחו לתאריך 10.10.10.1:

Check gateway לא יודע דבר על ניתוב רקורסיבי ופשוט שולח פינגים ל-8.8.8.8, אשר (בהתבסס על הטבלה הראשית) נגיש דרך שער 10.10.10.1.

אם יש אובדן תקשורת בין 10.10.10.1 ל-8.8.8.8, אז המסלול מנותק, אך מנות (כולל פינגי בדיקה) ל-8.8.8.8 ממשיכות לעבור עד 10.10.10.1:

אם הקישור ל-ether1 אבד, אז מתרחש מצב לא נעים כאשר מנות לפני 8.8.8.8 עוברות דרך הספק השני:

זו בעיה אם אתה משתמש ב-NetWatch כדי להפעיל סקריפטים כאשר 8.8.8.8 אינו זמין. אם הקישור נשבר, NetWatch פשוט תעבוד דרך ערוץ התקשורת הגיבוי ותניח שהכל בסדר. נפתרה על ידי הוספת מסלול סינון נוסף:

/ip route
add dst-address=8.8.8.8 gateway=10.20.20.1 distance=100 type=blackhole

יש על habré מאמר, שבו המצב עם NetWatch נחשב ביתר פירוט.

וכן, כשמשתמשים בהזמנה כזו, הכתובת 8.8.8.8 תהיה מחוברת לאחד הספקים, כך שהבחירה בה כמקור dns היא לא רעיון טוב.

כמה מילים על ניתוב והעברה וירטואלית (VRF)

טכנולוגיית VRF נועדה ליצור מספר נתבים וירטואליים בתוך נתב פיזי אחד, טכנולוגיה זו נמצאת בשימוש נרחב על ידי מפעילי טלקום (בדרך כלל בשילוב עם MPLS) כדי לספק שירותי L3VPN ללקוחות עם כתובות משנה חופפות:

אבל VRF במיקרוטיק מאורגן על בסיס טבלאות ניתוב ויש לו מספר חסרונות, למשל, כתובות IP מקומיות של הנתב זמינות מכל ה-VRF, אתה יכול לקרוא עוד по ссылке.

דוגמה לתצורת vrf:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.200.1/24 interface=ether2 network=192.168.200.0

מהמכשיר המחובר ל-ether2, אנו רואים שהפינג עובר לכתובת הנתב מ-vrf אחר (וזו בעיה), בעוד שהפינג לא עובר לאינטרנט:

כדי לגשת לאינטרנט, עליך לרשום מסלול נוסף הניגש לטבלה הראשית (בטרמינולוגיה של vrf, זה נקרא דליפת מסלול):

/ip route
add distance=1 gateway=172.17.0.1@main routing-mark=vrf1
add distance=1 gateway=172.17.0.1%wlan1 routing-mark=vrf2

להלן שתי דרכים לדליפת מסלול: שימוש בטבלת הניתוב: 172.17.0.1@main ושימוש בשם הממשק: 172.17.0.1%wlan1.

והגדר סימון לתנועה חוזרת פנימה [PREROUTING|Mangle]:

/ip firewall mangle
add chain=prerouting in-interface=ether1 action=mark-connection new-connection-mark=from-vrf1 passthrough=no
add chain=prerouting connection-mark=from-vrf1 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf1 passthrough=no 
add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-vrf2 passthrough=no
add chain=prerouting connection-mark=from-vrf2 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf2 passthrough=no 

רשתות משנה עם אותה כתובת
ארגון גישה לרשתות משנה עם אותה כתובת באותו נתב באמצעות VRF ומפת רשת:

תצורה בסיסית:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.100.1/24 interface=ether2 network=192.168.100.0
add address=192.168.0.1/24 interface=ether3 network=192.168.0.0

חוקי חומת האש:

#Маркируем пакеты для отправки в правильную таблицу маршрутизации
/ip firewall mangle
add chain=prerouting dst-address=192.168.101.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf1 passthrough=no
add chain=prerouting dst-address=192.168.102.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf2 passthrough=no

#Средствами netmap заменяем адреса "эфимерных" подсетей на реальные подсети
/ip firewall nat
add chain=dstnat dst-address=192.168.101.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24
add chain=dstnat dst-address=192.168.102.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24

כללי ניתוב לתנועה חוזרת:

#Указание имени интерфейса тоже может считаться route leaking, но по сути тут создается аналог connected маршрута
/ip route
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf1
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf2

הוספת מסלולים שהתקבלו באמצעות dhcp לטבלת ניתוב נתונה
VRF יכול להיות מעניין אם אתה צריך להוסיף אוטומטית מסלול דינמי (למשל מלקוח dhcp) לטבלת ניתוב ספציפית.

הוספת ממשק ל-vrf:

/ip route vrf
add interface=ether1 routing-mark=over-isp1

כללים לשליחת תנועה (יוצאת ומעבר) דרך הטבלה over-isp1:

/ip firewall mangle
add chain=output out-interface=!br-lan action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting in-interface=br-lan dst-address-type=!local action=mark-routing new-routing-mark=over-isp1 passthrough=no

מסלול מזויף נוסף לניתוב יוצא לעבודה:

/interface bridge
add name=bare

/ip route
add dst-address=0.0.0.0/0 gateway=bare

מסלול זה נחוץ רק כדי שמנות יוצאות מקומיות יוכלו לעבור את החלטת הניתוב (2) לפני כן [OUTPUT|Mangle] וקבל את תווית הניתוב, אם יש מסלולים פעילים אחרים בנתב לפני 0.0.0.0/0 בטבלה הראשית, זה לא נדרש.

Цепочки connected-in и dynamic-in в [Routing] -> [Filters]

סינון מסלולים (נכנס ויוצא) הוא כלי שבדרך כלל נעשה בו שימוש בשילוב עם פרוטוקולי ניתוב דינמיים (ולכן זמין רק לאחר התקנת החבילה ניתוב), אבל יש שתי שרשראות מעניינות במסננים הנכנסים:

• מחובר - סינון מסלולים מחוברים
• dynamic-in - סינון מסלולים דינמיים המתקבלים על ידי PPP ו-DCHP

סינון מאפשר לך לא רק לזרוק מסלולים, אלא גם לשנות מספר אפשרויות: מרחק, סימן ניתוב, הערה, היקף, היקף יעד, ...

זה כלי מאוד מדוייק ואם אתה יכול לעשות משהו בלי Routing Filters (אבל לא סקריפטים), אז אל תשתמש ב-Roting Filters, אל תבלבל את עצמך ואת מי שיגדירו את הנתב אחריך. בהקשר של ניתוב דינמי, מסנני ניתוב ישמשו בתדירות גבוהה ובפרודוקטיביות הרבה יותר.

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

#При создании vpn подключений указываем создание default route и задаем дистанцию
/interface pptp-client
add connect-to=X.X.X.X add-default-route=yes default-route-distance=101 ...
add connect-to=Y.Y.Y.Y  add-default-route=yes default-route-distance=100 ...

#Фильтрами отправляем маршруты в определенные таблицы маршрутизации на основе подсети назначения и дистанции
/routing filter
add chain=dynamic-in distance=100 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn1
add chain=dynamic-in distance=101 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn2

אני לא יודע למה, כנראה באג, אבל אם אתה יוצר vrf עבור ממשק ppp, אז המסלול ל-0.0.0.0/0 עדיין יכנס לטבלה הראשית. אחרת, הכל יהיה אפילו יותר קל.

השבתת מסלולים מחוברים
לפעמים זה נדרש:

/route filter
add chain=connected-in prefix=192.168.100.0/24 action=reject

כלי איתור באגים

RouterOS מספק מספר כלים לאיתור באגים בניתוב:

• [Tool]->[Tourch] - מאפשר לך להציג מנות בממשקים
• /ip route check - מאפשר לך לראות לאיזה שער תישלח החבילה, לא עובד עם טבלאות ניתוב
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - פינג ומעקב באמצעות טבלת הניתוב שצוינה
• action=log в [IP]->[Firewall] - כלי מצוין המאפשר לך להתחקות אחר הנתיב של חבילה לאורך זרימת החבילות, פעולה זו זמינה בכל הרשתות והטבלאות

מקור: www.habr.com