איך לתת לרשת LAN בדיקה אחת יציאת WireGuard משלה

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

החליטו היכן היציאה גרה

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

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

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

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

אשרו שלושה דברים מול המפעיל: העמית מאשר את כתובת המנהרה שלכם, הוא מעביר IPv4 הלאה במקום להסתיים אצלו, והוא מחיל NAT יוצא. בלי הראשון החבילות שלכם מגיעות ונעלמות. בלי השלישי הן יוצאות עם מקור פרטי ומתות בצעד הבא. אחר כך בדקו ש wg-quick לא מתקין מסלול ברירת מחדל משלו, וזה מה ש Table = off מונע; ההגדרה הזאת מדכאת יצירת מסלולים, לא את בדיקות AllowedIPs של העמית ולא את הטיפול שלו ב DNS.

שני אובייקטי מדיניות עושים את ההיגוי

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

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

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

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

סגרו את פער הנסיגה לפני שתפתחו אותו

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

המסנן משלים את התמונה. בוו forward קבלו את הכיוון מ LAN למנהרה עבור קידומת הבדיקה ואת כיוון החזרה המבוסס, ואז השליכו את כל השאר; ה NAT של אותה קידומת אל ממשק המנהרה הולך ב postrouting. דווקא השארת policy drop על שרשרת ההעברה היא מה שהופך מסלול חסר לדממה במקום לדליפה. סינון נתיב הפוך דורש מצב רופף בממשק המנהרה, כי למקור ציבורי שמגיע לאחר פירוק מעטפת יש את נתיב ההפוך הטוב ביותר בצד ה WAN. לינוקס לוקח את הגבוה מבין הערך all והערך לכל ממשק, ולכן הגדרת ממשק המנהרה אינה אותו דבר כמו החלשת האימות בכל מקום.

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

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

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