NAS של Synology עם שני פורטות LAN: למה לחיצת היד של ה-VPN נכשלת

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

מה הלקוח מדווח ומה באמת קרה

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

הפורטה והכתובת הכבולה הם שתי העובדות שקובעות אם חבילה בכלל תגיע.

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

מצאו את הכתובת שעליה החבילה מאזינה

DSM ממספר את פורטות Ethernet וכל אחת נושאת כתובת משלה. דף VPN Server מציין את הממשק שבו משתמש שירות OpenVPN, ולוח הרשת מציג את הכתובת שהוגדרה בממשק הזה. קראו אותם בסדר הזה, מהשירות החוצה, כדי שתתארו את מה שמאזין ולא את מה שאתם מניחים שהוא אמור להשתמש בו.

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

sudo ss -lunp | grep 1194

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

תקנו את ההעברה, ואז הביטו במונה

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

אם DSM מקבל את הכתובת הזו דרך DHCP, צרו קודם הקצאה קבועה. שינוי חכירה שובר בשקט העברה שעבדה אתמול.

sudo tcpdump -i any -n udp port 1194

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

רק אז הביטו בתעודות ובתחבורה

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

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

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