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

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

טענו את האתר פעם אחת כשהמנהרה פעילה, ואז הסתכלו בכתובת העמית שהדפדפן באמת התחבר אליה. בלינוקס, ss -tunp מציג את הכתובת המרוחקת של כל socket פתוח, ו- dig +short על אותו שם מראה מה הפותר החזיר. שמרו את שני המספרים מולכם.

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

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

שימו מסלול מארח אחד על הלקוח

נניח שהממשק נקרא home-wg ושהנתב של ה-LAN נמצא ב-192.168.1.1. NetworkManager לוקח מסלול שהשער שלו הוא הנתב הזה וששאורך הקידומת מכסה את כל 32 הביטים, והליבה מעדיפה אותו כי הקידומת הארוכה ביותר מנצחת.

nmcli connection modify home-wg +ipv4.routes "198.51.100.20/32 192.168.1.1"
nmcli connection up home-wg
ip route get 198.51.100.20

השער חייב להיות נגיש בלי המנהרה; הפניית הקפיצה הבאה לכתובת המנהרה מחמיצה את המטרה, כי החבילה הייתה נכנסת שוב לממשק שאתם מנסים להימנע ממנו. אחרי שהחיבור עולה שוב, ip route get עבור החריגה אמור להדפיס את שער ה-LAN, ואותה פקודה עבור פותר ציבורי אמורה עדיין להדפיס את התקן המנהרה.

לפרופיל wg-quick אין שדה מסלולים, ולכן אותה חריגה חיה בשורה PostUp שמוסיפה את מסלול המארח לטבלה הראשית עם ממשק ה-LAN כמכשיר שלו. הורידו והעלו את הממשק לאחר העריכה, כי ממשק פועל לא קורא מחדש את הקובץ שלו לעולם. כללי ה-fwmark ש-wg-quick מתקין מנווטים רק את החבילות העטופות שלו עצמו, לכן תעבורת דפדפן רגילה עדיין עוקבת אחרי הטבלה הראשית ומוצאת את ה-/32 שלכם.

מתג ההריגה הוא הדבר הבא שחוסם את זה

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

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

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

ה-DNS מחליט לאיזו כתובת הדפדפן מחייג

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

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

אותה חריגה על הנתב, פעם אחת, לכל מכשיר

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

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

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

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