WireGuard AllowedIPs: המסלול ש-NetworkManager מעולם לא הוסיף

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

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

אמתו את המנהרה לפני שאתם רודפים אחרי המסלול

wg show מציג את הממשק, את ה-peer, את נקודת הקצה ואת גיל לחיצת היד האחרונה, ו-ip addr show מאשר שהכתובת קיימת. לחיצת יד עדכנית פירושה שהמפתחות, נקודת הקצה ונתיב ה-UDP עובדים. כל מה ששבור יושב במורד הזרם מהם: ניתוב, סינון או פתרון שמות.

אחר כך שאלו את הליבה מה היא תעשה עם יעד אמיתי במקום היפותטי: ip route get 10.42.7.9. התשובה נוקבת בממשק היציאה ובכתובת המקור שהחבילה תישא. כשהיא נוקבת במתאם הפיזי, החבילה לא נכנסת למנהרה לעולם, יהא מצב לחיצת היד אשר יהא.

AllowedIPs הוא גם מסנן וגם רשימת מסלולים

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

במקרה שמאחורי המאמר הזה, הפרופיל יובא דרך תוסף של צד שלישי ולא דרך התמיכה המובנית, והממשק עלה בלי מסלול הקידומת. רישום הטבלה מראה זאת מיד: ip route show מכיל רק את המסלול המחובר של כתובת הממשק, ושום דבר לטווח המרוחק.

שאלו אם מסלולי peer מופעלים בכלל

קראו את ההגדרה לפני שאתם משנים משהו: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. כשהשדה peer-routes מציג no, התיקון הנתמך הוא nmcli connection modify work-wg wireguard.peer-routes yes, ואחריו התחברות מחדש. הוספת מסלול סטטי במקום זה עובדת עד ההפעלה הבאה ואז נעלמת בשקט. ההיעלמות הזו היא הרמז: מסלול שחוזר כתעלומה כל בוקר אינו מותקן על ידי הפרופיל.

אם האפשרות כבר מופעלת, בדקו אם הקידומת חיה בטבלה אחרת עם ip route show table all | grep 10. מסלול בטבלה שאינה הראשית אינו חסר, הוא פשוט בלתי נראה לחיפוש שמושך רק מהטבלה הראשית. תקנו את ניתוב המדיניות במקום לערום מעליו רשומה כפולה.

הוסיפו את הקידומת לחיבור, לא למערכת הפועלת

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

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

מנהרה מפוצלת נקבעת על ידי רשימת הקידומות

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

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

בעלים אחד לטבלת הניתוב

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

כשהפיצול חייב ללכת אחרי מתאם פיזי ולא אחרי יעד, עברתם לניתוב מדיניות, וגם ניתוב מדיניות צריך מחבר אחד. אמתו בכך שתחזרו על ip route get, ואז תגיעו למארח בתוך הקידומת המרוחקת עם משהו שמדפיס את כתובת המקור שבחר. בדקו IPv6 ו-DNS בנפרד אם הפרופיל נושא אחד מהם.