פורט 1194 כבר בשימוש: למי שייך הסוקט הזה של OpenVPN?

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

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

קראו את שגיאת הקישור המדויקת

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

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

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

עשו מלאי של הסוקט, לא של הפורט

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

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

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

מצאו איזה תהליך מחזיק בו

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

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

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

בעלים אחד, או שני מופעים מתוכננים

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

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

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

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

אמתו את הקישור לפני כל דבר אחר

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

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

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