לקוח Kerio VPN ב-Linux: חמישה בדיקות לפי הסדר
חמישה בדיקות לפי הסדר: ארכיטקטורת החבילה, אשף שורת הפקודה, קובץ התצורה, סקריפט השירות והיומנים. עצרו בראשונה שנכשלת.
לאחר התקנת לקוח Kerio VPN ב-Linux לא מופיע סמל בשולחן העבודה והרשת הפרטית נשארת מחוץ להישג יד. זו הצורה הרגילה של לקוח זה ולא התקנה שבורה: הוראות GFI ל-Linux מתארות תצורה משורת הפקודה וסקריפט שירות, בלי שום ממשק גרפי. עברו על הבדיקות שלהלן לפי הסדר, כי כל אחת מסירה שכבה אחרת. הכשל הראשון אומר לכם היכן לעצור, ודילוג קדימה בדרך כלל פירושו בנייה מחדש של חבילה שמעולם לא הייתה הבעיה.
ודאו שהבנייה מתאימה למכונה
התחילו בשאלה מה dpkg חושב שהמכונה היא ולשם מה נבנתה החבילה. במערכת 64 סיביות רגילה, dpkg --print-architecture מדפיס amd64, ועמוד הספק מפרט חבילת amd64 לצד חבילת ה-Debian הרגילה. קראו את מחרוזת המהדורה בשם הקובץ שהתקנתם בפועל במקום להניח ששניהם תואמים.
ארכיון מ-2013 שנבנה ל-i386 אינו הופך ל-64 סיביות רק משום שהעברתם --force-architecture בעת ההתקנה. כפייה מתקינה בינאריים זרים, מסתירה כשל תלות מאחורי משגר שעדיין עולה, ועלולה להשאיר את הדמון טוען ספריות שגויות. אם המהדורה שבידיכם מסופקת רק ב-32 סיביות, הריצו אותה בסביבת 32 סיביות או בקשו מבעל השער בנייה עדכנית.
בדקו גם את שורת התלויות. dpkg -s kerio-control-vpnclient | grep -i depends מראה למה החבילה מצפה, ותלות גרסה שלא סופקה או ספריית זמן ריצה חסרה עולות כאן, ולא ביומן הלקוח.
הגדירו אותו דרך אשף החבילה
מלכתחילה אין ללקוח רשומה במגירת היישומים, ולכן סמל חסר אינו אומר דבר על הצלחת התצורה. פתחו שוב את האשף עם sudo dpkg-reconfigure kerio-control-vpnclient וענו על שאלותיו: נקודת קצה של VPN, פרטי החשבון וטביעת האצבע של תעודת השרת.
התייחסו לשאלת טביעת האצבע כמקום היחיד שבו שרת שגוי יכול לנצח. השוו את הערך למידע השרת שמסר האדמין שמפעיל את השער, ולא למה שנקודת הקצה מציגה. קבלת טביעת אצבע שאינכם יכולים לאמת הופכת את שאר הרשימה לקישוט, כי שרת עוין נראה זהה לשרת האמיתי ברגע שהסיכה נשמרה. אם אי אפשר לאשר את הערך בערוץ אחר, עצרו ושאלו, גם כשהמנהרה הייתה עולה אחרת.
הרצה חוזרת של האשף משנה את התצורה ועלולה להפעיל מחדש את הלקוח, לכן החזיקו נתיב שני אל המכונה כשהסשן שאתם עובדים דרכו תלוי ב-VPN הזה. הקלידו את הסיסמה בהנחיה הרגילה במקום לשבץ אותה בפקודה שתגיע להיסטוריית המעטפת.
הכירו את הקובץ שהאשף כותב
התצורה נמצאת ב-/etc/kerio-kvc.conf, והיא נושאת גם את החשבון וגם את טביעת האצבע המוצמדת. התייחסו אליו כאל חומר סודי. sudo stat -c '%a %U %G' /etc/kerio-kvc.conf לא אמור להציג אותו כקריא לכולם.
לאחר עריכה ידנית מורשית, טענו מחדש את הדמון שמחזיק בקובץ במקום להפעיל מחדש את מחסנית הרשת: sudo /etc/init.d/kerio-kvc reload. טעינה מחדש קוראת שוב את התצורה ומפילה את הסשן הנוכחי, ולכן היא אינה פעולה חסרת השפעה על חיבור חי.
העתיקו את הקובץ הקודם לפני שתשנו משהו. אם האימות נכשל לאחר עריכה, שחזור העותק התקין האחרון אורך שניות ומבודד את העריכה מהרשת, וזו הדרך הזולה ביותר לדעת איזה מן השניים זז.
הפרידו את הסשן החי מהתנהגות האתחול
סקריפט השירות שולט בחיבור הנוכחי: sudo /etc/init.d/kerio-kvc stop מסיים את המנהרה עכשיו ו-start מחזיר אותה. אף אחת משתי הפקודות לא קובעת מה יקרה באתחול הבא, וההבדל הזה חשוב במכונה שאתם מנהלים מרחוק.
בררו מי מחזיק באתחול לפני שאתם מסירים קישורים או מסתירים משהו. החבילה עשויה להתקין סקריפט init משלה, ליצור unit או את שניהם, וכיבוי השם הלא נכון מחזיר את הלקוח לאחר אתחול. בדקו את systemctl status kerio-kvc מול השם שהתיעוד של החבילה משתמש בו, ואז כבו את הנתיב שתהליך האתחול קורא בפועל.
אל תחליפו unit של OpenVPN רק מפני שהתצורה נראית דומה. הלקוח הזה מדבר בפרוטוקול משלו עם שער Kerio, ולכן דמון אחר שמכוון לאותו קובץ לא יאומת, והכשל הנוסף הופך את הראיות לקשות יותר לקריאה. לקוח GFI ל-Linux גם מחזיק בחיבור VPN אחד בלבד בכל רגע; המגבלה הזו חלה על הלקוח, לא על קיבולת המשתמשים של השער.
קראו את היומנים ואז אמתו את המשאב
שלושה קבצים תחת /var/log/kerio-kvc מספרים את סיפורו של הדמון: init.log לאירועי מחזור חיים, error.log לכשלים קריטיים ו-debug.log לפרטים. קראו את הקטע הקטן ביותר שעונה על שאלתכם, והסירו נקודות קצה ושמות משתמש לפני שתדביקו אותו במקום כלשהו. פער ב-init.log בסביבות הזמן שבו הרצתם את האשף אומר לכם שהדמון מעולם לא הופעל מחדש.
| File | Read it for | Skip it when |
|---|---|---|
init.log | start, reload and stop events | you already know the daemon restarted |
error.log | failed authentication and certificate problems | the tunnel is up and traffic still fails |
debug.log | protocol detail worth attaching to a ticket | the error is already named in error.log |
חבילה תקינה, דמון פועל ומשאב נגיש הם שלוש תוצאות נפרדות, והרשימה שלמה רק כשכל השלושה מתקיימים. לאחר שינוי מאושר, בקשו מארח שקיים רק מאחורי השער, ואז פתחו עליו שירות רגיל. אם המנהרה למעלה והמשאב לא, התקלה שנותרה נמצאת בנתיב בשער או בכלל חומת אש, ולא בלקוח שזה עתה הגדרתם מחדש.
רשמו את המצב שבו סיימתם: מהדורת החבילה, הארכיטקטורה, אם טביעת האצבע אומתה בערוץ אחר ואיזו טעינה מחדש או הפעלה מחדש הפעלתם. ההערה הזו היא מה שהופך את הבדיקה הראשונה של האדם הבא לזולה.