הוספת תת-רשת שנייה ל-VPN בין אתרים: שני מסלולים
מנהרות מבוססות מדיניות דורשות בוררים תואמים בשני הצדדים; מבוססות מסלול דורשות מסלול. בחרו במסלול הנכון ותקנו קודם את מסלול החזרה.
הוספת תת-רשת שנייה למנהרה פעילה בין אתרים אורכת חמש דקות בתכנון אחד וכמעט את כל אחר הצהריים בשני. כשהמנהרה מתקינה מסלולים לקידומות שאתם נוקבים בשמן, אתם מוסיפים מסלול והתעבורה עוקבת אחריו. כשהיא מנהלת משא ומתן על זוג בוררים קבוע, הקידומת החדשה נשארת לא מוגנת עד ששני הצדדים מסכימים על זוג תואם. שלושה דברים מכריעים: מה התצורה של כל צד באמת מתארת, אם התעבורה שנדונה מצטמצמת לזוג התואם הקטן, ומי הבעלים של מסלול החזרה לטווח החדש.
קראו את הגרעין, לא את תווית המצב
מנהרה שמדווחת על חיבור התקינה לפחות אסוציאציית בת אחת, אבל לא בהכרח את זו שאתם חושבים. בלינוקס הגרעין מראה מה מיושם: ip xfrm policy מפרט את זוגות הבוררים ו-swanctl --list-sas (או ipsec statusall הישן) מראה מה הצדדים ניהלו משא ומתן, כולל בוררי התעבורה בכל כיוון. אם הקידומת החדשה לא מופיעה באף אחד מהם, היא לא מוגנת, יאמר קובץ התצורה מה שיאמר.
השוו לכך את טבלת המסלולים. בתכנון מבוסס מסלול, התקן המנהרה הוא הקפיצה הבאה עבור הקידומות המוגנות. בתכנון מבוסס מדיניות אין לעיתים קרובות מסלול ספציפי לתת-הרשת המרוחקת, רק מסלול ברירת המחדל, כי המדיניות בוחרת את התעבורה ולא הטבלה.
מנהרות מבוססות מדיניות: שני הצדדים חייבים לפרט את הקידומת החדשה
במונחי strongSwan הבורר יושב ב-local_ts וב-remote_ts תחת תצורת הבת, ממשיכי leftsubnet ו-rightsubnet. הקידומת החדשה חייבת להופיע בשני הצדדים באופן מראה: מה שאתר A מכנה מקומי, אתר B מכנה מרוחק. אי-התאמה כמעט ולא מפיקה שגיאה נקייה. הצדדים מצטמצמים לחתך, הקידומת הישנה ממשיכה לעבוד ורק החדשה נכשלת בשקט.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyב-pfSense או OPNsense זה אומר רשומת Phase 2 שנייה שמזווגת את תת-הרשת המקומית החדשה לרשת המרוחקת החדשה, ואז החלה. שמרו על הרשומה הישנה; החלפה מעבירה את תת-הרשת המקורית במקום להוסיף. אם Phase 2 קיימת כבר מכסה רשת-על כמו 0.0.0.0/0 או טווח מסוכם, אל תוסיפו רשומה צרה יותר לצידה: בוררים חופפים מתקינים מדיניות מתחרה וסדר ההערכה מכריע מי מנצח.
IKEv1 הופך כל זוג תת-רשתות ל-Phase 2 משלו, וצד שמקבל זוג אחד לכל החלפה מפיל את השאר. IKEv2 יכול לשאת כמה זוגות בוררים בבת אחת, אבל רק אם שתי המימושים מקבלים אותם. הרשימה מ-swanctl --list-sas היא האמת; מה שהקלדתם הוא בקשה.
מנהרות מבוססות מסלול: המסלול הוא המדיניות
ממשק XFRM או התקן VTI נושא תעבורה לפי טבלת המסלולים. אתם מפנים את הקידומת החדשה אל ההתקן בשני האתרים, והמצב הקשור לטרנספורמציה של הממשק חל. אין זוג בוררים לסנכרן, ולכן התכנון הזה משתרע טוב יותר כשתת-הרשתות מתרבות. מדריך ההעברה של strongSwan מפרט את צד הגרעין.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard מרחיק את הרעיון. AllowedIPs הוא גם רשימת ההיתר הקריפטוגרפית וגם, דרך wg-quick, הרשומה בטבלת המסלולים. הוסיפו את הקידומת בצד אחד בלבד ותקבלו לחיצת יד, מנות יוצאות ודממה, כי הצד המרוחק מפיל מנות שמקורן אינו ברשימתו. הצורה wg set מחליפה את כל הרשימה, לכן חזרו על הקידומות שעבדו או שתנתקו אותן:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0הפקודה השנייה אינה רשות כשהשתמשתם ב-wg set במקום ב-wg-quick. הגרעין מקבל את רשימת ההיתר מיד, אבל דבר אינו מוסיף לה מסלול, ולכן תעבורה שנוצרת מקומית עדיין יוצאת דרך שער ברירת המחדל. זו הסיבה הנפוצה ביותר שתת-רשת WireGuard חדשה עובדת ממארח המנהרה ולא ממחשב נייד.
מסלול החזרה נכשל לעיתים קרובות יותר מהמנהרה
מארחים בתת-הרשת המרוחקת החדשה חייבים לשלוח תשובות בחזרה דרך שער ה-VPN. כאשר השער הזה אינו הנתב הראשי שלהם, התשובה הולכת לנתב ה-LAN, שמושך אותה או מעביר אותה לאינטרנט עם כתובת מקור פרטית. בדקו ממארח בצד המרוחק ולא מהשער: ip route get 10.30.20.15 בלינוקס או Find-NetRoute -RemoteIPAddress 10.30.20.15 ב-PowerShell מראה את הקפיצה הבאה שהמארח באמת ישתמש בה. אם התשובה אינה נקודת הקצה של המנהרה, הוסיפו שם מסלול סטטי לקידומת החדשה.
NAT מקור באתר שחסר לו מסלול חזרה הוא חלופה לגיטימית והדרך שבה פריסות hub-and-spoke רבות נמנעות מנגיעה בכל שרת. החילו אותו גם על הקידומת החדשה בשער בצד היעד:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEהמחיר אמיתי. יומנים מרוחקים מפסיקים להציג כתובות מקור בודדות, וכללי חומת אש המבוססים על תת-הרשת המקורית מתמזגים לכלל אחד עבור השער. בחרו בכך במכוון, לא משום שחסר מסלול.
חומות אש הן החצי השני של מסלול החזרה. התקנים מבוססי אזורים אינם מרחיבים אוטומטית אזור של ממשק מנהרה קיים לתת-רשת חדשה, וכלל שנכתב לקידומת הישנה לא יתאים. הוסיפו את תת-הרשת החדשה לאזור או לזוג הכללים בשני הכיוונים לפני שתאשימו את IPsec.
החליטו בשלוש שאלות ואז אמתו בתעבורה
הגרסה הקצרה: האם תצורת הצד מפרטת קידומות (מבוסס מדיניות), או שהתעבורה מנותבת לממשק (מבוסס מסלול)? האם שני הקצוות מפרטים את הקידומת החדשה? האם יש דרך חזרה מתת-הרשת החדשה לטווח המקור המקורי?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
האימות הוא המקום שבו רוב השינויים נסגרים מוקדם מדי. פינג מהשער מוכיח מעט, כי השער שולח מעצמו ולעיתים קרובות מתאים למדיניות אחרת מזו של מארח. עשו פינג ממארח בתת-הרשת החדשה, הריצו את היישום שהניע את השינוי והביטו במונים ולא בסמל מצב.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showבמנהרה מבוססת מדיניות מוני ip xfrm state אמורים לעלות בשני הכיוונים; מונים שטוחים אומרים שהמנה מנותבת אך אינה נבחרת. ב-WireGuard wg show מדווח על העברה לכל צד, ולחיצת יד עם אפס בתים שהתקבלו מצביעה על רשימת הצד המרוחק או על מסלול החזרה שלו.
סיימו בתיעוד הקידומת, הבורר או המסלול של הצד, ההחלטה על מסלול החזרה ורשומת חומת האש עם שאר מלאי המנהרה. אחר כך הפעילו מחדש שער אחד ובדקו שוב: מסלול שהוסף ביד נעלם, והאדם הבא לא אמור לגלות זאת מחדש.