מי הבעלים של הכתובת, המסלול, ה-DNS וחומת האש ב-VPN לינוקס?

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

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

ההתקן והכתובות שלו

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

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

מסלולים וכללי מדיניות

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

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

ה-DNS הוא תמיד בעלים נפרד

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

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

מצב חומת האש, ומי משחזר אותו

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

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

מחזור חיים: אתחול, התחברות מחדש, פירוק

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

לצורך תצפית, ip monitor link address route מציג שינויי ליבה כשהם קורים, אבל הוא מדווח על אירועים ולא על כוונה: מסלול שנמחק לא אומר דבר על איזה תהליך מחק אותו. חברו אותו למפת הבעלות, וכיבוי מבלבל יהפוך לרשימה קצרה של מועמדים.

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