אתם חושבים ששינוי שם השרת Pritunl משנה את נקודת הקצה שלו?

שינוי שם של שרת Pritunl משנה תווית במסוף. הוא לא משנה את הכתובת שאליה מתחברים פרופילי הלקוחות, והוא לא יוצר רשומת DNS. הערך שחשוב הוא הכתובת הציבורית של המארח, והיא מקבלת שם באותה קלות כמו כתובת.

השם שאליו מתחברים הלקוחות חי בשדה מארח אחד

Pritunl חושף את נקודת הקצה דרך הגדרת כתובת ציבורית של המארח, שמקבלת כתובת IP ציבורית או שם DNS. שימו שם vpn.example.net, והפרופילים שנוצרים והסנכרון המאומת יעבירו את השם הזה ללקוחות. הרשומה חייבת כבר להתקיים ולהיפתר אל המאזין שמקבל תעבורת VPN; השדה מכריז על יעד, הוא לא מפרסם אותו. שם התצוגה של אובייקט שרת הוא מטא-נתונים מנהליים והוא לעולם לא מגיע לניסיון החיבור של הלקוח.

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

שלושה שדות שנראים דומים ואינם

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

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

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

דחפו את השם החדש ללקוחות שכבר קיימים

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

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

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

קבלו את השינוי בחיבור אמיתי

פתרון שמות הוא המבחן החלש ביותר האפשרי. dig +short vpn.example.net שמחזיר כתובת רק מוכיח שרשומה קיימת.

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

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