אתם מדביקים את פקודת ההתקנה בשורה אחת מתוך מדריך, לוחצים Enter ומקבלים curl: (77). ההודעה מזכירה מיקומי אימות אישור, ולכן האינסטינקט הוא להניח שהאישור של ספק ה-VPN שבור ולחפש דגל שמדלג על האימות. הקריאה הזאת שגויה, ופעולה לפיה הופכת בעיית קובץ מקומית להחלטה ביטחונית. נחזור להתחלה.

שלב 1: קראו מה המספר אומר

שגיאה 77 עוסקת בקלט ה-CA המקומי: curl לא הצליח לקרוא או לטעון את חומר האישור שנאמר לו לבטוח בו. שגיאה 60 היא זו של הצד השני, כאשר שרשרת השרת אינה מאומתת. הן מופיעות זו לצד זו במדריכים ומשמעותן הפוכה.

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

שלב 2: קראו את הפקודה שהעתקתם

פקודות מועתקות מסתירות תווים. האות הקטנה -l היא --list-only, שמתייחסת לרישום פרוטוקולים. האות הגדולה -L היא --location, שעוקבת אחר הפניה מחדש של HTTP. אלו אינן צורות כתיב חלופיות, ומדריך שכותב אחת ומתאר את האחרת שולח אנשים במסלול הפניה שלא נועד מעולם.

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

שלב 3: גלו איזה קלט CA הבנייה הזו משתמשת בו

התחילו בזיהוי הקובץ הבינארי, כי התשובה תלויה באופן שבו הוא הורכב:

curl --version

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

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

שלב 4: תקנו את הקלט, לא את האימות

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

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

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

שלב 5: הורידו, הביטו ואז הריצו

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

curl -fL -o vpn-installer.sh https://example.invalid/install.sh
file vpn-installer.sh
head -n 40 vpn-installer.sh

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

זכרו מה HTTPS עשה ומה לא. הוא אימת את התעבורה אל המארח שאיתו יצרתם קשר; הוא לא סקר את תוכן הסקריפט והוא לא אומר לכם אם המפרסם אמין.

שלב 6: הפרידו בין שלבי ההתקנה

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

אם ההתקנה מצליחה והמנהרה עולה, אמתו את המסלולים ויעד אמיתי אחד לפני שסוגרים את הפנייה. שגיאת curl תוקנה כשפקודה פשוטה curl -I https://example.invalid עובדת שוב, לא כשהמתקין מפסיק להתלונן.

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