קראו קונפיגורציית WireGuard שורה אחר שורה, מ-Interface ל-Peer

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

מפתחות interface מתארים את המכונה הזו

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

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

כל השאר ב-[Interface] בלוק עם לקוח אמיתי מתווסף בדרך כלל על ידי wg-quick: DNS, MTU, Table, ושורות ההוק. הם לא שדות פרוטוקול, והתקנת wg חשופה מתעלמת מהם לגמרי.

כל רשומת peer מתארת צד אחר אחד

בלוק [Peer] הוא הצד המרוחק. PublicKey הוא המפתח הנגזר של אותו צד, אף פעם לא המפתח הפרטי שלו, ו-PresharedKey הוא סוד נוסף אופציונלי ששני הצדדים חייבים להחזיק זהה. Endpoint הוא לאן לשלוח, ו-PersistentKeepalive מבקש מהמארח הזה לשלוח חבילה אחרי המרווח כשאין משהו אחר שיוצא.

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

AllowedIPs הוא ניתוב, לא רשימת הרשאות

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

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

מה wg-quick מוסיף סביב הפרוטוקול

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

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

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

בדקו את המצב המיושם, לא את הקובץ

הקובץ הוא כוונה. המצב המיושם הוא מה שהקרנל מחזיק, והם מתפצלים בכל פעם שכלי עזר, drop-in או הוק ערך משהו אחרי ההפעלה.

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

sudo wg show
ip -4 addr show dev wg0
ip -4 route show dev wg0
grep -v "^#" /etc/wireguard/wg0.conf

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