העברת תוכן HTTP ו-HTTPS באותו דומיין שפורסם

בדרך כלל, כשמשתמשים ב-Cloud CDN, מעבירים תוכן HTTP ו-HTTPS באותו שם מארח. הרבה דפדפנים אוכפים את השימוש ב-Transport Layer Security ‏ (TLS) ולא מאפשרים מסירת תוכן לא מאובטח, אבל עדיין יש תרחישי שימוש שבהם צריך לאפשר מסירה לא מאובטחת ומסירה מאובטחת באותו שם מארח. במאמר הזה נסביר איך אפשר להשיג את הפונקציונליות הזו באמצעות Cloud CDN.

אתגר

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

  1. הפניה לשם דומיין ששייך ל-CDN באמצעות רשומת CNAME של DNS.
  2. ניתוב תעבורה לקבוצת משנה של שרתים שתומכים במשא ומתן של TLS עבור שם הדומיין הזה.

מכיוון ש-Cloud CDN משתלב עם Cloud Load Balancing, הגישה של Cloud CDN שונה מהגישה של רשתות CDN רגילות. ‫Cloud CDN ממנף את כתובת ה-IP מסוג Anycast של מאזן עומסים חיצוני של אפליקציות. כשמגדירים את Cloud CDN, יש כתובת IP ספציפית שאליה מכוונים את התנועה. לשם כך צריך ליצור רשומת A (ל-IPv4) או רשומת AAAA (ל-IPv6) ברשומת ה-DNS, ולא רשומת CNAME עם ערך של שם מארח.

כברירת מחדל, כשמגדירים את הקצה הקדמי של מאזן העומסים, מערכתGoogle Cloud מקצה באופן דינמי כתובת IP זמנית. מכיוון שצריך להגדיר את ההגדרות של HTTP ו-HTTPS בנפרד, יכול להיות שיהיו לכם שני כתובות IP למופע Cloud CDN. מכיוון שכתובת ה-IP של רשומת A או רשומת AAAA זהה גם ל-HTTP וגם ל-HTTPS, אי אפשר לטפל במקרה הזה בצורה תקינה ב-DNS.

פתרון

כשמספקים תוכן מאובטח ולא מאובטח באותו שם מארח, הלקוח מופנה לשרת קצה שיכול לנהל משא ומתן על HTTP או על HTTPS. כדי שזה יעבוד עם Cloud CDN, אפשר לשריין כתובת IP ולקשר את כתובת ה-IP המשוריינת להגדרות של הקצה הקדמי ב-HTTP וב-HTTPS במאזן העומסים של אפליקציות (ALB) החיצוני.

פרוטוקולי HTTP ו-HTTPS באותו דומיין
HTTP and HTTPS over the same domain

בתרשים:

  • בקשות נכנסות לכתובת www.example.com מגיעות מלקוחות שמשתמשים ב-HTTP/2, ב-HTTPS וב-HTTP.

  • שתי כתובות IP שמורות, אחת ל-IPv4 ואחת ל-IPv6:

    • 34.95.111.204
    • [2600:1901:0:b13e::]

  • שתי כתובות ה-IP האלה משויכות ל-www.example.com ב-Cloud DNS.

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

    שם פרוטוקול IP:Port
    ipv4-http HTTP 34.95.111.204:80
    ipv4-https HTTPS 34.95.111.204:443
    ipv6-http HTTP [2600:1901:0:b13e::]:80
    ipv6-https HTTPS [2600:1901:0:b13e::]:443

  • במקרה של אי מציאה במטמון של Cloud CDN, מאזן העומסים מפזר את הבקשות למקורות הקצה העורפי, על סמך ההגדרות שמוגדרות במפת ה-URL של מאזן העומסים.

שלב 1: שמירת כתובת IP חיצונית גלובלית

יוצרים כתובת IPv4 או IPv6 (או את שתיהן). כדי לתמוך בכתובות IPv4 ו-IPv6, צריך ליצור כתובת IPv4 אחת וכתובת IPv6 אחת.

ברשומת ה-DNS,יוצרים רשומת A (או רשומת AAAA) כדי להפנות את התנועה לכתובת ה-IP השמורה הזו.

המסוף

  1. נכנסים לדף External IP addresses במסוף Google Cloud .

    לדף External IP addresses

  2. לוחצים על Reserve static address כדי לשריין כתובת IPv4.
  3. מקצים שם של ipv4-address.
  4. מגדירים את מסלול הרשת ל-Premium.
  5. מגדירים את IP version ל-IPv4.
  6. מגדירים את Type (סוג) בתור Global (גלובלי).
  7. לוחצים על Reserve.

מאזן העומסים משתמש ברשת במסלול הפרימיום, כפי שנדרש כש-Cloud CDN מופעל.

gcloud 

gcloud compute addresses create ipv4-address \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

שימו לב לכתובת ה-IPv4 שהוקצתה:

gcloud compute addresses describe lb-ipv4-1 \
    --format="get(address)" \
    --global

חוזרים על השלב הזה עבור IPv6.

מידע נוסף זמין במאמר בנושא שמירת כתובת IP חיצונית סטטית חדשה.

שלב 2: קישור כתובת ה-IP השמורה למאזן העומסים

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

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

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

המסוף

