WireGuard: שני חצאי מסלולים מול 0.0.0.0/0 ב-wg-quick

שני קידומות /1 מכסות בדיוק את אותן כתובות IPv4 שקידומת אחת /0 מכסה, והשוויון הזה תקף רק בתוך רשימת הקידומות המותרות של העמית. הוא מפסיק להיות תקף ברגע שכלי ההגדרה מחליט איך לנתב, מפני ש-Linux wg-quick מתייחס לקידומת ברירת מחדל כמקרה מיוחד ולא כאריתמטיקה. הענף המיוחד מתקין טבלה נפרדת, שני כללי מדיניות, סימן שקע והגדרות נתיב הפוך שזוג חצאי מסלולים לעולם אינו מקבל. לכן כשמתווך או דפדפן מפסיק לעבוד אחרי העריכה, הקידומות הן החלק הפחות מעניין בשינוי.

רשימת הקידומות אינה כל התצורה

AllowedIPs עושה שתי עבודות בבת אחת, ורק אחת מהן נוגעת לכיסוי. עבור WireGuard עצמו הרשימה היא ניתוב לפי מפתח הצפנה: היא קובעת אילו יעדים מוצפנים אל העמית ואילו כתובות מקור העמית רשאי להשתמש בהן. עבור wg-quick אותה רשימה משמשת גם כמפרט מסלולים, והמסלול שהיא מייצרת תלוי באיזה ענף הרשימה במקרה מתאימה. לכן כיסוי זהה בשתי צורות רשימה שונות אינו אומר דבר על מצב מארח זהה.

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

מה הענף המוגדר כברירת מחדל מוסיף מעבר למסלול

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

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

היכן שני הסידורים מתפצלים

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

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

קראו את הכללים והסימנים לפני עריכה

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

ip rule show
ip -4 route show table all | grep -E 'default|wg1'
wg show wg1 fwmark
wg show wg1 endpoints

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

תרגלו אובדן מנהרה לפני שחרור

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

sudo ip -4 route add 198.51.100.20/32 via 192.0.2.1 dev eth0
ip -4 route get 198.51.100.20
sudo wg-quick down wg1

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