OpenVPN Connect דוחה fragment: תקנו את מקור הפרופיל

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

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

היכן הייבוא נעצר

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

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

מה fragment משנה בלקוח הקהילה

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

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

בקשו פרופיל שנבנה עבור הלקוח הזה

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

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

אמתו את החיבור, לא רק את הייבוא

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

openvpn --config client.ovpn --verb 3
ip -4 addr show tun0
curl -sS --interface tun0 -o /dev/null -w '%{http_code}\n' --max-time 8 https://example.com/

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

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