מדריך הפעלה: קליטת שני לקוחות OpenVPN בנפרד

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

הקצו כרטיס משאבים מלא לכל לקוח

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

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

שמרו את חומרי האמון בתוך כל לקוח

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

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

הפרידו גם את הרשתות וגם את התהליכים

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

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

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

אספקו ביטול לפני מסירה

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

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

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

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