לערוך יומן VPN בלי לאבד את הרמזים החשובים
הסירו כל דבר שמיש, שמרו תווית אחת לכל ערך אמיתי, ושמרו על הסדר והגרסאות. יומן שנערך צריך עדיין לאפשר לזר לעקוב אחר התקלה.
אתם מדביקים יומן בשרשור תמיכה, תגובה מציינת שהוא מכיל את המפתח הפרטי שלכם, וההדבקה קבועה. התקלה השקטה יותר מופיעה מאוחר יותר, כשכל כתובת הפכה ל-X והקובץ כבר לא מוכיח שהלקוח והשרת היו מארחים שונים. מעבר עריכה מסיר את מה שמעניק גישה או נוקב בשם של אדם, ומשאיר את מה שמסביר את התקלה. זהו שינוי עם כללים, לא מחיקה עם תיבת חיפוש.
עריכה היא שינוי, לא מחיקה
יומן נושא מבנה כמו גם ערכים: הכתובת הזו דיברה עם ההיא, בזמן הזה, ולחיצת היד נעצרה בשלב הזה. הערכים הם מה שהופך את הקובץ למסוכן לפרסום. המבנה הוא מה שהופך אותו לראוי לפרסום מלכתחילה.
מחיקת שורות שלמות מסירה את שניהם בבת אחת, ולכן יומן מקוצר לרוב לא עונה על דבר. כיווץ כל ערך לאסימון אחד נכשל אחרת, כי שני עמיתים נפרדים הופכים לשחקן אחד. שני המעברים יכולים להיראות מסודרים ובכל זאת להרוס את הראיה. המבחן הוא אם קורא שמעולם לא ראה את הרשת שלכם יכול לעקוב אחר הרצף ולהגיע למסקנה שאליה הגעתם.
קודם קטע, אחר כך ניקוי
חתכו את הקטע סביב התקלה לפני שתערכו דבר. קטע קטן יותר קל לבדוק, ופחות סביר שיישא משהו ששכחתם שהיה בקובץ. שמרו את המקור שלא נגעו בו באחסון מוגן עד שהנושא ייסגר. העריכה מאבדת מידע, והקובץ הגולמי הוא הדרך היחידה לענות על השאלה הבאה.
קראו את הקטע כטקסט פשוט לפני שאתם סומכים על פקודת ייצוא שהסירה את החלקים הפרטיים, כי מייצאים מסכמים ומסובבים שדות במקום לטהר אותם. מצבי debug ו-verbose הם המקום הסביר ביותר לבלוק מפתח או לאישור גישה מוטמע. פתחו את הקובץ בעורך שמציג שורות מלאות, לא בצופה שעוטף ומסתיר את הזנב.
מה חייב ללכת, ובאיזה סדר
התחילו בחומר שמעניק גישה, כי פספוס שם מסיים את התרגיל: בלוקי מפתח פרטי, סיסמאות, מפתחות משותפים מראש, אסימוני API, קודי שחזור. אלה לא רק מזהים; הם שמישים לכל מי שקורא את השרשור. מעבר שמסיר את כל השאר ומשאיר אחד מהם נכשל.
אחר כך שכבת הזהות: שמות משתמשים, נושאים ומספרים סידוריים של תעודות, מזהי חשבון, וכל נתיב שמכיל שם של אדם. שום דבר מזה לא שמיש לבדו, אבל יחד הם נוקבים בשם של אדם, וזה החלק ששרשור ציבורי לא צריך.
אחר כך שכבת הטופולוגיה, וכאן נכנס שיקול הדעת. כתובות ציבוריות, טווחים פנימיים ושמות מארחים כולם ניתנים להחלפה כשהחשיפה שלהם לא משרתת שום מטרה אבחונית, ותוויות יציבות עדיפות על ריק. הסדר חשוב כי השכבות הקודמות מוחלטות והאחרונה היא החלטה. עבודה בסדר הזה גם מונעת מכם לבזבז שעה על שמות מארחים בזמן שבלוק מפתח יושב בשורה הארבעים.
| Original kind | Replace with | Keep |
|---|---|---|
| Client address | CLIENT_A | Which side initiated |
| Server address | SERVER_B | Port and protocol |
| Username | USER_1 | The failure that mentions it |
| Hostname | HOST_1 | Resolution order |
אל תהרסו את היחסים
תנו לכל ערך אמיתי ממלא מקום אחד והשתמשו בו שוב בכל פעם שהערך הזה מופיע. אם שתי כתובות היו שונות, הן חייבות להישאר שונות אחרי המעבר, אחרת הקורא יסיק שהלקוח התחבר לעצמו. העקביות היא כל המנגנון: הקורא לומד את המיפוי כשהוא רואה תווית חוזרת. אסימון אחד בשימוש חוזר לשני שחקנים הוא הדרך המהירה ביותר להפוך יומן לבלתי קריא.
סדר וזמן הם חלק מאותו מבנה. שמרו על הרצף שלם, ואם אתם מזיזים חותמות זמן, הזיזו את כולן באותה כמות ואמרו זאת בשורה אחת. ערבוב זמנים משונים ואמיתיים גרוע מהסרתם, כי אז הפערים נראים כראיה למשהו שמעולם לא קרה.
פורטים, פרוטוקול וכיוון נשארים כפי שהם. ממלא מקום בכתובת לא מחייב ממלא מקום בפורט.
שמרו על השאלה שהיומן חייב לענות עליה
רשמו את השדות שעוזר צריך לפני שתתחילו לערוך: טקסט השגיאה המדויק שאינו סודי, גרסאות לקוח ושרת, התעבורה, ואיזה צד יזם את הניסיון. אלה מאפשרים לזר לזהות את התקלה. החזקת הרשימה לצדכם הופכת את המעבר לבדיקה ולא לתקווה.
כשאתם שולחים את הקובץ, הוסיפו שורה אחת שאומרת מה הוחלף, כדי שאיש לא יבזבז שעה באבחון שם מארח של ממלא מקום. התיעוד של OpenVPN על יומני אבחון מפרט את השדות שהיומנים שלו נושאים, וזו הרשימה שאתם עומדים לשנות. שאלו לפני שליחת dump של זיכרון או לכידת מנות, והשתמשו בערוץ התמיכה שאתם יכולים לאמת. חפצים אלה מכילים הרבה יותר מהיומן הטקסטואלי, וחלק מזה אינו שלכם לפרסום.
קראו את הקטע המוגמר פעם אחת מהשורה הראשונה לאחרונה, כולל ההתחלה והסוף. צילומי מסך ראויים לחשד רב יותר מטקסט, כי הם נושאים חלונות אחרים, שמות חשבון ופריטי תפריט.