האם WireGuard מוכן לייצור? התשובה אינה הפרוטוקול

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

השאלה שמאחורי השאלה

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

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

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

שער ראשון: הנתיב חייב לשאת UDP

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

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

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

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

שער שני: מישהו חייב להחזיק בבעלות על המפתחות

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

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

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

שער שלישי: החבילה צריכה מתחזק

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

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

שער רביעי: קבל את עומס העבודה, לא את לחיצת היד

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

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

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

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

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