איך לשחזר שרת VPN בלי לשכפל זהויות

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

גיבוי מחזיר קבצים, לא סמכות

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

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

זהות השרת וזהות הלקוח נכשלות בדרכים שונות

ב-WireGuard זהות השרת היא המפתח הפרטי ב-wg0.conf, כך שהעתקת הקובץ הזה לשרת שני שנגיש יוצרת שני שרתים עם אותה זהות ובלי ידיעה זה על זה. כל אחד מחזיק רשימת עמיתים משלו. הסירו עמית בשרת החדש והשרת הישן עדיין מקבל אותו; בדקו wg show באחד ותראו חצי מהאמת. גם הלקוחות לא עוברים מעצמם: פרופיל נושא Endpoint אחד, כך שמכשיר ממשיך לדבר עם הכתובת שאליה הוגדר, שאולי היא השרת שרציתם להוציא משירות.

OpenVPN משתכפל באותה שכבה עם אישור שרת, המפתח הפרטי שלו ומפתח סטטי מסוג tls-auth או tls-crypt. העתיקו את שלושתם ולקוח לא יוכל להבדיל בין המופעים; אם שניהם נגישים, התחברות מחדש עשויה לנחות על כל אחד מהם, וכל קובץ לוג מספר סיפור חלקי. רשות האישורים היא העותק העמוק יותר. עץ easy-rsa משוחזר הוא מקור אמת שני שיכול להנפיק אישור תקף לכל שם שתיתנו לו.

גם לקוחות משתכפלים, בדרך כלל בזמן ההעברה עצמה. העתקת פרופיל למכשיר חלופי «רק כדי לבדוק» יוצרת מכשיר שני עם אותו מפתח ואותו שם נפוץ. עם duplicate-cn שני המושבים יכולים לעמוד בו-זמנית, והקצאת כתובת סטטית ב-ccd או ב-ifconfig-pool-persist עשויה להתנגש במכשיר המקורי. אלה שתי מכונות שלובשות זהות אחת, ושום דבר בתצורת השרת לא מבחין ביניהן.

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

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

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

ss -lunp | grep -E ':51820|:1194'
wg show wg0
wg pubkey < /etc/wireguard/server.key

קודם התאימו עמיתים, ביטולים וכתובות

רשמו מה השחזור תובע מול מה שמורשה כעת. ב-WireGuard הפקודה wg show wg0 נותנת לכל עמית מפתח, נקודת קצה, לחיצת היד האחרונה ומוני העברה, מספיק כדי לזהות מכשיר שכבר אינו שלכם. הסירו אותו בזמן אמת עם wg set wg0 peer <key> remove, ואז ערכו גם את התצורה, אחרת העמית יחזור בהפעלה הבאה. wg show wg0 allowed-ips חושף את הבעיה השנייה: שני עמיתים על כתובת אחת, או כתובת שכבר הקציתם מחדש.

ב-OpenVPN רשימת הביטולים היא קובץ עם תאריך, ושחזור יכול להחזיר ישנה. בדקו אותה לפני שלקוחות מתחברים:

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
grep -E 'crl-verify|reneg-sec' /etc/openvpn/server.conf

אם העדכון האחרון קודם לביטול, השרת עדיין מכבד אישור שביטלתם. OpenVPN 2.4 ואילך קורא מחדש את קובץ ה-CRL לכל חיבור חדש, כך שהחלפת הקובץ עוצרת מושבים חדשים, אבל מנהרות קיימות נמשכות עד למשא ומתן מחדש; ברירת המחדל של reneg-sec היא 3600 שניות, והורדתה או הפעלה מחדש של השירות היא מה שנותן לכם את השינוי עכשיו. גרסאות ישנות יותר אולי לא קוראות את הקובץ באמינות דומה, אז הפעילו מחדש כשאינכם יכולים לאמת את התנהגות הגרסה. המדריך של wg(8) מכסה את הסרת העמית ותחביר allowed-ips שבו השתמשתם לעיל.

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

אמתו עם לקוח שביטלתם

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

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