מאגר ה-VPN שלך אינו טווח ה-DHCP של ה-LAN: למה זה נשבר

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

שני מקצים, מרחב כתובות אחד

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

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

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

למה הנתב לא מחלק כתובות VPN

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

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

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

החפיפה מתגלה כהתנגשות, לא כרשת איטית

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

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

נתיב החזרה הוא בעיה נפרדת

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

קראו את הנתיב בשני הכיוונים לפני שמשנים משהו. בשער, שאלו באיזה ממשק הגרעין ישתמש לכתובת לקוח; בלקוח, שאלו באיזה נתיב הוא משתמש לכתובת LAN.

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

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

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

תכנונים מגושרים קיימים, אבל צריך לבחור בהם

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

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

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