שתפו חיבור VPN אחד עם כל מכשיר ב-LAN שלכם

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

למה הפניית מכשירים אל המארח נכשלת

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

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

הפעילו העברה ותרגום במארח

שני שינויים במארח המחובר מכסים את שני החלקים הראשונים: הפעילו העברת IPv4 ותרגמו תעבורת LAN אל ממשק המנהרה.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

שמרו את ערך sysctl בקובץ תחת /etc/sysctl.d, ובדקו שוב את כלל MASQUERADE לאחר אתחול, משום שחזיתות חומת אש עשויות לרוקן שרשראות מותאמות. ב-Windows תכונת השיתוף מבצעת את שני השלבים, אך היא גם מקצה מחדש את מתאם ה-LAN לתת-רשת קבועה ומוחקת את השער שלו, מה ששובר כתובות סטטיות והעברת פורטים. שחזרו את הנתיב של הנתב אל המארח בכתובתו החדשה לפני שתסיקו שהשיתוף נכשל. לאחר מכן התבוננו במוני הכללים עולים כשמכשיר שני שולח תעבורה.

תנו ל-LAN נתיב ששורד אתחולים

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

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

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

שימו לב ל-MTU לפני שאתם מאשימים את המנהרה

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

ping -M do -s 1400 10.8.0.5

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

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