החלפת ספקי VPN: לתכנן את שם המארח, לא רק את כתובת ה-IP
רשומת DNS חדשה אינה מעבירה הפעלות קיימות. תכננו מי שולט בשם, מתי כל לקוח מפענח אותו וכיצד תפרישו את נקודת הקצה הישנה.
רשומת ה-DNS שלכם תקינה, התחליף בריא, ובכל זאת כמה לקוחות מבלים שעות בחיוג לכתובת הישנה. מעטים נכשלים מיד מול שם שמתפענח ואינו עונה לעולם. שתי התוצאות נובעות מפער אחד: שם מארח משנה מה לקוח מחפש, לא מתי הוא מחפש אותו, ולא במה הוא בוטח כשהתשובה מגיעה.
התסמין: רשומה תקינה, מנהרות מיושנות
פרופיל ששומר שם אינו לקוח שממשיך לפענח אותו. רוב הלקוחות מפענחים אותו פעם אחת, בעת החלת התצורה או כשהמנהרה עולה, ואז משתמשים שוב באותה כתובת עד שההפעלה מסתיימת. TTL ארוך שנערם על כך הוא הסיבה לכך שהמעבר חייב להיות מתוכנן סביב התחברויות מחדש ולא סביב עריכת ה-DNS.
אף אחת משתי ההתנהגויות אינה תקלה, וזה בדיוק מה שהופך את התסמין למבלבל. הלקוח עובד עם תשובה שקיבל קודם, ושום דבר בצד השרת לא מראה איזו תשובה זו הייתה. תכננו את ההתחברות מחדש בתוך חלון התחזוקה וספרו למשתמשים מה יראו, או הקדישו את החלון למענה לפניות. תור של דיווחים זהים הוא התוצאה הרגילה.
מי שולט בשם, ומה הלקוח מאמת
השליטה באזור קובעת כמה מהר הגירה יכולה להתקדם. החזיקו את הרשומה אצל רשם שאתם יכולים להיכנס אליו, ורשמו מי עוד יכול לשנות אותה.
אמון אינו הולך אחרי השם. לקוח מבוסס TLS עשוי לבדוק זהות תעודה או שם מוצמד, בעוד WireGuard מאמת את המפתח הציבורי של העמית ומתעלם לחלוטין משם המארח. ההבדל הזה קובע אם עריכת DNS מספיקה או שכל פרופיל צריך טביעת אצבע חדשה. שינוי רשומה לא אמור אי פעם להרשות נקודת קצה שאיש לא אישר.
הרחיקו גישה ניהולית וגישת שחזור משם הלקוח הציבורי. אובדן חשבון אחסון לא אמור לעלות לכם גם ברשומה שמפנה לקוחות. אחסנו את נתיב השחזור במקום שאינו תלוי בספק שאתם עוזבים.
מתי כל לקוח קורא את השם מחדש
תזמון הפענוח הוא תכונה של כל לקוח בנפרד, לכן בדקו את המימוש שאתם באמת מספקים לפני שאתם מבטיחים חלון מעבר. wg-quick מפענח את נקודת הקצה כשהממשק עולה ושומר על הכתובת עד שהמנהרה מופעלת מחדש. לקוח OpenVPN מחפש את השם כשהוא מתחבר, והאם יסתכל שוב בהתחברות מחדש תלוי באפשרויות שלו.
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
לקוחות ניידים הם ההפתעה הרגילה, כי הם עשויים להחזיק כתובת מפוענחת דרך שינה או שינוי רשת. פרסמו רשומות A ו-AAAA רק אם התחליף עונה בשתי המשפחות. כתובת שעונה במשפחה אחת אינה מוכיחה דבר על השנייה, ורשומת AAAA מתה מוסיפה פסק זמן לכל ניסיון. תעדו את התנהגות הפענוח לכל לקוח שאתם תומכים בו, ואז בדקו במכשירים שאנשים באמת משתמשים בהם.
התחברות מחדש היא פעולת משתמש ברוב הלקוחות, והשרת אינו יכול לכפות אותה. הכניסו את השלב הזה להערת התחזוקה, עם שורה על מה המשתמש יראה כשהוא יקרה.
עברו על סמך ראיות, ואז הפרישו את נקודת הקצה הישנה
לפני המעבר, הוכיחו כל שכבה בתחליף: המאזין עונה, חומת האש מעבירה את הפורט, המסלולים חוזרים נכון, השם מתפענח לכתובת החדשה, וזהות מוכרת מתקבלת. מאזין שמקבל חיבור אינו אותו דבר כמו זה שמשלים לחיצת יד, לכן בדקו את לחיצת היד ולא את הפורט. החזיקו את רשימת הביטול הנוכחית לצד התצורה, כי גיבוי משוחזר יוצר מחדש את רשימת העמיתים כפי שהייתה ויפתח מחדש גישה שכבר סגרתם. רשמו באיזו זהות בדקתם, כי «זה עובד» אינה ראיה שמישהו יכול לחזור עליה.
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesבמהלך המעבר, עקבו אחרי ניסיונות התחברות בשתי נקודות הקצה עבור אותה זהות. לקוח שעדיין מאמת את עצמו מול הכתובת הישנה הוא פרופיל או תשובה שמורה במטמון שלא זזה מעולם. הפרישו את נקודת הקצה הישנה לפי תוכנית מתוארכת, כי שני שירותים שמקבלים זהות אחת משאירים שתי דלתות פתוחות.
מבחן המעבר הוא הפעלת יישום דרך נקודת הקצה החדשה, לא פינג. ברגע שההפעלה הזו עובדת ונקודת הקצה הישנה אינה רושמת ניסיונות מורשים במחזור התחברות מחדש מלא, המעבר הושלם.