לחיצת היד של WireGuard עובדת, השירות לא

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

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

לחיצת היד מוכיחה רק את המנהרה

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

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

קראו את המאזין ואת המסלול

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

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

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

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

החילו כללים לקלט מקומי, לא להעברה קדימה

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

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

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

הפרידו בין כשלי שם, גודל וזהות

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

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

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