קידומת מארח ב-WireGuard: למה כתובת אחת עובדת והשאר לא

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

מה קידומת הממשק באמת יוצרת

ב-Linux הקצאת כתובת לממשק יוצרת מסלול מחובר לאותה קידומת. אם תקצו קידומת מארח, המסלול המחובר מכסה כתובת אחת. אם תקצו /24, הוא מכסה 256, וכל אחת מהן נחשבת כעת לנגישה דרך אותו קישור.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

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

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

AllowedIPs הם שני כללים תחת שם אחד

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

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

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

מאיפה מגיע המסלול

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

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

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

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

קידומת רחבה יותר אינה מוסיפה את רשומת העמית

התיקון המפתה הוא לשנות את הכתובת ל-/24 כך שהמסלול המחובר יכסה את הרשת המקומית של השרת. זה נראה כאילו הוא עובד, והסיבה שזה נראה כאילו הוא עובד היא שהמסלול המחובר מתאים כעת, ולא ש-WireGuard למד משהו חדש.

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

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

אשרו את שני הכיוונים לפני שתשנו משהו

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

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

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

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