האם שם המארח של שער ה-Pi מעדכן מסלולים סטטיים מעצמו?

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

תשובת ה-DNS והמסלול הם אובייקטים שונים

נניח שה-Pi שלך עונה ל-vpn-gw.lan ומעביר 10.44.0.0/16 אל תוך מנהרה. לקוחות ב-192.168.30.0/24 מגיעים אליו דרך מסלול סטטי. כשהכתובת של ה-Pi עברה מ-192.168.30.4 ל-192.168.30.11, הרשומה עקבה בתוך ה-TTL שלה והמסלולים לא.

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

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

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

מה נשאר בטבלה לאחר שהפקודה יוצאת

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

לכן ip route add 10.44.0.0/16 via vpn-gw.lan יכול להיראות כאילו הוא עובד. הכלי מפענח את השם בזמן שהפקודה רצה, כותב את הכתובת שהתקבלה, ושוכח את השם לגמרי. הריצו ip route show 10.44.0.0/16 אחר כך ותקבלו חזרה כתובת מפורשת.

כדאי להכיר את ההתנהגות הזו לפני שמאשימים את המנהרה.

כלים שמפענחים עבורך שם, ומתי

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

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

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

נעצו את הכתובת או הריצו את המעדכן בעצמכם

עבור LAN קטן, הזמנה בשרת ה-DHCP היא התיקון הזול ביותר. בחרו כתובת מחוץ למאגר הדינמי, קשרו אותה לכתובת ה-MAC של ה-Pi, ואשרו אותה עם ip -4 addr show dev eth0 לאחר חידוש החכירה הבא. ואז כוונו פעם אחת את הקפיצה הבאה של הלקוחות לכתובת הזו. עכשיו יש לכם שער יציב ורשומה שמתארת אותו, וזה הסדר שבו היחסים באמת עובדים.

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

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

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

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