האצלת קידומת IPv6 דרך VPN מאתר לאתר: רשימת בדיקה
בדיקות לניתוב קידומת IPv6 מואצלת דרך VPN מאתר לאתר: מפת קידומות, בוררי תעבורה, העברה, MTU, נתיב חזרה ומספור מחדש.
הרמת המנהרה היא החצי הקל. ראיתי קישור מאתר לאתר נשאר פעיל ימים שלמים בעוד כל מארח ב-LAN המרוחק קיבל חזרה רק שקט, מפני שהקידומת המואצלת מאחורי אותו שער הוגדרה על ממשק אך מעולם לא נותבה אל תוך המנהרה. כתובות המנהרה ענו לפינג כל אותו זמן, ובדיוק משום כך איש לא הביט בקידומת. זהו הסדר שאני בודק כאשר קידומת IPv6 מואצלת צריכה לחצות VPN אתרי: מפת הקידומות, בוררי התעבורה, ההעברה וחומת האש, ואחר כך נתיב החזרה.
כתבו את מפת הקידומות לפני שנוגעים במנהרה
האצלת קידומת מוסרת בלוק לנתב שביקש אותו. היא אינה מתקינה מסלול אצל העמית, אינה מרחיבה את הבלוק על הקישור ואינה מספרת לשער המרוחק מה נמצא מאחורי הנתב המבקש. שלושת הדברים האלה באחריותכם, ומקומם בתכנית כתובות לפני שכל קובץ תצורה משתנה.
לכל אתר, רשמו את הקידומת המואצלת, את ה-/64 שבשימוש בפועל ב-LAN, את כתובות המנהרה ואת הבעלים של כל מסלול. הספק מאציל 2001:db8:a1::/56 לאתר A, שמשרת 2001:db8:a1:10::/64 ב-LAN שלו; אתר B שומר על 2001:db8:b2::/64. אם אתר A משרת רק את אותה /64, שני הקצוות צריכים לנקוב ב-2001:db8:a1:10::/64 ולא בכל ה-/56.
שתי טעויות מופיעות כמעט בכל פעם. האחת היא להתייחס לקידומת המרוחקת כאל נמצאת על הקישור, לגשר אותה או להניח אותה על ממשק המנהרה כך שהשער עונה לבקשת שכן עבור מארחים שאינו יכול להגיע אליהם. האחרת היא לפרסם את כל ה-/56 כאשר רק /64 אחת מוגדרת: טבלת המסלולים טוענת שהבלוק נגיש ורוב הכתובות נופלות לחור שחור.
התאימו את בוררי התעבורה של שני הקצוות למסלולים
IKEv2 ו-WireGuard שניהם מסרבים לתעבורה לא תואמת, בשקט שמספיק כדי שהמנהרה עוד תיראה תקינה.
ב-strongSwan הבוררים מפורשים. באתר A:
conn a-to-b
left=2001:db8:ff::1
leftsubnet=2001:db8:a1:10::/64
right=2001:db8:ff::2
rightsubnet=2001:db8:b2::/64
auto=startה-conn של אתר B משקף את שתי תת-הרשתות. כאשר הן אינן תואמות, המגיב דוחה את ה-CHILD_SA עם TS_UNACCEPTABLE, כך שה-SA הבן לעולם לא עולה אף שה-IKE_SA עלה. בשני הצדדים תת-הרשת המוגדרת חייבת להיות שווה למה שהליבה המקומית מנתבת אל המנהרה.
WireGuard נושא את אותו מידע ב-AllowedIPs, עם תפנית אחת: AllowedIPs הוא מסנן מקור בקליטה וגם מסלול בשליחה. אם רשומת העמית של אתר B עבור אתר A משמיטה את 2001:db8:a1:10::/64, חבילות מאתר A מגיעות על לחיצת יד תקפה ומושלכות כלא מורשות. זה יוצר את התבנית המוכרת של לחיצת יד שמתחדשת ללא הרף בעוד שום תשובה לא יוצאת. השוו את שני הקצוות עם wg show wg0 allowed-ips. בדקו שוב את הרשימה בכל שינוי של ההאצלה; /64 מיושנת משאירה את הסשן למעלה ואת הקידומת החדשה בלתי נגישה.
שללו קודם העברה, חומת אש ו-MTU
לפני שתקראו עוד שורת יומן, ודאו שהשערים מעבירים בכלל. sysctl net.ipv6.conf.all.forwarding חייב להחזיר 1 בשניהם, ומיושם גם על ממשקי המנהרה וה-LAN. מלכודת אחת מגיעה יחד עם זה: ברגע שההעברה פעילה, ממשק עם accept_ra=1 מפסיק לקבל הודעות נתב מהספק, כך שהמכונה עלולה לאבד את מסלול ברירת המחדל כלפי מעלה בעוד היא מנתבת היטב בתוך המנהרה. הגדירו accept_ra=2 במקום שבו עדיין נדרשת RA מהספק.
לאחר מכן כללי חומת האש חייבים להתיר את הקידומת בשני הכיוונים, ו-ICMPv6 חייב לשרוד: גילוי שכנים, חבילה-גדולה-מדי ויעד-בלתי-נגיש אינם אופציונליים. השליכו אותם וגילוי ה-MTU של הנתיב נשבר, וכך תקבלו חיבורים שנפתחים ואז נתקעים בתגובה הגדולה הראשונה. זוג כללים מינימלי נראה כך:
nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } acceptה-MTU נמצא מאחורי זה. מנהרה מקטינה את ה-MTU השמיש מתחת ל-1500, ו-IPv6 דורש שכל קישור יישא לפחות 1280. פינגים קטנים עוברים, סשן SSH קופא בהתפרצות גדולה, ו-/proc/net/snmp6 מציג הודעות חבילה-גדולה-מדי שלעולם אינן חוזרות. הגדירו את MTU המנהרה במפורש, או הגבילו TCP MSS בטבלת mangle, ותנו ל-ICMPv6 שמדווח על ה-MTU הקטן יותר לחזור.
בדקו את נתיב החזרה, לא את כתובת המנהרה
הכשל שגובה את מרב הזמן הוא ניתוב חד-כיווני. כל שער מנתב את הקידומת המרוחקת אל המנהרה, אבל המארחים עונים דרך שער ברירת המחדל שלהם מפני ששם יושבת ה-/64 שלהם. הבאת חבילה ליעד היא רק חצי דרך.
| What you see | Likely cause | First check |
|---|---|---|
| Tunnel up, every host silent | remote prefix not routed into the tunnel | ip -6 route get on both gateways |
| Handshake renews, no replies | source prefix missing from selectors or AllowedIPs | ipsec statusall, wg show allowed-ips |
| Small pings pass, transfers stall | MTU or ICMPv6 packet-too-big filtered | /proc/net/snmp6 counters |
| Old prefix still works | stale /64 left in routes or selectors | delegation lease and route table |
שתי פקודות מכריעות את רוב זה. באתר A, ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 מראה באיזה ממשק תשתמש תשובה מאותו מקור; בצעו את בדיקת המראה באתר B. אחר כך צרו תעבורה ממארח ולא מהשער והשוו מונים בשני הקצוות.
אם בקשת שכן עבור הקידומת המרוחקת מופיעה במנהרה, אותה קידומת נמצאת על הקישור במקום שבו היא לא אמורה להיות; תקנו זאת לפני שתכווננו מסלולים. Proxy NDP מכסה מקרים שבהם גישור באמת נדרש, ואינו תחליף למסלול.
תכננו לקידומת שמשתנה מתחתיכם
האצלת קידומת היא חכירה בין הנתב המאציל לנתב המבקש, וחידוש עשוי להחזיר בלוק אחר: /56 אחר לאחר הגירת ספק, או חכירה קצרה מהזמן שהמנהרה פעילה. כל מקום שמנקוב בקידומת הישנה מתיישן בבת אחת: מסלולים, בוררים, AllowedIPs, כללי חומת אש, רשומות DNS וכל ניטור שמקודד כתובות מילוליות בקשיחות. זרימת ההודעות נמצאת ב-RFC 8415.
במקום שבו צפויה הקידומת לזוז, החזיקו תכנית כתובות פנימית שאינה תלויה בה ותרגמו בגבול. NPTv6 היא האפשרות חסרת המצב והיא משאירה את המדיניות הפנימית קריאה, אבל זו תרגום קידומות, לא שכבה קסומה: גבולות /64 חייבים להתיישר, סכומי ביקורת מותאמים, ויישומים שמטמיעים כתובות מילוליות עדיין נשברים. אם אתם שומרים על כתובות הספק מקצה לקצה, רשמו את התנהגות החכירה ואת נוהל השינוי בתכנית הכתובות.
סיימו במבחן שישרוד זמן: מארח מורשה בכל LAN מגיע לשירות ב-LAN האחר, התשובה חוזרת דרך המנהרה, ואותו זוג עדיין עובד לאחר הפעלה מחדש של המנהרה וחידוש ההאצלה. אם החלק האחרון נכשל, התכנון תלוי במצב שלא ישרוד את השבוע.