WireGuard 5G שלוחה: תנו לשלוחה לחייג אל הרכזת

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

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

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

איזה צד מחזיק בנקודת הקצה היציבה

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

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

תנו לשלוחה תצורה ששורדת מספור מחדש

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

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

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

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

אמתו את המיפוי ואת המעבר

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

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

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

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

מה התכנון הזה לא פותר

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

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

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

מאמרים קשורים