WireGuard במרחב שמות רשת: למה הסוכול נשאר מאחור

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

התסמין: מרחב שמות נכון, בלי מנות

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

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

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

למה לסוקט יש מקום לידה

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

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

צרו אותו במקום שבו אתם רוצים את הסוקט

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

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

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

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

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

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

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

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

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