הקפיצה הבאה בנתיב VPN: מדוע השער חייב להיות נגיש מקומית

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

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

שתי כתובות, נתיב אחד

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

לכן הבדיקה הראשונה אינה «האם השער פועל» אלא «האם השער בקישור הזה». תת-הרשת של המחשב הנייד עצמו, רשומת ה-ARP או השכן שלו, והממשק שבנתיב — כולם חייבים להסכים. כתובת שקיימת רק בתוך 10.70.0.0/24 יכולה להיות היעד של נתיב שני, אבל לעולם לא ה-via של הראשון.

למה מחייבת הקפיצה הבאה את השער

התקנת הנתיב במחשב הנייד קובעת רק את המסירה הראשונה. לאחר מכן השער זקוק לנתיב משלו: העברה מופעלת, נתיב מנהרה אל 10.70.0.0/24, וכל מדיניות גישה שקובעת מי רשאי להשתמש בו. ב-Linux זה net.ipv4.ip_forward=1 ועוד נתיב מנהרה; חומת אש שלפניו זקוקה לכלל שמתיר את הזרימה המועברת.

כיוון החזרה הוא החלק שאנשים שוכחים. לצד המרוחק חייב להיות נתיב חזרה אל 192.168.20.0/24, או שהתכנון חייב לתרגם את המקור של המחשב הנייד למשהו שהצד המרוחק מכיר. ping שעובד מהשער מוכיח שהשער מצליח להגיע לרשת המרוחקת; הוא לא אומר דבר על כך אם החבילות של המחשב הנייד שורדות את הדרך חזרה.

אמתו את החיפוש מהמארח ששולח

שאלו את הגרעין איזו קפיצה הבאה הוא היה בוחר, וקראו את הממשק בתשובה:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

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

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

אל תשתמשו ב-onlink כדי לזייף נגישות

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

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

מנהרות נקודה-לנקודה אינן Ethernet

התקן מנהרה לא מבצע ARP ולעתים קרובות אין לו תת-רשת משמעותית של שכנים. הנתיבים שלו נראים לעתים קרובות כמו 10.70.0.0/24 dev tun0, בלי שום via, מפני שהעמית הוא נקודת הקצה האחרת היחידה. העתקת via בסגנון LAN אל אותה טבלה יוצרת נתיב שהגרעין עשוי לדחות או, גרוע מכך, כזה שמצביע על כתובת שהעמית לעולם אינו עונה לה.

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

הוסיפו, אשרו, החזירו לאחור

כל השינוי הוא שלוש פקודות ובדיקה אחת, ויש לכתוב אותו בסדר הזה:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

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