שני peers של WireGuard חולקים טווח: מי מקבל את החבילה

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

הקידומת הארוכה ביותר מנצחת בתוך WireGuard

כל רשומת peer נושאת קבוצה של קידומות יעד. כאשר חבילה מנותבת אל הממשק, המימוש מחפש את הרשומה עם הקידומת התואמת הספציפית ביותר — אותו כלל שטבלת ניתוב מיישמת. לכן /24 גובר על /16 שמכיל אותו, וה-peer הצר יותר מקבל את התעבורה.

הגדרות road-warrior משתמשות בזה בכוונה. peer אחד מחזיק בטווח רחב לאתר, ומארחים בודדים נגזרים ברשומות /32 ששייכות ל-peers אחרים. התבנית עובדת מפני שהגזירות ספציפיות יותר, לא בגלל הסדר.

רשמו את הבעלות כטבלה של קידומת ו-peer. אם שתי רשומות מתארות את אותה קידומת, התצורה כבר לא מבטאת כוונה, היא מבטאת מירוץ.

מערכת ההפעלה בוחרת קודם את הממשק

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

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

חבילות נכנסות נבדקות לפי מקור

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

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

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

טווחים כפולים אינם failover

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

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

ודאו את הבחירה לפני עריכה

שלוש פקודות עונות על שלוש השאלות לפי הסדר. הראשונה מפרטת את הטווחים שכל peer תובע. השנייה מראה באיזה ממשק המארח ישתמש ליעד. השלישית מראה את מצב ה-peers החי לאחר שהתעבורה זרמה.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

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

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