לקוח VPN עם כתובת LAN אינו על ה-LAN

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

המיתוס: אותה קידומת פירושה אותו מקטע

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

כאשר השרת שולח אל 10.50.0.200, הוא משווה את היעד למסכה שלו, מחליט שהכתובת נמצאת on-link, ומבקש מהמקטע המקומי את כתובת החומרה שבבעלותה. הבקשה הזו יוצאת דרך ממשק ה-Ethernet, ולקוח ה-VPN אינו שם כדי לשמוע אותה.

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

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

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

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

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

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

כיצד proxy ARP מספק את הקפיצה הבאה

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

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

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

קראו בעיון את שמות המצבים של הפלטפורמה. RouterOS מפריד בין proxy-arp ל-local-proxy-arp, והשני מטפל בתעבורה שנכנסת ויוצאת דרך אותו ממשק. אלו אינן איותים הניתנים להחלפה, והפעלת שניהם בלי הבחנה אינה קיצור דרך.

מה proxy ARP לא נותן לכם

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

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

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

השוואה למאגר שמנותב בנפרד

החלופה היא לתת ללקוחות ה-VPN קידומת משלהם ולתת למארחי ה-LAN לנתב אליה. אז השרת שולח תשובות off-link אל השער שלו, השער מנתב את הקידומת אל נקודת הקצה של ה-VPN, ואין צורך כלל בפענוח שכנים במקטע ה-LAN. אלו פחות חלקים נעים מאשר כתובת מושאלת ועוד תשובת proxy.

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

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