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

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

הפרידו בין לחיצת היד לזרימה המועברת

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

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

קראו את כלל המדיניות, לא את טבלת ברירת המחדל

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

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

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

בדקו את הסימון והתרגום יחד

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

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

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

שימו לב איזה ממשק נושא את התגובה

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

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

שנו דבר אחד עם דרך חזרה

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

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

מאמרים קשורים