למה הזמנת DHCP אינה IP קבוע לשרת ה-VPN שלך

העברתי קופסת VPN ביתית מ-Wi-Fi ל-Ethernet והכתובת ה״קבועה״ שלה השתנתה באותו ערב. שום דבר בנתב לא היה שבור. ההזמנה התאימה למתאם האלחוטי, והמתאם הזה כבר לא היה בנתיב.

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

הזמנה מתאימה ללקוח, לא להתקן

ב-DHCPv4 ההזמנה מבוססת על כתובת החומרה של הלקוח; ב-DHCPv6 היא מבוססת על DUID שהלקוח אמור לשמור. השדה hostname הוא תווית לבני אדם. מה שהנתב באמת משווה הוא המזהה שמגיע בבקשה.

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

OpenWrt מציג את הצורה בבירור. בלוק config host אחד ב-/etc/config/dhcp קושר שם, MAC וכתובת יחד, וכן התיעוד של חכירות סטטיות מסביר איך הרשומה הזו מתנהגת עם המאגר. נתבים אחרים מסתירים את אותם שלושה שדות מאחורי תוויות שונות.

איפה ההתאמה נופלת בשקט

החלפת חומרה היא המקרה הנפוץ. החליפו את כרטיס הרשת, או העבירו את המכונה בין Ethernet ל-Wi-Fi, והכתובת שהנתב רואה משתנה איתה. ההזמנה הישנה נשארת ברשימה, ועדיין נראית נכונה.

התקנה מחדש היא המקרה השני, והיא נושכת הכי חזק ב-IPv6. התקנה חדשה יכולה ליצור DUID חדש בזמן שחכירת ה-IPv4 הישנה עדיין תקפה, כך שכתובת ה-v4 שורדת זמן מה והרשומה של v6 מפסיקה לחול בלי שום עריכה גלויה.

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

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

תצורה בצד המארח ומה היא עולה

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

המחיר הוא בעלות. עכשיו אתם מספקים את הקידומת, את השער ואת הפותרים, ואתם חייבים להחזיק את הכתובת מחוץ למאגר הדינמי בעצמכם. ב-Ubuntu עם netplan, זה נישא ב-/etc/netplan/01-vpn.yaml:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

משתמשי NetworkManager מגיעים לאותו מצב עם nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, ואז nmcli con up "Wired connection 1". החילו netplan עם netplan try בניסיון הראשון ולא עם netplan apply; שער שהוקלד בטעות מוריד את הקופסה מהרשת ומשאיר אתכם לחפש קונסולה.

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

כתובת LAN יציבה אינה נקודת קצה ציבורית

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

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

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

בדקו את המסלול לפי הסדר שבו הוא נשבר

התחילו בנתב. השוו את הרשומה בטבלת החכירות ליעד של ההזמנה; אם השרת לקח כתובת מהמאגר, המזהה שגוי, ו-ip link show על המארח נותן לכם את הערך להשוואה.

אחר כך המארח. ip -4 addr show eth0 אמור לדווח את הכתובת והקידומת הצפויות. כתובת שנייה על אותו ממשק בדרך כלל פירושה ש-DHCP עדיין רץ לצד התצורה הסטטית שלכם.

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

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

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