OpenVPN push-peer-info: תיוג לקוחות בלי להעניק גישה

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

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

הגדירו את המשתנה והפעילו את הנתיב

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

setenv UV_DEPLOY field-support
push-peer-info

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

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

קראו את השדה מהוו בשרת

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

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

קראו את המשתנה דרך הסביבה ולא על ידי ניתוח הלוג, ותנו לו תמיד ערך ברירת מחדל. ${UV_DEPLOY:-unset} משאיר את הסקריפט עובד עבור לקוחות שלעולם אינם שולחים את השדה, וזה המצב הרגיל בפריסה מדורגת. אל תשפכו את כל הסביבה ללוג כדי למצוא את השם; היא מכילה הרבה יותר מהתג, כולל ערכים שלא התכוונתם לשמור.

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

אמתו מה באמת הגיע

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

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

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

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

תייחסו לתג כאל טענה, לא כאל זהות

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

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

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

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

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

הסרת התכונה היא שתי מחיקות ואימות אחד. הסירו את השורות setenv ו-push-peer-info מפרופיל הלקוח, ואז הסירו או השביתו את הוו ואת יעד הלוג שלו בשרת.

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

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

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