איך בונים בדיקת WireGuard עם שני עמיתים שמוכיחה נתיב אחד

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

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

מפתחות, כתובות ונקודת הקצה היחידה

צור זוג מפתחות בכל מערכת והעבר ביניהן רק את החצאים הציבוריים. wg genkey | tee privatekey | wg pubkey > publickey היא הפקודה המתועדת בשורה אחת, והיא משאירה את המפתח הפרטי בקובץ שאפשר אחר כך להגן עליו. בחר כתובות מנהרה מטווח שלא מופיע בשום תצורה אחרת שיש לך, כמו 10.99.0.1/24 ו-10.99.0.2/24. רשום איזו כתובת שייכת לאיזו מכונה, כי כל בדיקה מאוחרת תלויה במיפוי הזה.

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

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

השדות ששייכים ל-wg ואלה שלא

מערך השדות המרכזי קטן: PrivateKey ו-ListenPort תחת Interface, PublicKey, AllowedIPs ו-Endpoint תחת Peer. Address ו-DNS שייכים ל-wg-quick ולא ל-wg עצמו, וההבחנה הזו נושכת ברגע שאותה תצורה עוברת לכלי אחר.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs נושא שתי משימות בבת אחת. הוא בוחר אילו יעדים נכנסים למנהרה, ו הוא מאשר לעמית להשתמש בכתובות המקור האלה בהגעה. משום כך הרשומה המקבילה בצד השני חייבת לנקוב בכתובת המנהרה שלך במדויק; /32 לעמית הלא נכון נקרא כבעיית ניתוב ומתנהג כבעיית הרשאה. התחלה מהירה של WireGuard מציגה אותה צורת שני עמיתים עם הניסוח הקנוני אם ברצונך להשוות שמות שדות.

לקרוא את לחיצת היד במקום את הסמל

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

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

להוכיח שירות מותר אחד, ואז את ההפוך

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

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

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

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

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