PBR ב-Check Point Gaia: איך שולחים תעבורה ספציפית ל-ISP אחר — מדריך מלא בעברית (כולל Application-Based Routing ל-Office365)

בפעם הראשונה שנתקלתי ב-PBR באמת, השעה הייתה 23:40 ואני ישבתי אצל לקוח עם שני קווי אינטרנט. הקו הראשי היה עמוס, וההנהלה התלוננה שה-Teams מקרטע. הפתרון שנשמע הגיוני במבט ראשון — להעביר את כל התעבורה לקו השני — לא היה מתאים: הקו השני היה זול ואיטי, וטוב לגלישה בלבד. מה שנדרש בפועל היה כלל אחד ומדויק: "רק תעבורת Office365 תצא דרך הקו השני". בדיוק בשביל כללים כאלה קיים Policy-Based Routing.

המדריך הזה מבוסס על התיעוד הרשמי של Check Point בנושא Policy-Based Routing ו-Application-Based Routing ב-Gaia (גרסאות R81, R81.10, R81.20, R82 ו-R82.10), אבל כתוב כמו שאנחנו מסבירים אותו בכיתה במכללת נטמי: דוגמה אחת שמלווה אתכם מההתחלה ועד הסוף, בלי להיטבע בפרמטרים מיותרים.

מה זה PBR, ולמה טבלת הניתוב הרגילה לא מספיקה

ניתוב קלאסי מתבסס על נתון אחד בלבד: כתובת היעד. הוא אינו מתחשב בזהות השולח, בפורט או בממשק שדרכו נכנס הפאקט. Policy-Based Routing מסיר את המגבלה הזו ומאפשר ל-Gaia להחליט לאן להעביר את התעבורה גם לפי קריטריונים נוספים:

• ▸ממשק הכניסה (Inbound Interface) שדרכו הגיע הפאקט
• ▸כתובת מקור + Subnet Mask (מתחנה בודדת ועד רשת שלמה)
• ▸כתובת יעד + Subnet Mask
• ▸פורט יעד (למשל 443 ל-HTTPS, 22 ל-SSH)
• ▸מספר פרוטוקול (TCP=6, UDP=17, ICMP=1)
• ▸מספר חוק Firewall — הבסיס ל-Application-Based Routing מ-R80.40

PBR נבדק לפני הניתוב הרגיל. פאקט שתואם לחוק PBR ינותב לפי טבלת הפעולה (Action Table) שהוגדרה בחוק. פאקט שאינו תואם לאף חוק ימשיך לפי טבלת הניתוב הראשית (Main Routing Table).

בכל חוק אפשר לבחור גם פעולה שאינה ניתוב: Prohibit (החזרת הודעת Prohibit לשולח), Unreachable (החזרת הודעת Unreachable), או Table — ניתוב לפי Action Table. החוקים נבדקים לפי סדר עדיפות (Priority), בזה אחר זה, עד להתאמה הראשונה.

מי שלמד CCNA ודאי מזהה את העיקרון: זהו בדיוק אותו רעיון של Policy-Based Routing בנתבי Cisco, שמיושם באמצעות route-map ו-set ip next-hop. אותו קונספט, ממשק ניהול שונה. זו הסיבה שאנחנו מלמדים את שני העולמות — מי שמבין ניתוב לעומק, לומד פיירוול מהר בהרבה.

הטופולוגיה של המעבדה

הדוגמה כולה בנויה על תרחיש אמיתי ופשוט: רשת פנימית אחת ושני ספקי אינטרנט. ברירת המחדל יוצאת דרך ISP2, ותעבורת HTTPS מסוימת מנותבת דרך ISP1.

לחצו להגדלה

• ▸רשת פנימית: 55.226.23.0/24 — ממשק eth2 בכתובת 55.226.23.44
• ▸ISP2 (ברירת מחדל): ממשק eth0 בכתובת 205.226.23.44, Next Hop 205.226.23.1
• ▸ISP1 (יעד ה-PBR): ממשק eth1 בכתובת 105.226.23.44, Next Hop 105.226.23.1
• ▸המטרה: כל התעבורה יוצאת ב-ISP2, למעט HTTPS (TCP/443) שתצא ב-ISP1

לחצו להגדלה

