מה באמת מכיל קובץ .ovpn, ומה הוא לא יכול לעשות

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

קראו את הקובץ כרשימת בקשות הפונה ללקוח שלכם, ורוב השורות שלו יהפכו למובנות.

הקובץ מתאר את הלקוח שלך, לא את השרת

פרופיל מאגד remote נקודת קצה, תעבורה, סוג ממשק, חומר זהות וכל התנהגות בצד הלקוח שהמפעיל רוצה. כל שורה מבוצעת על ידי הלקוח בעת האתחול. אף אחת מהן לא מגיעה לשרת כשינוי תצורה, ואף אחת לא יכולה ליצור מאזין שאינו פועל כבר. פרופיל שמציין TCP 443 מול שרת שמקשיב רק ב-UDP 1194 נכשל כבר במנה הראשונה.

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

שורות התעבורה חייבות להתאים למאזין שכבר קיים

proto ו remote חייבות להתאים למה שהשרת באמת קושר. UDP הוא הבחירה הרגילה מפני שדאטהגרם שאבד לא עוצר את המנהרה, ואילו TCP יכול לשרוד ברשתות מגבילות במחיר חסימת ראש התור בתוך המנהרה. מעבר פרופיל מ-UDP ל-TCP לא גורם לשרת לקבל TCP; הוא רק גורם ללקוח לשלוח ליציאה שאיש לא קורא.

יציאה 443 פופולרית מפני שהיא עוברת ברשתות שמאפשרות מעט מאוד אחר, והיא נשארת הפעלת OpenVPN ולא בקשת HTTPS. אם המפעיל מפרסם כמה שורות remote, הלקוח מנסה אותן לפי הסדר, וזו רשימת מעבר בעת כשל ולא החלטת איזון עומסים. שמרו על השילובים שהמפעיל סיפק במקום לערבב מארח מרשומה אחת עם יציאה מאחרת.

מפתחות מוטמעים משנים את אופן הטיפול בקובץ

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

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

ייתכן שמסלולים ו-DNS כלל לא יגיעו מהקובץ

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

DNS פועל באותו דפוס: dhcp-option DNS שנדחף יכול להיות מיושם על ידי הלקוח, להתעלם, או להיעקף על ידי מנהל פותר מקומי. בדקו את מצב הפותר אחרי ההתחברות במקום לקרוא את הפרופיל שוב.

אפשרויות לא נתמכות הן שאלה של גרסת לקוח

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

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

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