העברת שרת VPN לכתובת IP ציבורית חדשה: מה לבדוק קודם
החלפה במקום ומעבר מקביל נשברים במקומות שונים. עברו על תצורות, NAT ותעודות, ואז בדקו כיצד כל לקוח מפענח את השם.
הקצאה מחדש של כתובת אורכת דקה. השבוע שאחרי הוא המקום שבו המעבר נשבר, ולעיתים רחוקות במקום שהקונסולה של הספק מרמזת עליו. כתובת IP ציבורית חדשה מוזכרת בארבעה מקומות: ה-socket שהדימון מאזין עליו, עוגן האמון שהלקוחות מאמתים, כל כלל שמציין את הכתובת הישנה, וכן רשומת ה-DNS שקושרת ביניהם. שני מעברים נראים זהים מפאנל בקרה אך מתנהגים אחרת לגמרי: הקצאה מחדש של הכתובת במכונה שאתם מפעילים, או הקמת endpoint שני והעברת לקוחות אליו. הבדיקות שלהלן שמות את הכשלים הזולים ראשונים, וכל חלק מציין לאיזה מעבר הוא חל.
החלפה במקום ומעבר מקביל הם עבודות שונות
החלפה במקום שומרת על המארח, המפתחות, טבלת הניתוב ורשימת המשתמשים; רק הכתובת משתנה. זה מה שהקצאה מחדש של IP צף עושה, ובכמה ספקים האורח כלל לא מבחין, כי התרגום קורה לפני המופע. בנייה מחדש או הקצאה מחדש מצד הספק קשות יותר: האורח רואה את השינוי, וכל מה ששמר את הערך הישן במטמון לומד עליו באותו רגע.
endpoint מקביל הוא מארח שני שעושה את אותה עבודה. בנו אותו, בדקו אותו עם פרופיל אחד, והשאירו את הישן עונה עד שהחדש יוכיח את עצמו בנתיב אמיתי. המחיר הוא מצב. בלי רשומות peer משותפות, ביטולים ורישום, יש לכם שתי רשתות שמקרה חולקות שם.
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
מצאו כל מקום שבו הכתובת הישנה כתובה
התחילו בסריקת טקסט, כי קובצי התצורה הם החצי הקל. חפשו בתצורת הדימון, בקטעי חומת האש, ביעדי הניטור ובכל חבילת לקוח שנוצרה בדיסק. כללו את כתובת IPv6 אם אתם מפרסמים אחת; מעבר שעוקב רק אחרי רשומת A משאיר לקוחות בדו-מחסנית בנתיב הישן.
OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpointsאחר כך סרקו את הליבה, כי מערכת פועלת מחזיקה את הכתובת במקומות שאף קובץ לא מזכיר. כלל NAT מקור סטטי, רשומת ipset, כתובת bind ורשומת conntrack שורדים את עריכת התצורה שהסירה אותם, וחלקם שורדים גם אתחול כי הם חזרו מקבוצת כללים שמורה. קומה אחת למעלה, קבוצות האבטחה של הספק, יעדי מאזן העומס ובדיקות הניטור כלל לא נמצאים במערכת הקבצים שלכם.
רשמו את המלאי לפני שתשנו משהו; הוא משמש גם כתסריט חזרה לאחור.
לקוחות לפי שם מארח מתאוששים; לקוחות לפי IP מילולי שותקים
אם הלקוחות מגיעים לשרת דרך שם מארח, המעבר הוא בעיקר בעיית DNS, וה-TTL שקבעתם אתמול קובע כמה זה יהיה גרוע. הפותרים שומרים במטמון, פותרי stub שומרים שוב, ולקוחות רבים מחפשים את השם רק בחיבור חדש, כך שמנהרה מבוססת שומרת על כתובת הפתיחה שלה.
אם ה-endpoint הוא כתובת מילולית, דבר אינו מפוענח מחדש ודבר אינו רושם תלונה. WireGuard שומר כתובת socket מפוענחת: Endpoint = vpn.example.net:51820 הופך ל-IP ברגע ש-wg-quick up רץ ונשאר אותו IP עד שתשנו אותו. OpenVPN סלחני יותר: הוא מפענח את שם המארח remote בזמן החיבור, ועם resolv-retry infinite מנסה DNS שוב בחיבור מחדש. עם IP מילולי, שניהם ממשיכים לחייג למכונה שכבר אינה קיימת.
מה שמטעה אנשים הוא תמונת הראי. לקוח שכבר מכוון לכתובת החדשה, בעוד המאזין הישן עדיין עונה, עובר כל בדיקה שתעשו מהשולחן שלכם. גם אני הוטעיתי מזה: ה-endpoint החדש עלה בטלפון בניסיון אחד, ולקוח עם פרופיל מיושן התגלה רק כשהמאזין הישן כובה הרבה יותר מאוחר.
אמון אינו עובר עם הכתובת
WireGuard מפריד זהות מנגישות, מה שהופך העברת כתובת לכמעט חינם. peers מזוהים לפי מפתח ציבורי, וה-endpoint הוא רק לאן שהחבילות הולכות כרגע; מארח מעדכן את ה-endpoint של peer מכתובת המקור של החבילה המאומתת האחרונה. peer לא פעיל עדיין זקוק לסיבה לדבר עם המקום החדש, והוא לומד את הכתובת רק כשהפעלה שלו מתיישנת וניסיונות ה-handshake נכשלים במקום גלוי. המדריך המהיר של WireGuard מכסה את שדה ה-endpoint.
שרתים מבוססי TLS הם המקרה ההפוך. התעודה קשורה לשם, ולקוח שמחייג לכתובת משווה את מה שחייג לשמות החלופיים של הנושא. התחברו ב-IP לתעודה שנושאת רק SAN של DNS והאימות נכשל: השם שהלקוח השתמש בו אינו בתעודה. הנפקה מחדש עם SAN של IP מתקנת את החיבור האחד הזה ומחמירה את המעבר הבא. השארת שם מארח בפרופיל והשארת verify-x509-name במקומו שומרת על בדיקה קפדנית בזמן שהכתובת שמתחת משתנה.
אחר כך בדקו למה הדימון קשור; socket שנעוץ לכתובת הישנה נכשל בשקט. שרת OpenVPN שהופעל עם local 203.0.113.10 מסרב לעלות ברגע שהכתובת הזו נעלמת, בעוד מאזין על 0.0.0.0 עוקב אחרי השינוי בחינם. NAT מתפצל באותו אופן: MASQUERADE עוקב אחרי הכתובת שיש למכונה עכשיו, ו-SNAT --to-source 203.0.113.10 סטטי ממשיך לשכתב לכתובת שאינה שלכם יותר, כך שתעבורת החזרה נעלמת. אם הכתובת החדשה מגיעה עם שער upstream אחר, בדקו rp_filter: סינון נתיב הפוך מפיל תעבורת חזרה שמגיעה לממשק שהליבה לא ציפתה לו.
סדר המעבר והראיות שהוא עבד
הנמיכו את ה-TTL יום מראש, הקימו את המאזין החדש, והוכיחו אותו עם פרופיל שרק לכם יש. בדיקה מתוך אותה רשת כמעט אינה מוכיחה דבר, לכן השתמשו בטלפון על סלולר ובדקו משהו שהמנהרה אמורה לשאת ולא פינג ל-endpoint.
עקבו אחרי שתי הכתובות לאורך החלון. wg show all latest-handshakes במארח החדש, או קובץ המצב של OpenVPN, אומר לכם כמה peers באמת עברו. כשבקצה החדש יש ה-peers שציפיתם להם ובישן רק מפגרים, הוציאו את המאזין הישן משירות, הסירו את כלל ה-NAT הישן והוציאו את הכתובת מחומת האש של הספק. הסרת המאזין הישן היא השלב שמדלגים עליו, והיא סוגרת את הפער שבו פרופיל מיושן עדיין מגיע לרשת הישנה.
קבעו בכתב את טריגר החזרה לפני שמתחילים: אם ל-endpoint החדש אין handshake מאף לקוח אמיתי אחרי החלון המוסכם, החזירו את הכתובת הישנה והפסיקו להפיץ פרופילים. הריצו את הסריקה שוב אחר כך ואשרו שאף מאזין אינו קשור לכתובת שהוצאה משירות. שני דברים עוברים למעבר הבא: שם מארח בפרופיל הלקוח כדי שהשינוי הבא יהיה עריכת DNS, והמלאי שנשמר לצד הערות השחזור של השרת.