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

היעד כאן הוא לקוח שורת פקודה OpenVPN 2.6 עבור Linux, מנותב ב-TUN מעל UDP, עם אימות בתעודה.

אספו רק את הקבצים בצד הלקוח

עבדו בתיקייה מוגנת ואספו את חומר האמון של CA שאושר, את תעודת הלקוח שהונפקה לכם ואת המפתח הפרטי המתאים לה. בדוגמה הזו השמות הם ca.crt, laptop-a.crt ו-laptop-a.key. שמות הקבצים הם רק תוויות; הם לא אומרים דבר על מה שכל קובץ מכיל.

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

השאירו את מפתח החתימה הפרטי של ה-CA, את המפתח הפרטי של השרת ואת פרמטרי ה-DH מחוץ לחבילה הזו.

חברו את הקבצים לפרופיל קטן

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

client
dev tun
proto udp
remote vpn.example.net 1194
nobind

remote-cert-tls server
verify-x509-name vpn-gateway name
ca ca.crt
cert laptop-a.crt
key laptop-a.key

השורה remote בוחרת את נקודת הקצה ברשת. remote-cert-tls server דורש שהצד השני יציג תעודה בתפקיד שרת. verify-x509-name מקבע את השם הצפוי, כאן vpn-gateway כ-Common Name של תעודת השרת עם שדה השם המוגדר כברירת מחדל ב-OpenVPN. הערך הזה אינו נגזר משם המארח ב-DNS, לכן השתמשו בסכימת הזהות שהמפעיל סיפק.

אל תוותרו על הבדיקות האלה רק מפני שנקודת קצה לבדיקה מציגה תעודה אחרת.

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

הפכו את תיקיית העבודה למפורשת

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

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

sudo openvpn --cd /etc/openvpn/client/laptop-a --config laptop-a.ovpn

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

השאירו את המפתח קריא רק למשתמש או לזהות השירות המיועדים.

אמתו את המסירה, לא את שמות הקבצים

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

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

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

מאמרים קשורים