לפני שניגשים ל-PBR יש לוודא שלושה תנאים מקדימים: השער מוגדר במלואו בכל ה-Blades הרלוונטיים, המדיניות הותקנה עליו, והניתוב הבסיסי פועל כשורה. PBR הוא שכבה שנשענת על ניתוב תקין, ואינו תחליף לניתוב שגוי. בסביבת קלאסטר ההגדרות חייבות להיות זהות בכל ה-Members (התכונה נתמכת ב-ClusterXL HA, ב-Load Sharing מסוג Unicast ו-Multicast וב-VRRP).

שלב 1 — Action Table: לאן שולחים

ב-Gaia Portal עוברים למצב Advanced ונכנסים אל Advanced Routing → Policy Based Routing. בקטע Action Tables לוחצים Add ויוצרים טבלה בשם ISP1: מסמנים Default Route, בוחרים Next Hop Type מסוג Normal (קבלה והעברה של התעבורה — לעומת Reject שמחזיר Unreachable, ו-Black Hole שמשליך את הפאקט ללא הודעה), ומוסיפים Gateway בכתובת 105.226.23.1 עם Priority 1 (הטווח האפשרי הוא 1–8).

לחצו להגדלה

שלב 2 — Policy Rule: מי נכנס לטבלה

בקטע Policy Rules לוחצים Add ומגדירים: Priority 1, Action → Table: ISP1, ובאזור ה-Match מסמנים Interface: eth2, Service Port: HTTPS ‏(443) ו-Protocol: TCP ‏(6). כלל חשוב: יש לסמן לפחות אחד משלושת הקריטריונים — Interface, Source או Destination — כדי שההתאמה תהיה חד-משמעית לכיוון אחד בלבד (לקוח→שרת או שרת→לקוח) ולא לשני הכיוונים יחד.

לחצו להגדלה

אותו דבר ב-Clish — למי שאוהב שורת פקודה

lock database override

# Action Table
set pbr table ISP1 static-route default nexthop gateway address 105.226.23.1 on

# Policy Rule
set pbr rule priority 1 match interface eth2
set pbr rule priority 1 match port 443
set pbr rule priority 1 match protocol tcp
set pbr rule priority 1 action table ISP1

save config
show pbr summary

NETME-GW44> show pbr summary
PBR Summary
    PBR has 1 table
        PBR table ISP1 (ID=1) has 1 route
            Default route, nexthop gateway
                gateway 105.226.23.1
                        preference 1
    PBR has 1 rule
        PBR rule 1 interface eth2 port 443 protocol TCP (6) table 1

שלב 3 — אימות שההגדרה אכן עובדת בפועל

זהו השלב שסטודנטים נוטים לדלג עליו, והוא בדיוק ההבדל בין מי שמגדיר לבין מי שמבין. שלוש פקודות ב-Expert Mode נותנות תמונה מלאה:

[Expert@NETME-GW44]# ip rule
0:      from all lookup local
1:      from all fwmark 0x1bb20/0xfffff0 iif eth2 lookup 1
32766:  from all lookup main
32767:  from all lookup default

[Expert@NETME-GW44]# ip route show table 1
default via 105.226.23.1 dev eth1 proto 7

[Expert@NETME-GW44]# ip route
default via 205.226.23.1 dev eth0 proto 7
55.226.23.0/24  dev eth2 proto kernel scope link src 55.226.23.44
105.226.23.0/24 dev eth1 proto kernel scope link src 105.226.23.44
205.226.23.0/24 dev eth0 proto kernel scope link src 205.226.23.44

# R80.40 ומעלה
fw monitor -F "55.226.23.44,0,0.0.0.0,443,0"

[vs_0][fw_0] eth2:i[52]: 55.226.23.44 -> 40.97.164.146 (TCP) len=52
[vs_0][fw_0] eth2:I[52]: 55.226.23.44 -> 40.97.164.146 (TCP) len=52
[vs_0][fw_0] eth1:o[52]: 55.226.23.44 -> 40.97.164.146 (TCP) len=52
[vs_0][fw_0] eth1:O[52]: 55.226.23.44 -> 40.97.164.146 (TCP) len=52

Application-Based Routing — ניתוב לפי אפליקציה ולא לפי כתובת IP

