WireGuard עובד ברשת סלולרית אבל לא באותה רשת Wi-Fi
בקשה מתוך ה-LAN לכתובת הציבורית של הנתב עוברת מסלול שונה מבקשה שמגיעה מרשת סלולרית. בדקו מבחוץ, ואז בחרו מסלול מקומי.
המנהרה עולה על רשת סלולרית ואז נשארת על מצב מתחבר בבית, עם אותו פרופיל, אותו מפתח עמית ובלי שום שינוי תצורה בדרך. ההבדל הוא במסלול: בקשה מתוך ה-LAN לכתובת הציבורית של הנתב אינה אותה נסיעה כמו בקשה שמגיעה מהאינטרנט. רוב שערי הבית או שאינם מיישמים את מסלול החזרה, או שמיישמים אותו רק עבור פרוטוקולים מסוימים. זה גורם לתסמין להיראות כמו מפתח שבור כששום דבר במפתח לא זז. קבעו איזה מסלול נכשל לפני שנוגעים במפתח, בהעברת פורט או בפרופיל לקוח.
כתובת אחת, שני מסלולים שונים
מבחוץ, חבילה מגיעה לכתובת הציבורית של הנתב וכלל העברת פורט מוסר אותה למאזין WireGuard במארח הפנימי. מבפנים, הלקוח מחייג לאותה כתובת ציבורית, כך שהחבילה יוצאת מהלקוח, מגיעה לנתב וצריכה להיות מוחזרת לכיוון ה-LAN. בנקודת החזרה הזו שני המסלולים מתפצלים, כי הנתב חייב לתרגם זרימה שיוצאת וחוזרת לאותו ממשק. יישומים רבים מפילים אותה במקום לתרגם אותה, והלקוח ממתין לתשובה של לחיצת יד שמעולם לא נשלחה.
ההתנהגות הזו מכונה בדרך כלל NAT loopback או hairpinning, והיא שייכת לנתב ולא ל-WireGuard; RFC 4787 מפרט את מקרי התרגום שבהם שער עשוי לתמוך בה או לא. WireGuard עצמו אינו מביע דעה על המסלול, כי הוא רואה רק חבילות שמגיעות לממשק שלו. כשהנתב מפיל את הזרימה, הדמון לא מקבל דבר, הלקוח מדווח על פסק זמן בלחיצת יד והיומן של השרת נשאר ריק. יומן ריק הוא אפוא רמז להיכן נעצרה החבילה, ולא הוכחה שהשרת נפל. זו גם הסיבה שהתקנה מחדש לא משנה דבר.
גם ההפך חשוב: יומן שרת שמראה ניסיון לחיצת יד מכתובת ה-LAN מוכיח שהחבילה הגיעה ושהמסלול תקין, מה שמעביר את הבדיקה למפתחות ולכתובות מורשות. קראו את היומן לפי מה שהוא מוכיח, לא לפי מה שקיוויתם לראות.
שחזרו את התנאי לפני שאתם משנים משהו
בדקו מרשת חיצונית מורשית עם אותו מכשיר ואותו פרופיל, ואז חזרו על הבדיקה בתוך ה-LAN בלי לשנות דבר. לחיצת יד שהושלמה בחוץ ולקוח שבפנים לא יוצא מהמכשיר משחזרים את התנאי במקום לנחש אותו. שתי הבדיקות חייבות להשתמש באותו פרופיל, אחרת ההשוואה לא מוכיחה דבר.
לאחר מכן בדקו למה מתפענח שם נקודת הקצה במכשיר הזה. שלוש הפקודות האלה מראות גם לאיזו כתובת הלקוח באמת חייג:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netהפקודה הראשונה מדווחת באיזו נקודת קצה הממשק משתמש כרגע, ושתי האחרות מראות למה מתפענח השם במחשב הזה. לקוח שמחייג לכתובת ציבורית בעודו יושב על אותה רשת של השרת מפעיל את מסלול ה-hairpin. לקוח שמחייג לכתובת ה-LAN אינו עושה זאת, וכשל שם שייך לבדיקה אחרת. ההבחנה הזו קובעת אם הפרק הבא רלוונטי בכלל.
דרכים נתמכות להגיע לשרת קרוב
הסידור הנקי ביותר הוא תשובת split-horizon: השם הציבורי מתפענח לכתובת הציבורית עבור האינטרנט ולכתובת ה-LAN של השרת עבור לקוחות בפנים. הפרופיל שומר על שם נקודת קצה אחד והפותר בוחר את המסלול. זה דורש שליטה בתשובת ה-DNS הפנימית, שנתב ביתי בדרך כלל מספק וארגון יכול לסדר בכוונה. בלי השליטה הזו, האפשרויות שנותרו הן תכונה של הנתב או פרופיל שני.
תכונת הנתב היא החזרה: השער מתרגם את הזרימה מבפנים החוצה ושולח אותה חזרה פנימה. במקום שבו זה עובד אין צורך בשינוי בצד הלקוח, ובמקום שבו זה לא עובד שום הגדרה של לקוח לא תציל. בדקו זאת על ידי התבוננות ביומן השרת בזמן ניסיון פנימי, ולא בקריאת רשימת התכונות של הנתב.
שינוי הפרופיל לכתובת פרטית הוא אבחון, לא תכנון. הוא מוכיח שהשרת עונה ב-LAN, והוא שובר את אותו פרופיל ברגע שהמחשב הנייד יוצא מהבית.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
השאירו את הפרופיל שמיש מחוץ לבית
בכל מסלול שתבחרו, אל תיגעו בבדיקת הזהות. כתובת נקודת הקצה אינה זהות העמית, ושינוי כתובת אינו מצדיק בשום פנים קבלת מפתח ציבורי לא קשור שמקרה עונה. WireGuard מאמת לפי מפתח, כך שמארח שגוי מכשיל את לחיצת היד ולא נותן גישה למשהו בלתי צפוי.
אם הכתובת הציבורית זזה, DNS דינמי הוא מה ששומר על השם שימושי, והתנהגות הרענון של הלקוח קובעת כמה מהר השינוי נכנס לתוקף. בדקו זאת מבחוץ לאחר שינוי כתובת, כי מקרה ה-LAN לא יכול לאמת אותו. שימו לב לפותר ששומר את התשובה הישנה בזיכרון מעבר לתוקף הרשומה. שם שעדיין מצביע לכתובת הקודמת נראה בדיוק כמו שרת שנפל.
רשמו איזה שם הפרופיל משתמש בו ולמה הוא מתפענח בכל צד של הגבול. פרופיל שתלוי בתכונת נתב שאיש לא תיעד הוא קריאת תמיכה שממתינה לעדכון הקושחה הבא. אותה הערה היא גם מה שמגלה לאדם הבא אם כשל פנימי הוא מקרה ה-hairpin הידוע או משהו חדש.