כיצד לאמת את השרת של פרופיל OpenVPN לפני ייבואו

מישהו שולח לכם פרופיל, אתם מייבאים אותו, ושלושים שניות לאחר מכן לקוח מחייג ליעד שאיש לא בדק. קראו תחילה את הקובץ בעורך טקסט, כי כל מה שחשוב נמצא בקומץ הנחיות: remote, proto, port, ca, cert, tls-crypt ו-verify-x509-name. כל השאר הם ברירות מחדל, ושם בדיוק גרות ההפתעות.

פרטו כל נקודת קצה שהקובץ יכול להשתמש בה

התחילו בנקודות הקצה, כי פרופיל אחד יכול להחזיק כמה. הפקודה grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn מדפיסה כל מועמד לפי סדר הקובץ, כולל אלה המקוננים בתוך בלוקי <connection> פנימיים.

כשההנחיה משמיטה פורט, הלקוח חוזר לברירת המחדל של המאזין, כך ש-remote vpn.example.com לבדו פירושו פורט 1194 עם כל proto שיופיע בהמשך הקובץ. כמה שורות remote פשוטות הן חלופות: הלקוח מנסה אותן לפי הסדר אלא אם remote-random מערבב אותן, והוא לעולם אינו מחליף בשקט במארח של מפעיל אחר. שתי שורות remote בדומיינים לא קשורים הן הנקודה שבה עוצרים ושואלים איזו מהן התכוונו.

שימו לב גם לאיות של proto. tcp מתקבל כמילה נרדפת ל-tcp-client בצד הלקוח, אבל tcp-server בפרופיל לקוח הוא שגיאת תצורה שנוטה להיתקע במקום להיכשל נקי.

אמתו את השם, ואחר כך את הפורט

dig +short vpn.example.com אומר לכם אם השם קיים ואילו כתובות הוא מחזיר, ונקודת קצה עם כמה כתובות או מאחורי פרוקסי עשויה להחזיר כמה כדין. פתרון השם הוא תנאי מוקדם, לא הוכחת בעלות; כל אחד יכול להפנות שם לכתובת, וכתובת אחת יכולה לענות עבור שמות רבים.

לאחר מכן בדקו את המאזין בפורט שמצאתם, בהתאמה לשכבת התעבורה. מעל TCP, openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com מדפיסה את השרשרת שהשרת מציג. מעל UDP דרוש DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 מריץ את אותה לחיצת יד מעל דאטהגרמים. לחיצת יד שהושלמה מוכיחה שמשהו מאזין ומחזיק תעודה, וזה יותר ממה ש-ping מראה ופחות ממה שדורשות הגדרות האמון של הפרופיל עצמו.

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

קראו את סיכות האמון בנפרד מהכתובת

הכתובת קובעת לאן הלקוח הולך; בלוק האמון קובע במי הוא מאמין כשמגיע. verify-x509-name "vpn.example.com" name מצמיד את השם הנפוץ של הנושא, ו-remote-cert-tls server דורש את השימוש המורחב במפתח לאימות השרת. פרופיל שמפעיל מוסר לכם אמור לשאת את שניהם.

חפשו ca, בלוק <ca> פנימי, ואת tls-crypt או tls-auth. פרופיל שמשתמש ב-tls-auth זקוק ל-key-direction 1 בלקוח כשצד השרת משתמש בכיוון 0, וחוסר התאמה מפיל את לחיצת היד בשגיאת TLS שנקראת כמו תקלת תעודה. CA פנימי שאינו שייך למפעיל שזה עתה פתרתם את שמו פירושו שהקובץ הורכב משני מקורות, וזה המקרה שראוי לסרב לו באופן מוחלט.

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

בדקו את האפשרויות שנכשלות בשקט

OpenVPN 2.6 מנהל משא ומתן על צפנים דרך data-ciphers, ופרופיל שנושא רק שורת cipher AES-256-CBC ישנה יכול להשלים את ערוץ הבקרה ואז להיתקע על הנתונים. קריאת הערך הזה אומרת לכם אם הקובץ קודם לשרת שאליו אתם מצטרפים; עמוד המדריך של 2.6 מפרט את סדר המשא ומתן אם צריך לצטט אותו למפעיל.

auth-user-pass בלי שם קובץ פירושו שהלקוח ישאל, ולכן פרופיל שנראה עצמאי עדיין זקוק לאישורים. auth-user-pass credentials.txt פירושו שהוא מצפה לקובץ שקרוב לוודאי לא נשלח אליכם. nobind ו-resolv-retry infinite רגילים ובלתי מזיקים, ואילו explicit-exit-notify מיועד ל-UDP בלבד וחסר תועלת מעל TCP.

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

החליטו, ואז תעדו מה החלטתם

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

תעדו את ה-hash שבדקתם, כדי שהאדם הבא יוכל לדעת אם הקובץ השתנה: sha256sum profile.ovpn, מודבק לצד נקודת הקצה בהערות שלכם. פרופיל הוא סידור שלם, לא רשימת כתובות, ולכן לעולם אל תשחילו remote עובד לתוך בלוק האמון של מישהו אחר תוך שמירה על אישוריו.

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

אם בכל זאת תייבאו אותו והניסיון הראשון ייכשל, הריצו את הלקוח עם --verb 3 וקראו את עשר השורות הראשונות: כתובת ה-remote שנפתרה, ה-proto שנוהל עליו משא ומתן והשגיאה של TLS מופיעים בסדר הזה, מה שאומר לכם איזו מהבדיקות שלמעלה דילגתם עליה.