Linux EHOSTUNREACH עם OpenVPN: איזו קפיצה הבאה נכשלה?

EHOSTUNREACH הוא החלטה מקומית לעתים קרובות כמו כשל מרוחק. הגרעין יכול לדחות מנה מפני שנתיב אומר שהיעד אינו נגיש, מפני שהקפיצה הבאה ב־Ethernet מעולם לא ענתה, או מפני שדוח ICMP host-unreachable הגיע ממקום רחוק יותר לאורך הנתיב. כל מקור חי בטבלה או במטמון אחרים, וכל אחד מתוקן במקום אחר. קראו את הנתיב הנבחר ואת מצב הקפיצה הבאה לפני שנוגעים בצפנים או מתקינים מחדש את המנהרה.

בחרו את הכתובת ומרחב השמות שבהם הלקוח באמת משתמש

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

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

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

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

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

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

סוגי הנתיבים אינם ניתנים להחלפה. Blackhole זורק את המנה בלי שגיאה לשולח, prohibit מחזיר EACCES, ו־unreachable מחזיר EHOSTUNREACH. לכן עוזר VPN שמתקין נתיב בולען בזמן התחברות מחדש יכול לייצר פרץ של שגיאות host-unreachable שנעלמות כשהמנהרה עולה, בעוד נתיב blackhole היה יוצר במקומן פסקי זמן שקטים.

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

שכן מת מייצר את אותה שגיאה ב־Ethernet

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

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

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

דוחות מרוחקים ושגיאות UDP אסינכרוניות

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

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

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

הפרידו את השכבות לפני שינוי ההצפנה

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

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

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