הגדרת שרת Caddy: TLS אוטומטי, פרוקסי הפוך, HTTP/3

התקנת Caddy: היכן נשברים TLS ופרוקסי

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

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

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

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

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

מה נותנת האוטומציה של תעודות ופרוקסי הפוך

TLS אוטומטי ב-Caddy בנוי כך שהתעודה מונפקת כבר בפנייה הראשונה לדומיין ומתחדשת הרבה לפני תום התוקף — בלי צעדים ידניים ובלי תזכורות ביומן. ההנפקה אורכת שניות: מהחלת התצורה ועד לחיבור HTTPS פעיל. סוג האירועים "התעודה פגה בלילה של סוף שבוע" נעלם יחד עם החלפה ידנית.

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

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

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

דרכים לפריסת השרת: חבילה, קונטיינר, בנייה

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

איך לבחור מצב

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

התקנת Caddy והגדרה: שלבי העבודה ההנדסית

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

1. ביקורת תצורה. אוספים מה משרת את שכבת האינטרנט, היכן מסתיים TLS, אילו דומיינים ופורטים תפוסים ומי מחזיק בתעודות. מסמנים נקודות שבהן חידוש אוטומטי מתנגש עם מאזן עומסים חיצוני.
2. סכימת ניתובים. מגדירים תחום אחריות: מה Caddy מקבל על עצמו ומה נשאר במתאר החיצוני. מסכמים רשימת דומיינים וכללי הפניות לפני תחילת העבודה.
3. התקנה והגדרה בסיסית. מתקינים מהמאגר הרשמי, מגדירים שירות מערכת, הרשאות לפורטים ולתיקיית התעודות. התצורה חיה במאגר, ולא נערכת ידנית על המכונה.
4. ניתובים ותעודות. מתארים מארחים וירטואליים, כתובות אפליקציות וכותרות. מפעילים הנפקה וחידוש אוטומטיים, בודקים את השרשרת ואת ההתנהגות בעת העברת דומיין.
5. בדיקת ניתובים. מריצים את כל הכתובות והשיטות: קודי תגובה, הפניות, התנהגות כשהאפליקציה לא זמינה, גדלים גבוליים של בקשות. בנפרד בודקים חזרה לתצורה הקודמת.
6. תיעוד ומסירה לתפעול. מוסרים תצורות, סכימת ניתובים, סדר עריכות ותרחישי אבחון. עוברים עליהם עם הצוות שיהיה תורן.

תצורות, סכימות ניתוב ונהלים

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

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

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

מקרה בוחן: מעבר לפרוקסי הפוך עם TLS אוטומטי

לפני העבודה, הסכימה נשענה על פרוקסי הפוך עם סיום TLS ידני: תעודות הונפקו על ידי סקריפט לפי לוח זמנים, תצורות נערכו ישירות על צמתי העבודה, ו-HTTP/3 הופעל באמצעות הנחיות נפרדות בכל אחד מהם. החידוש יכול היה להיכשל בשקט — על הבעיה נודע מתלונות על אי-זמינות. שחזור אחרי כשל כזה ארך כ-40 דקות ודרש כניסה למכונה מסוימת.

מה שינו

העברנו את סיום ה-TLS ל-Caddy: תעודות מונפקות ומתחדשות אוטומטית, התצורה מתוארת באופן הצהרתי בקובץ אחד ונמצאת במאגר עם סקירה חובה. הוספת דומיין הצטמצמה לרשומה אחת במקום שישה צעדים ידניים, ו-HTTP/3 מופעל באמצעות הנחיה, לא בבנייה נפרדת. המעבר בוצע צומת אחר צומת, עם בדיקת תגובות על תעבורה חיה וחזרה מיידית לקומיט הקודם.

מדדים לפני ואחרי

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

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

מה עושים אם פרוקסי הפוך כבר פרוס?

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

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

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

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

שאלות טכניות נפוצות על TLS ופרוקסי הפוך

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

כיצד הפתרון מתנהג תחת עומס?

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

מי אחראי לחידוש והיכן מגבלות הפתרון?

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

נדון במשימה: מה להכין לשיחה הראשונה

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

• רשימת דומיינים ותת-דומיינים: אילו פונים החוצה, אילו חיים רק ברשת הפנימית והיכן צריך להסתיים TLS.
• היכן ממוקמות אזורי DNS והאם יש גישה פרוגרמטית לספק — מזה תלויים הנפקה אוטומטית וחידוש תעודות.
• אילו שירותים הפרוקסי מכסה: פורטים ונתיבים, חיבורים ארוכים, תוכן סטטי, כתובות בדיקת מצב.
• תצורה נוכחית: מה עומד בכניסה כעת, אילו קבצים וכללים משתתפים ומה מפריע למעבר.
• סכימת רשת והרשאות: כיצד המהנדס נכנס למכונה, האם פורטי תעבורת אינטרנט פתוחים מבחוץ, האם יש צומת מתווך.
• דרישות ל-TLS ול-HTTP/3: האם נדרשות מדיניות מחמירה, אימות הדדי, עדיפות ללקוחות מודרניים.
• מגבלות זמן: האם אפשר להעביר תעבורה חיה, האם יש חלון לעבודה וחלון נפרד לחזרה לאחור.

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