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

מה מנהרת ראוטר באמת מכסה

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

הכיסוי מותנה בדרכים שמפתיעות אנשים. רשת אורחים או SSID שני עם מדיניות משלו הולך בדרך שמגדירה המדיניות ההיא, ולא המנהרה. נתיב IPv6 יכול לעקוף מנהרה שנושאת רק IPv4. מכשיר עם אפליקציית VPN משלו או פותר מוצפן משלו מתעלם מהראוטר לגמרי. והתעבורה של הראוטר עצמו, כולל עדכונים ו־DNS, הולכת לפי מדיניות היציאה שלו, שהיא נתיב שונה מהתעבורה המועברת של ה־LAN.

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

היכן לקוח בכל מכשיר מנצח

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

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

תמיכת פרוטוקולים מכריעה יותר מקרים מהעדפה

ראוטרים לצרכנים חושפים רק את הפרוטוקולים שהספק סיפק. ראוטר עם PPTP, L2TP או IPsec פשוט אינו יכול להתחבר לספק שמפרסם רק פרופילי OpenVPN או WireGuard, ושום תצורה לא משנה זאת. האפשרויות הכנות הן ספק שמדבר פרוטוקול נתמך, ראוטר עם OpenWrt או קושחה אחרת עם הלקוח שאתם צריכים, או לקוח בכל מכשיר.

המקרה ההפוך נפוץ באותה מידה: ראוטר שמסוגל OpenVPN אינו יכול להשתמש בספק ששירותו תלוי בלקוח קנייני ובתעלולי הניתוב שלו עצמו. קראו את עמוד הפרוטוקולים הנתמכים של הספק לפני רכישת חומרה ובדקו את גרסת הקושחה, כי «תומך ב־WireGuard» בעמוד מוצר פירושו לעתים קרובות דור קושחה מסוים.

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

האפשרות השלישית: מכונה כשער

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

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

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

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

פורטים נכנסים, DNS והכשל המשותף

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

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

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

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