כאן מתחיל החלק המעניין באמת. החל מגרסה R80.40, מנגנון ה-PBR יודע לעבוד יחד עם ה-Access Control Policy, כלומר להתאים תעבורה לפי חוק Firewall שלם. כך אפשר לנתב לפי אפליקציה, שירות, משתמשים, שעה ומיקום. יכולת זו נקראת Application-Based Routing, והיא הפתרון האמיתי לבעיה שבה פתחנו: כיצד לשלוח רק את תעבורת Office365 לקו הנפרד, בלי לתחזק ידנית רשימות IP שמיקרוסופט מעדכנת מדי שבוע (למטרה זו קיימים Updatable Objects).

התכונה מוסתרת כברירת מחדל. מפעילים אותה ב-Expert Mode ולאחר מכן מאתחלים את השער:

dbset process:rtgpbrd:runlevel 4
dbset process:rtgpbrd:path /bin
dbset process:rtgpbrd t
dbset :save
reboot

ב-SmartConsole יוצרים חוק Access Control ששמו מתחיל בקידומת "_PBR" — רק חוקים בעלי קידומת זו יופיעו ברשימה בשער. בשדה היעד בוחרים Updatable Object כגון Office365 Worldwide Services, בשירותים בוחרים http ו-https, ולבסוף מתקינים את המדיניות.

לחצו להגדלה

• ▸חוקי PBR_ חייבים להיות ממוקמים מעל חוקים רחבים מסוג any-any, אחרת ההתאמה תתבצע מול החוק הרחב והניתוב הייעודי יאבד
• ▸החוק חייב להיות ייחודי וניתן להכרעה כבר בפאקט הראשון של החיבור, אחרת הפאקטים הראשונים ייצאו דרך הקו השגוי
• ▸חוק ABR אינו יכול לכלול Inner Layer
• ▸גם ב-ABR חובה לסמן Interface, Source או Destination — חוק Firewall כשלעצמו אינו קריטריון מספיק

set pbr rule priority 1 match interface eth2
set pbr rule priority 1 match fwrule 1
set pbr rule priority 1 action table ISP1
save config

# האם המדיניות אכן כתבה את חוקי ה-PBR לשער?
cat /tmp/fwpbrrules.conf
1 63c094b7-d27a-4a72-bf73-a0d74bbb8554 "PBR_NETME_ToOffice365"

# האם התהליך האחראי פועל?
ps aux | grep rtgpbrd

# מה שמור במסד הנתונים של Gaia?
dbget -arv fwrules

מגבלות שחשוב להכיר לפני שמתחייבים ללקוח

• ▸בקלאסטר, תצורת ה-PBR חייבת להיות זהה בכל ה-Members; אחרת לאחר Failover התעבורה תצא דרך קו אחר
• ▸ב-VSX מגרסה R80.40: ב-Virtual System ניתן להתאים לפי Source, Destination, Interface, Port ו-Protocol, ואילו ב-Virtual Router רק לפי Source, Destination ו-Interface
• ▸בגרסה R80.30 ומטה, PBR נתמך ב-Virtual Router בלבד ולא ב-Virtual System
• ▸יכולת ה-ABR נבדקה בהרחבה מול Office365, Amazon ו-Zoom; עבור שירותים אחרים מומלץ לאמת במעבדה לפני הטמעה בפרודקשן
• ▸PBR אינו תחליף לניטור קו: אם ה-Next Hop נופל, מומלץ לשלב Monitored IPs כדי שהטבלה לא תישאר מכוונת לקו שאינו פעיל

השורה התחתונה

PBR הוא אחד הכלים שמבחינים בין מי שיודע ללחוץ Install Policy לבין מי שמבין לעומק כיצד התעבורה זורמת בארגון. הוא נוגע בו-זמנית בניתוב, בפיירוול ובקרנל של Gaia — ומסיבה זו הוא נושא נפוץ בראיונות עבודה.

בקורס Check Point של מכללת נטמי תגדירו את התרחיש הזה בעצמכם על מעבדה חיה: שני ספקי אינטרנט, Action Table, Policy Rule, אימות באמצעות fw monitor ו-ip rule, ולבסוף ABR עם Updatable Objects. אם נושא הניתוב עדיין אינו ברור דיו, קורס CCNA הוא נקודת הפתיחה הנכונה: אותו PBR קיים גם בנתבי Cisco (route-map יחד עם set ip next-hop), ומי שמבין אותו שם — מבין אותו בכל פלטפורמה.