שליחת דואר נכשלת כשהרשת VPN מתחברת: מצאו את השלב

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

שלב 1: סווגו את הכשל לפני שנוגעים באישורים

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

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

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

שלב 2: אשרו את נקודת הקצה ואת מצב ה-TLS

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

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

הרצת הבדיקה השגויה מבין השתיים היא בדיוק הטעות שהלקוח עושה כשהוא מוגדר למצב האחר. אם בדיקת ה-TLS המשתמעת נתקעת בפורט 587, או שבדיקת STARTTLS נכשלת בפורט 465, הפורט והמצב אינם תואמים. תקנו את המצב בלקוח במקום לכבות את אימות התעודה, שממיר שגיאת הגדרה בחיבור לא מאומת. ההפרדה ישנה מספיק כדי להיות תקנית: TLS משתמע בפורט 465 הוא הסידור המתואר במסמך RFC 8314.

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

שלב 3: השוו מסלולים בלי לשנות את החשבון

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

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

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

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

שלב 4: שלחו הודעה אחת בלתי מזיקה ותעדו את התשובה

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

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

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