הגדרת כלל העברה של HTTP

  1. נכנסים לדף Load balancing במסוף Google Cloud .

    לדף Load balancing

  2. בוחרים את מאזן העומסים ולוחצים על עריכה.
  3. בחלונית הימנית, לוחצים על Frontend configuration.
  4. בשדה שם מזינים ipv4-http.
  5. בשדה Protocol, בוחרים באפשרות HTTP.
  6. מגדירים את IP version ל-IPv4.
  7. בשדה IP address (כתובת IP), בוחרים את כתובת ה-IP ipv4-address שיצרתם קודם.
  8. מוודאים שהיציאה מוגדרת ל-80 כדי לאפשר תנועת HTTP.
  9. לוחצים על סיום.

הגדרת כלל העברה של HTTPS

  1. נכנסים לדף Load balancing במסוף Google Cloud .

    לדף Load balancing

  2. בוחרים את מאזן העומסים ולוחצים על עריכה.
  3. בחלונית הימנית, לוחצים על Frontend configuration.
  4. בשדה שם מזינים ipv4-https.
  5. בשדה Protocol, בוחרים באפשרות HTTPS.
  6. מגדירים את IP version ל-IPv4.
  7. בשדה IP address (כתובת IP), בוחרים את כתובת ה-IP ipv4-address שיצרתם קודם.
  8. מוודאים שהיציאה מוגדרת ל-443 כדי לאפשר תנועת HTTP.
  9. לוחצים על התפריט הנפתח אישור.
    1. אם כבר יש לכם משאב של אישור SSL בניהול עצמי שאתם רוצים להשתמש בו כאישור ה-SSL הראשי, בוחרים אותו מהתפריט הנפתח.
    2. אחרת, בוחרים באפשרות Create a new certificate.
    3. בוחרים באפשרות העלאת האישור שלי או באפשרות יצירת אישור מנוהל על ידי Google.
    4. אם בחרתם באפשרות העלאת האישור שלי, צריך לבצע את השלבים הבאים.
      1. ממלאים את השם של www-ssl-cert.
      2. בשדות המתאימים מעלים את האישור של המפתח הציבורי (קובץ ‎.crt), את שרשרת האישורים (קובץ ‎.csr) ואת המפתח הפרטי (קובץ ‎.key).
      3. לוחצים על יצירה.
    5. אם בוחרים באפשרות Create Google managed certificate, צריך להזין Domain.
    6. כדי להוסיף משאבי אישורים בנוסף למשאב אישור ה-SSL הראשי:
      1. לוחצים על הוספת אישור.
      2. בוחרים אישור מהרשימה Certificates או לוחצים על Create a new certificate ופועלים לפי ההוראות שלמעלה.
  10. לוחצים על סיום.

חוזרים על השלבים האלה עבור IPv6.

בדיקה וסיום

  1. בחלונית הימנית, לוחצים על בדיקה וסיום.
  2. משווים את ההגדרות למה שרציתם ליצור.
  3. אם הכל נראה נכון, לוחצים על עדכון.

gcloud

  1. יוצרים HTTP proxy ליעד כדי להפנות בקשות למפת URL.

    gcloud compute target-http-proxies create http-lb-proxy \
  --url-map=web-map

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

    gcloud compute target-https-proxies create https-lb-proxy \
  --url-map=web-map --ssl-certificates=www-ssl-cert

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

    • במאזן עומסים גלובלי חיצוני של אפליקציות, משתמשים בפקודת ה-CLI של gcloud עם load-balancing-scheme=EXTERNAL_MANAGED. ההגדרה הזו מציעה יכולת מתקדמת לניהול תנועה.
    • במאזן עומסים קלאסי של אפליקציות (ALB), משתמשים ב-load-balancing-scheme=EXTERNAL.
    gcloud compute forwarding-rules create ipv4-http \
  --load-balancing-scheme=LOAD_BALANCING_SCHEME \
  --network-tier=PREMIUM \
  --address=ipv4-address \
  --global \
  --target-http-proxy=http-lb-proxy \
  --ports=80

    gcloud compute forwarding-rules create ipv4-https \
  --load-balancing-scheme=LOAD_BALANCING_SCHEME \
  --network-tier=PREMIUM \
  --address=ipv4-address  \
  --global \
  --target-https-proxy=https-lb-proxy \
  --ports=443

אחרי שיוצרים את כללי ההעברה הגלובליים, יכולות לחלוף כמה דקות עד שההגדרה תופץ בכל העולם.

שלב 3: יוצרים רשומת A או AAAA בקובץ אזור ה-DNS

השלב האחרון בתהליך הוא יצירת רשומת A או רשומת AAAA בקובץ אזור ה-DNS כדי להפנות אל Cloud CDN, שבו ערך שם המארח ישיב עם כתובות ה-IP השמורות שהקציתם במאזן העומסים.

עכשיו אפשר להציג גם HTTP וגם HTTPS באותו שם מארח דרך Cloud CDN.

אופציונלי: הפניה אוטומטית מ-HTTP ל-HTTPS

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

  • כלל העברה עם אותה כתובת IP חיצונית שמורה שבה משתמש מאזן העומסים של HTTPS, כמו שמוצג בדף הזה.
  • שרת proxy של HTTP ביעד, כמו שמוצג בדף הזה.
  • מפת URL ש מפנה תנועה למאזן העומסים ב-HTTPS.

קבלת תמיכה

אם יש לכם שאלות לגבי Google Cloud ו-Cloud CDN, אתם יכולים לפנות לצוות המכירות של Google Cloud או לפרסם הערה בערוץ #cloud-cdn בGoogle Cloudקהילת Slack.

מה השלב הבא?