וו לקוח או וו שרת? היכן רץ סקריפט של OpenVPN

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

שתי מכונות, שתי שאלות שיש לענות עליהן קודם

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

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

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

האפשרות בצד השרת: אירוע לכל חיבור

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

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

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

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

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

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

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

למה דחיפת קוד הרצה לא נמצאת בתפריט

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

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

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

מה לאמת לפני שסומכים על מי מהווים

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

בדקו תחת החשבון שבאמת יריץ אותו, ברגע שבו הוא באמת ירוץ. המדריך openvpn(8) מתעד את שתי משפחות הווים ואת מגבלות ה-push; הפלטפורמה שאתם פורסים עליה מתעדת אם היא חושפת אותן בכלל. סקריפט שמצליח בטרמינל מנהל אינטראקטיבי הוא השערה, לא אימות.