כתובת VPN מול חכירת DHCP ברשת המקומית: מי מקצה את כתובת ה-IP של המנהרה?

חברו את הלקוח והסתכלו על המתאם ולא על סמל ה-Wi-Fi. כתובת כמו 10.80.0.14 יכולה לשבת על מנהרה בעוד שאף שרת DHCP ברשת המשרד לא רשם אי פעם את החכירה הזו. התהליך שבחר את המספר הוא שקובע היכן מתחילה חקירת התקלה.

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

לקרוא את כתובת המנהרה מצד הלקוח

Windows מציג את ההבדל אם קוראים את כל הבלוק ולא את השורה הראשונה. ipconfig /all מדפיס תיאור מתאם, כתובת פיזית ושורת DHCP. מתאם חיוג PPP או IKEv2 מדווח בדרך כלל ש-DHCP מושבת, משום שהחיבור ניהל משא ומתן על כתובתו בזמן החיוג במקום לחכור אותה משרת ברשת המקומית. מתאם מנהרה שבו DHCP מופעל אינו שגרתי וראוי לבדיקה נפרדת.

Linux מפצל את אותו מידע בין שני כלים. ip -4 addr show dev tun0 נותן את הכתובת ואת אורך הקידומת. nmcli -f IP4 connection show work מגלה אם הערך הגיע מפרופיל החיבור, מחילופי DHCP על הקישור או מתצורה שנדחפה. WireGuard הוא המקרה הבהיר ביותר, מפני ש-wg-quick מיישם את שורת Address מקובץ התצורה כשהממשק מופיע, ואף עמית אינו מקצה דבר בזמן ההתחברות.

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

מה נושא מטען התצורה של IKEv2

ל-IKEv2 יש מנגנון ייעודי למשימה הזו. מטען התצורה המתואר ב־RFC 7296, סעיף 3.15.1 נושא מאפיינים כמו INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS ועמיתיהם מסוג IPv6. הלקוח שולח מאפיין בעל אורך אפס כשאין לו העדפה, והמשיב מחזיר את הערך שבו הוא רוצה להשתמש. החליפין הזה עובר בתוך IKE_AUTH, שכבר מוצפן, ולכן שום שידור DHCP לא חוצה את המנהרה.

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

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

איפה טווח ה-DHCP של הרשת המקומית ומאגר ה-VPN מתנגשים

הצרה מתחילה כששני המקצים מצביעים על אותו טווח. שרת DHCP עבור 10.20.30.0/24 אינו יודע דבר על מאגר VPN שהוגדר עבור 10.20.30.128/25, ולכן שום דבר אינו מונע ממנו לחכור את 10.20.30.140 למדפסת בזמן שהשער מוסר את אותה כתובת ללקוח מרוחק. ההתנגשות נשארת שקטה ימים ואז עולה לפני השטח כשכפילות לסירוגין.

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

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

לוודא איזה תהליך מחזיק בכתובת

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

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

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

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