לחיצת היד של OpenVPN ב-Synology נכשלת? בדקו את העברת ה-LAN

המחשב הנייד שלכם מדווח שלחיצת היד של TLS נכשלה, ולכן הפיתוי הוא לבנות מחדש את התעודות. לפני כן, שאלו שאלה משעממת יותר: באיזה פורט Ethernet ה-Synology באמת מאזין? ל-NAS עם שני פורטי LAN יש שתי כתובות, וחבילת VPN Server של DSM קושרת את מאזין ה-OpenVPN שלה לאחת מהן. כשהנתב מעביר את 1194 לכתובת האחרת, שום חבילה לא מגיעה לשירות, וללקוח אין עם מה לנהל משא ומתן.

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

מצאו את הכתובת שאליה קשור המאזין

DSM מתייג את הפורטים שלו כ-LAN 1 ו-LAN 2, וכל אחד נושא כתובת ותת-רשת נפרדות. פתחו את VPN Server, קראו את הממשק הנקוב בכרטיסיית OpenVPN, אחר כך פתחו את לוח הבקרה ורשמו את כתובת ה-IPv4 שיש ל-DSM באותו ממשק. שני הערכים האלה, ולא שם המארח של ה-NAS, הם מה שההעברה חייבת לנקוב.

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

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

sudo netstat -anp | grep 1194

ערכו את ההעברה הקיימת במקום להוסיף עוד אחת

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

external 1194/udp  ->  192.0.2.20:1194/udp

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

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

הוכיחו אם החבילות בכלל מגיעות

התחילו קודם לכידה ב-NAS, אחר כך התחברו מהלקוח, וקראו את כתובת המקור בפלט. לכידה שהתחילה אחרי הכשל לא מראה דבר ולא מוכיחה דבר.

sudo tcpdump -i any -n udp port 1194

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

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

כשהחבילות מגיעות, הפסיקו להאשים את ההעברה

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

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

בדקו את המסלול שמשתמש מרוחק באמת עובר

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

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