MULTI: כתובת מקור שגויה מהלקוח: של מי הייתה הכתובת הזו?
המקור הפנימי אינו תואם ללקוח שמסר אותו. התאימו אותו להקצאת מנהרה, לרשת LAN מאחורי הלקוח, או לזהות כפולה.
יומן השרת מדפיס MULTI: bad source address from client, מפיל את החבילה, וההפעלה נשארת מחוברת. השילוב הזה מבלבל אנשים שקוראים את ההודעה ככשל אימות. זה לא כך: הלקוח אומת, והחבילה שהגיעה נשאה כתובת מקור פנימית שהשרת לא הצליח לשייך למופע הזה של הלקוח. הבדיקה מתרחשת לפני המסירה, ולכן המנהרה נראית תקינה בזמן ששום דבר שימושי לא עובר דרכה.
מה השרת משווה לפני המסירה
עבור כל חבילה שמגיעה מלקוח, שרת מרחב המשתמש בודק את כתובת המקור בתוך המנהרה ושואל את מצב הניתוב הפנימי שלו לאיזה לקוח הכתובת הזו שייכת. אם הבעלים הוא מופע אחר, או שאין בעלים כלל, החבילה נמחקת והאזהרה נפלטת.
מסירה רגילה דרך ממשק המנהרה אינה מתרחשת לעולם.
הסדר הזה מסביר פרט שמבלבל אנשים: מוני חומת האש של המארח אינם זזים, כי החבילה מעולם לא הגיעה לחומת האש. כוונון סינון הנתיב ההפוך במארח אינו משנה דבר כאן, מכיוון שהדחייה התרחשה בבדיקת השיוך של הדמון עצמו. קראו את ההודעה כהצהרה על בעלות, ואחר כך גלו איזה משלושת המצבים יצר אותה.
שלושה מקורות לכתובת פנימית שאינה תואמת
ייתכן שהלקוח שולח מכתובת שלא הוקצתה לו, מרשת שאיש לא הצהיר שהיא שלו, או משכפול של זהות שכבר יש לה בעלים. שלושתם יוצרים את אותה שורת יומן. הם נבדלים במה שעליכם לשנות. התחילו מהכתובת ומרשימת ההקצאות הנוכחית, ותנו לשני העובדות האלה לבחור את המקרה.
כדי להבחין ביניהם דרושות שתי עובדות: הכתובת שנדחתה ביומן, וההקצאות שהשרת מחשיב כנוכחיות. השנייה זמינה מתצוגת המצב או הניהול של המופע הפעיל, והיא הסמכות היחידה שכדאי להתייעץ איתה, מפני שקובץ תצורה רושם כוונות ולא את המצב הנוכחי.
רשמו את שתיהן לפני שתשנו משהו, ואז סווגו. צילום מסך שנעשה אחר כך אינו תיעוד של המצב שיצר את האזהרה. שמרו גם את חותמת הזמן, מפני שההקצאות נעות בין הפעלות.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
רשת ה-LAN מאחורי לקוח ו-iroute
כאשר לקוח אתר מנתב את הרשת הפרטית שלו, יש להצהיר שהרשת הזו שייכת ללקוח. קובץ ייעודי ללקוח עם רשומת iroute עושה זאת, והרשומה מציינת את הקידומת שהלקוח רשאי לשאת.
נתיב קרנל שמפנה את אותה קידומת למנהרה הוא דרישה נפרדת, והוספתו אינה משנה דבר בבעלות הפנימית של הדמון.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0ודאו שהזהות האפקטיבית תואמת לשם הקובץ, מכיוון שאי-התאמה משמעה שהקובץ אינו נטען לעולם והתסמין זהה לרשומה חסרה. אל תוסיפו iroute רחב כדי להשתיק את האזהרה, מכיוון שזה הופך מקור בלתי צפוי למקור מורשה בלי לענות למה הלקוח שלח אותו. המדריך של OpenVPN 2.6 מתעד את iroute, duplicate-cn ומיפוי זהויות כבקרות נפרדות.
אותה זהות בשני מחשבים
פרופיל שהועתק למחשב נייד שני נושא את אותו תעודה ואת אותו שם נפוץ. בהתאם להגדרות השרת, החיבור החדש יותר יכול להחליף את הישן, והמופע שמחזיק בבעלות מנצח בבדיקת השיוך.
זה גורם לתקלה להיראות לסירוגין ולהופיע רק כששני המכשירים ערים.
התרת שמות נפוצים כפולים מאפשרת לשניהם להתחבר, אבל אינה נותנת להם כתובות סטטיות נפרדות או בעלות נפרדת. אם שני מכשירים חייבים להתקיים יחד, רשמו אותם בנפרד כך שלכל אחד תהיה זהותו וההקצאה שלו. התייחסות להגדרת הכפילות כתיקון לאזהרה הזו משאירה את התעלומה במקומה ומוסיפה שנייה.
הוכיחו שהשיוך השתנה
החילו את התיקון דרך בעל התצורה, ואז חברו מחדש את הלקוח שנפגע כדי שהמדיניות החדשה תיטען.
חזרו על אותו זרם ואמתו שלושה דברים: המקור הפנימי של החבילה, מופע הלקוח שהשרת משייך לה אותה, והתנהגות היעד לאחר מכן.
אם האזהרה נפסקת אבל היישום עדיין נכשל, הבעיה עברה מקום ולא נעלמה. העברה קדימה, כללי חומת אש ונתיב החזרה הם שלבים נפרדים, ומעבר בבדיקת השיוך פירושו רק שהחבילה הורשתה לצאת מהמנהרה.