מדריך MikroTik IPsec בין שני אתרים

תקציר MikroTik IPsec site-to-site VPN מצפין תעבורה בין שתי רשתות שלמות — משרד ראשי וסניף, מרכז ניטור ואתר תורן — כך שמארחים בכל LAN מגיעים לרשת השנייה כאילו הייתה מקומית. מדריך זה מגדיר את שני הנתבים על RouterOS v7: עמית ה-IKEv2, זהות המפתח המשותף מראש, הצעת שלב 2, מדיניות המנהרה, כלל עקיפת ה-NAT שמכשיל את רוב הניסיונות הראשונים, וכללי חומת האש והבדיקות שמאשרים שהמנהרה פעילה.

מהו MikroTik IPsec site-to-site VPN?

MikroTik IPsec site-to-site VPN הוא מנהרה מוצפנת קבועה בין שני נתבים שמחברת שתי רשתות LAN נפרדות לרשת אחת שניתנת לניתוב בשכבה 3, בלי שאף אחד מהנתבים יחשוף פורט ניהול לאינטרנט הציבורי. בשונה מ-VPN לגישת לקוח כמו WireGuard או OpenVPN — שבו מכשיר ניהול יחיד מתחבר — מנהרה בין שני אתרים פעילה תמיד ופועלת מרשת משנה לרשת משנה: כל מארח מאחורי נתב A יכול להגיע אוטומטית לכל מארח מורשה מאחורי נתב B. IPsec הוא הכלי הנכון כאן מפני שהוא תקן פתוח שנתמך כמעט בכל יצרן חומות אש ונתבים, הוא רץ בליבת RouterOS ומספק תפוקה טובה, וב-MikroTik הוא מובנה בלי חבילה נוספת להתקנה.

המנהרה נבנית בשני משאים ומתנים. שלב 1 (IKE) מאמת את שני הנתבים זה מול זה ומקים ערוץ מאובטח; שלב 2 (IPsec) מנהל משא ומתן על המפתחות שמצפינים בפועל את תעבורת הנתונים שלכם. התאימו את שני השלבים בכל צד והמנהרה תעלה; שנו אלגוריתם אחד בלבד והיא תיכשל בשקט — ולכן השלבים שלהלן שומרים על סימטריה בין שני הצדדים.

לפני שמתחילים

דרושים שני נתבי MikroTik עם RouterOS v7, לכל אחד כתובת IP ציבורית או שם מארח DDNS פעיל, ושתי רשתות משנה LAN שאינן חופפות. מדריך זה משתמש ב-192.168.10.0/24 באתר A וב-192.168.20.0/24 באתר B. אם שני האתרים משתמשים ב-192.168.88.0/24, ניתוב בלתי אפשרי — שנו כתובות בצד אחד קודם. מכיוון ש-IPsec רגיש מאוד לסטיית שעון, הפעילו NTP בשני הנתבים לפני שמתחילים; אם שני הקצוות מתרחקים זה מזה בזמן, שיוכי האבטחה פגים והמנהרה ממשיכה ליפול.

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

שלב 1: יצירת פרופיל IKE ועמית

באתר A, הגדירו את פרופיל שלב 1 והפנו עמית לכתובת הציבורית של אתר B:

/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \
    enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d

/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \
    profile=to-siteB exchange-mode=ike2

dh-group=modp2048 הוא Diffie-Hellman Group 14 — ברירת מחדל מודרנית ותקינה. exchange-mode=ike2 בוחר ב-IKEv2, שמהיר ועמיד יותר ממצב main/IKEv1 הישן. שני הקצוות חייבים להשתמש באותם ערכי פרופיל ובאותו מצב חילופין.

שלב 2: הוספת הזהות (מפתח משותף מראש)

/ip ipsec identity add peer=siteB auth-method=pre-shared-key \
    secret="<long-random-shared-secret>"

השתמשו בסוד ארוך ואקראי ואחסנו אותו כפי שהייתם מאחסנים מפתח SSH — לא בהודעת צ’אט. אותו סוד עולה על שני הנתבים.

שלב 3: הגדרת הצעת שלב 2

/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \
    enc-algorithms=aes-256-cbc pfs-group=modp2048

Perfect Forward Secrecy (pfs-group) פירושה שכל החלפת מפתחות משתמשת בחומר מפתח טרי, כך שמפתח שנפרץ לעולם לא חושף תעבורה מהעבר. כמו בשלב 1, האלגוריתמים חייבים להתאים בשני הקצוות.

שלב 4: יצירת מדיניות המנהרה

המדיניות אומרת ל-RouterOS איזו תעבורה להצפין — מה-LAN המקומי אל ה-LAN המרוחק:

/ip ipsec policy add peer=siteB tunnel=yes \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    proposal=to-siteB action=encrypt

tunnel=yes הוא מה שהופך את זה לחיבור בין אתרים ולא בין מארחים: המנות המקוריות נעטפות בשלמותן, כך ששתי רשתות ה-LAN מדברות בשקיפות.

