חיבור שנדחה אינו בעיית תעודה: מדריך הפעלה ל-VPN
דחייה היא תשובה של שכבת התעבורה; אימות התעודה מתרחש מאוחר יותר, בתוך לחיצת היד. סדר בדיקות קבוע לבוקר שאחרי תחזוקת ה-CA.
הלקוח אומר שהחיבור נדחה מיד אחרי שיצרתם מחדש את ה-CRL, אז ה-CRL נראה אשם. הוא לא. דחייה היא תשובה של שכבת התעבורה, ואימות התעודה מתרחש מאוחר יותר, בתוך לחיצת היד של המנהרה. התזמון הוא הקשר, לא הוכחה.
שתי בדיקות מפרידות בין המקרים בפחות מדקה, ואף אחת מהן לא נוגעת בהגדרות אמון.
קראו את השגיאה בשכבה שיצרה אותה
ECONNREFUSED מ-connect פירושו שניסיון התעבורה נדחה: משהו ענה ב-reset, או שהמחסנית דיווחה על פורט שאינו נגיש. בעיית תעודה לא יכולה לייצר שגיאה כזו, כי לחיצת היד של TLS לעולם אינה מתחילה בלי חיבור תעבורה. אם אתם רואים דחייה, הלקוח מעולם לא הגיע רחוק מספיק כדי להציג תעודה. העובדה הבודדת הזו שוללת ביטול תעודה כסיבה.
גם ההפך נכון. תעודה מבוטלת מייצרת חיבור TCP שהושלם ולחיצת יד שנכשלה, שנרשמת בשרת כשגיאת אימות.
דחיית TCP: אף אחד לא מאזין
עבור TCP, בדקו אם המופע המיועד פועל וקשור לכתובת ולפורט שבפרופיל. ss -lntp מציג מאזינים, והיעדרם הוא ההסבר הרגיל. חומת אש שדוחה במקום להפיל מייצרת את אותה הודעה בצד הלקוח, ולכן בודקים את שניהם.
בדקו גם את משפחת הכתובות. שירות הקשור ל-127.0.0.1 או רק ל-IPv6 ידחה לקוח שמתפרש לכתובת האחרת.
לאחר מכן קראו את יומן השירות במקום לנחש. הפעלה מחדש אחרי תחזוקת CA עלולה להיכשל בקובץ שאינו קריא או חסר ולעולם לא להגיע למצב האזנה, והיומן נוקב בשם הקובץ. זו כשל הפעלה, באג שונה מתעודה שנדחתה.
ל-UDP אין לחיצת יד לדחות
OpenVPN מעל UDP אינו מקים חיבור במובן של TCP, ולכן אין מה לדחות בזמן connect. בלינוקס, שגיאה שמציג socket של UDP יכולה להגיע מ-ICMP port-unreachable שנוצר על ידי datagram קודם. עמוד המדריך udp(7) מתאר את ההתנהגות האסינכרונית הזו.
לכן לקוח UDP יכול להדפיס דחייה בזמן שתהליך השרת פועל אך אינו קשור לכתובת המצופה.
היכן באמת נבדק CRL
ה-CRL נבדק במהלך לחיצת היד של TLS, אחרי שהצד השני מציג את התעודה שלו, ורק אם תצורת השרת מאפשרת זאת. האפשרות crl-verify של OpenVPN מצביעה על הקובץ, וכשל מופיע ביומן השרת כשגיאת אימות שמציינת את התעודה.
לכן לקוח מבוטל מתחבר בשכבת התעבורה ואז נכשל באימות. אותו שרת, אותו פורט, הודעה שונה לחלוטין.
בדקו את מנפיק ה-CRL ואת תאריכי התוקף כשתגיעו לשלב הזה. CRL שנחתם על ידי CA שגוי, או כזה שפג לפני שהלקוח התחבר, מייצר שגיאות אימות שאין להן שום קשר לתעודה של הלקוח עצמו.
מדריך קצר לפעם הבאה
אמתו קודם את התעבורה: מאזין קיים, משפחת כתובות נכונה, חומת אש שאינה דוחה. אחר כך אמתו שהשירות הגיע למצב האזנה על ידי קריאת יומן האתחול. ורק אז הסתכלו על שגיאות לחיצת יד אחר הודעות אימות. שמרו על הסדר הזה קבוע, כי כל שלב מבטל מחלקה שלמה של סיבות.
רשמו את התעבורה, היעד שנפתר, הפורט ואת טקסט השגיאה המדויק. התקנה מחדש של הלקוח הורסת את הראיה הזו ובדרך כלל לא משנה דבר.