מנהרת WireGuard ביתית זקוקה לנתיב חזרה מה-LAN

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

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

החליטו מי מעביר ומי מסתיים

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

כתבו את תוכנית הכתובות לפני יצירת הממשק. נתב 192.168.50.1, שער 192.168.50.10, שירות 192.168.50.20, מנהרה 10.77.0.0/24 עם שער .1 ומחשב נייד .2. טווח המנהרה לא יחפוף לרשת שהמחשב הנייד כבר מגיע אליה, אחרת היעדים נעשים דו-משמעיים. NAT של ספק או נתב במעלה הזרם עלולים לחסום גישה נכנסת, ושום העברת פורט מקומית לא מתקנת זאת.

החליפו מפתחות, ואז קבעו את גודל AllowedIPs

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

[Interface]
Address = 10.77.0.2/32
PrivateKey = LAPTOP_PRIVATE_KEY_BASE64

[Peer]
PublicKey = HOME_PUBLIC_KEY_BASE64
Endpoint = home-vpn.example.com:51820
AllowedIPs = 192.168.50.0/24, 10.77.0.1/32

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

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

התכנון הזה שומר על המקור 10.77.0.2 של המחשב הנייד במקום להסוות אותו כשער, ולכן התקני הבית חייבים לדעת איך להשיב לו. הוסיפו נתיב סטטי בנתב הביתי עבור 10.77.0.0/24 עם 192.168.50.10 כקפיצה הבאה, וקראו מה wg-quick גוזר מ-AllowedIPs בתיעוד הרשמי שלו. בלי הנתיב הזה, לחיצת יד שהושלמה מתקיימת לצד תגובות יישום שלעולם לא מגיעות.

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

אפשרו שירות אחד, לא את תת-הרשת

הפעילו העברת IPv4 בשער ושמרו על שלושה תפקידי חומת אש בנפרד: לאפשר את מאזין ה-WireGuard, להעביר את מקור המחשב הנייד רק אל 192.168.50.20, ולהשאיר את שאר רשת הבית סגורה לאותו peer. שלבו את הכללים במנהל חומת האש שכבר בשימוש במקום לרוקן אותו. נתיב לכל קידומת הבית אינו הרשאה להשתמש בכל התקן שבתוכה.

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

בדקו מבחוץ, ואז פרשו בצורה נקייה

העלו את הפרופילים דרך הבעלים שלהם, אשרו את לחיצת היד, ואז הפעילו את היישום המיועד מרשת חיצונית מאושרת ובדקו את התגובה. נסו שירות ביתי שחייב להישאר חסום, כי כלל מתירני אינו נראה עד שמשהו משתמש בו. ב-HTTPS השתמשו בשם שעל האישור ותנו לאימות לרוץ; הקלדת הכתובת הגולמית ומעבר דרך האזהרה לא מוכיחים דבר על הנתיב. PersistentKeepalive הוא רשות: הוא עוזר ל-peer הכבול ל-NAT לאחר זמן סרק, אך הוא אינו נתיב חסר או תיקון הרשאה.

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

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