שלב 5: הוספת כלל עקיפת NAT (השלב שכולם שוכחים)

כאן נשברים רוב הניסיונות הראשונים. לנתב שלכם כבר יש כלל masquerade שמשכתב את כתובת המקור של תעבורת LAN יוצאת. אם הוא פועל לפני IPsec, הקצה המרוחק מקבל מנות שכתובת המקור שלהן כבר לא תואמת את המדיניות ומשליך אותן. הוסיפו כלל accept מעל ה-masquerade כדי שתעבורה שמיועדת למנהרה תדלג על NAT:

/ip firewall nat add chain=srcnat action=accept place-before=0 \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24

place-before=0 ממקם את הכלל ממש בראש שרשרת srcnat, וזה הכרחי — כלל עקיפה שממוקם אחרי masquerade אינו עושה דבר.

שלב 6: פתיחת חומת האש ואימות

אפשרו את פורטי ה-IKE וה-NAT-T ואת פרוטוקול ה-ESP בשרשרת input כדי שהמנהרה תוכל להיווצר, במיוחד אם אחד האתרים יושב מאחורי התקן NAT נוסף:

/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept
/ip firewall filter add chain=input protocol=ipsec-esp action=accept

ואז ודאו שהמנהרה עלתה:

/ip ipsec active-peers print
/ip ipsec policy print

מנהרה תקינה מציגה עמית פעיל ומדיניות שבה ph2-state מציג established. פינג מהיר ממארח ב-LAN אחד למארח בשני מוכיח קישוריות מקצה לקצה.

שכפול התצורה לאתר B

חזרו על כל שלב באתר B עם כתובות הפוכות: העמית מצביע על ה-IP הציבורי של אתר A, והמדיניות וכלל עקיפת ה-NAT משתמשים ב-src-address=192.168.20.0/24 וב-dst-address=192.168.10.0/24. הפרופיל, ההצעה, סוד הזהות ומצב IKEv2 נשארים זהים. כששני הצדדים תואמים, שלב 1 ושלב 2 מסתיימים והמנהרה עולה.

טיפים לאבטחה ולתפעול

שמרו על RouterOS מעודכן — גרסאות אחרונות כללו תיקונים שנוגעים להתאמת אישורי עמית ב-IPsec/IKEv2, ולכן מנהרה שעבדה ברבעון שעבר ראויה לבדיקה חוזרת אחרי כל שדרוג. העדיפו IKEv2 עם PFS על פני ברירות המחדל הישנות של IKEv1. במידת האפשר, עברו ממפתח משותף לאימות מבוסס אישורים ככל שמספר המנהרות גדל, כי מפתח משותף אחד שדלף משפיע על כל אתר שחולק אותו. ותעדו את מצב המנהרה במקום שאתם באמת עוקבים אחריו: קישור בין אתרים שמת נשאר בלתי נראה עד שמישהו מנסה להגיע ל-LAN המרוחק ולא מצליח.

בצי, מנהרת IPsec שנופלת בשקט אחרי סטיית שעון או תנודה ב-WAN היא בדיוק סוג התקלה שהלקוח מבחין בה לפניכם. MKController סוגר את הפער: הוא מנטר כל נתב דרך מנהרה יוצאת מאובטחת שאינה דורשת IP ציבורי ולא העברת פורטים במכשיר, שומר גיבויי תצורה מגורסאים כדי שתוכלו להשוות ולשחזר בלוק IPsec תקין אחרי עריכה שגויה, ויכול לפתוח קריאה באירוע נפילת קישור לפני שהטלפון מצלצל. לגבי תצורת המנהרה עצמה, המדריך שלנו על NAT ב-MikroTik מסביר את כלל ה-masquerade שאתם עוקפים כאן, ולגישה לנתב יחיד במקום חיבור שתי רשתות LAN, ראו ניהול מרחוק מאחורי CGNAT ואת המדריך שלנו על ניהול מרחוק עם WireGuard.

רכזו את המנהרות תחת קורת גג אחת

IPsec מחבר שני אתרים בצורה נקייה, אבל ספק אינטרנט או MSP שגדל מוצא את עצמו עד מהרה עם עשרות מנהרות, מפתחות וכללי חומת אש שצריך לסנכרן — וכל עריכה ידנית היא הזדמנות לנעול את עצמכם מחוץ לאתר מרוחק. MKController נבנה בדיוק לקנה מידה הזה: ניהול צי מרוכז, גישה מרוחקת מאובטחת בלי פורטים חשופים, היסטוריית תצורה וגיבויים, ודחיפה של שינויי חומת אש ומדיניות לכל הצי, כך שתבנית מנהרה מופצת פעם אחת במקום להיכתב מחדש נתב אחר נתב. מפעילים שמריצים MikroTik בקנה מידה משתמשים בו כדי להפוך צהריים אבודים של SSH לכל מכשיר לכמה קליקים לכל שינוי.

התחילו תקופת ניסיון חינם ב-MKController