הגדרת הפניה אוטומטית מ-HTTP ל-HTTPS למאזני עומסים פנימיים אזוריים של אפליקציות

במאמר הזה מוסבר איך להשתמש בהפניות במפת URL כדי להפנות את כל הבקשות הפנימיות של מאזן העומסים של האפליקציה מ-HTTP ל-HTTPS. בדוגמה שבדף הזה נעשה שימוש ביציאות המוכרות 80 (ל-HTTP) ו-443 (ל-HTTPS). עם זאת, לא חובה להשתמש במספרי היציאה הספציפיים האלה. כל כלל העברה של מאזן עומסים של אפליקציות יכול להפנות ליציאה אחת מ-1 עד 65535.

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

באופן כללי, כדי להפנות תנועת HTTP באופן אוטומטי אל HTTPS, צריך לבצע את הפעולות הבאות:

1. יוצרים מאזן עומסים פנימי רגיל מסוג HTTPS עם כתובת IP פנימית משותפת שמורה.
2. בודקים את מאזן העומסים כדי לוודא שהוא פועל.

3. הפניית תנועה למאזן העומסים ב-HTTPS.

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

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

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

למאזן העומסים מסוג HTTP יש את אותה כתובת IP כמו למאזן העומסים מסוג HTTPS, והוראת הפניה אוטומטית במפת URL.

הגדרה של הפניה אוטומטית פנימית מ-HTTP ל-HTTPS (לחצו כדי להגדיל).

יצירת מאזן עומסים פנימי מסוג HTTPS

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

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

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

הפניית תנועה למאזן העומסים ב-HTTPS

יוצרים מאזן עומסים חלקי של HTTP עם אותה כתובת IP כמו מאזן העומסים של HTTPS שנוצר בשלב הקודם. מאזן העומסים החלקי מפנה תנועה מיציאה 80 ליציאה 443.

המסוף

בחירת סוג מאזן העומסים

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

   כניסה לדף איזון עומסים

2. לוחצים על Create load balancer (יצירת מאזן עומסים).
3. בקטע Type of load balancer, בוחרים באפשרות Application Load Balancer (HTTP/HTTPS) ולוחצים על Next.
4. בקטע Public facing or internal (פנימי או גלוי לכולם), בוחרים באפשרות Internal (פנימי) ולוחצים על Next (הבא).
5. בקטע פריסה חוצה אזורים או פריסה באזור יחיד, בוחרים באפשרות הכי מתאים לעומסי עבודה אזוריים ולוחצים על הבא.
6. לוחצים על Configure (הגדרה).

הגדרה בסיסית

1. בשדה של שם מאזן העומסים, מזינים l7-ilb-http-redirect.
2. בשדה אזור, בוחרים באפשרות us-west1.
3. בקטע רשת, בוחרים באפשרות lb-network.

הגדרת שירות הקצה העורפי

1. לוחצים על Backend configuration.
2. בתפריט Select backend services בוחרים את שירות ה-backend הקיים l7-ilb-backend-service.
3. לוחצים על OK.

הגדרת מפת URL

1. לוחצים על כללי ניתוב.
2. בקטע Mode (מצב), בוחרים באפשרות Advanced host and path rule (כלל מתקדם של מארח ונתיב).
3. לוחצים על הוספת כלל של מארח ונתיב.

4. מגדירים את Hosts לערך *.

5. בשדה Path matcher (matches, actions and services) (התאמה לפי נתיב (התאמות, פעולות ושירותים)), מזינים את הקוד הבא:

   name: matcher1
   defaultUrlRedirect:
     httpsRedirect: true
     hostRedirect: IP_ADDRESS:443
     redirectResponseCode: PERMANENT_REDIRECT

6. מוודאים ש-l7-ilb-backend-service הוא שירות הקצה העורפי היחיד לכל מארח שלא תואם ולכל נתיב שלא תואם.

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

הגדרת הקצה הקדמי ל-HTTP

1. לוחצים על Frontend configuration.
2. מגדירים את השם של כלל ההעברה ל-l7-ilb-forwarding-rule.
3. מגדירים את Protocol לערך HTTP.
4. מגדירים את Subnetwork ל-backend-subnet.
5. מגדירים את Port ל-80.
6. בתפריט כתובת IP, בוחרים את כתובת ה-IP המשותפת שהוזמנה לכלל ההעברה של מאזן העומסים של HTTPS.
7. לוחצים על סיום.

בדיקת ההגדרות האישיות

1. לוחצים על Review and finalize.
2. בודקים את הגדרות ההגדרה של מאזן העומסים.
3. אופציונלי: לוחצים על Equivalent code (קוד מקביל) כדי לראות את בקשת API בארכיטקטורת REST שתשמש ליצירת מאזן העומסים.
4. לוחצים על יצירה.

gcloud

1. יוצרים מפת URL חדשה על ידי יצירת קובץ YAML עם הגדרות להפניית תנועה. מחליפים את IP_ADDRESS בכתובת ה-IP המשותפת שהוזמנה לכלל ההעברה של מאזן העומסים ב-HTTPS.

   defaultService: regions/us-west1/backendServices/l7-ilb-backend-service
   kind: compute#urlMap
   name: l7-ilb-redirect-url-map
   hostRules:
   - hosts:
    - '*'
    pathMatcher: matcher1
   pathMatchers:
   - name: matcher1
    defaultUrlRedirect:
          hostRedirect: IP_ADDRESS:443
          redirectResponseCode: PERMANENT_REDIRECT
          httpsRedirect: True

2. מייבאים את קובץ ה-YAML למפת ה-URL החדשה:

   gcloud compute url-maps import l7-ilb-redirect-url-map \
      --source=/tmp/url_map.yaml \
      --region=us-west1
   

3. יוצרים את שרת ה-Proxy של היעד של מאזן העומסים מסוג HTTP:

   gcloud compute target-http-proxies create l7-ilb-http-proxy \
      --url-map=l7-ilb-redirect-url-map \
      --region=us-west1
   

4. יוצרים כלל העברה חדש וכתובת IP משותפת:

   gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=lb-network \
      --subnet=backend-subnet \
      --address=IP_ADDRESS \
      --ports=80 \
      --region=us-west1 \
      --target-http-proxy=l7-ilb-http-proxy \
      --target-http-proxy-region=us-west1
   

בדיקת ההפניה האוטומטית של התנועה

1. מתחברים ל-VM של הלקוח.

   gcloud compute ssh l7-ilb-client-us-west1-a \
      --zone=us-west1-a
   

2. שליחת בקשת HTTP אל IP_ADDRESS ביציאה 80, וציפייה להפניה אוטומטית של התנועה.

   curl -L -k IP_ADDRESS

3. צפייה בפלט לדוגמה.

   Page served from: l7-ilb-backend-w11t
   

   כדי לראות פרטים נוספים, צריך להוסיף -vvv.

   curl -L -k IP_ADDRESS -vvv
   
   
   
   Rebuilt URL to: IP_ADDRESS/
   Trying IP_ADDRESS...
   TCP_NODELAY set
   Connected to IP_ADDRESS (IP_ADDRESS) port 80 (#0)
   > GET / HTTP/1.1
   > Host: IP_ADDRESS
   > User-Agent: curl/7.52.1
   > Accept: /
   >
   < HTTP/1.1 308 Permanent Redirect
   < location: https://IP_ADDRESS:443/
   < date: Fri, 07 Aug 2020 05:07:18 GMT
   < via: 1.1 google
   < content-length: 0
   <
   Curl_http_done: called premature == 0
   Connection #0 to host IP_ADDRESS left intact
   Issue another request to this URL: 'https://IP_ADDRESS:443/'
   Trying IP_ADDRESS...
   TCP_NODELAY set
   Connected to IP_ADDRESS (IP_ADDRESS) port 443 (#1)
   ALPN, offering h2
   ALPN, offering http/1.1
   Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
   successfully set certificate verify locations:
   CAfile: /etc/ssl/certs/ca-certificates.crt
   CApath: /etc/ssl/certs
   ...
   ...
   SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
   ALPN, server accepted to use h2
   Server certificate:
   subject: O=Google TESTING; CN=test_cert_1
   start date: Jan  1 00:00:00 2015 GMT
   expire date: Jan  1 00:00:00 2025 GMT
   issuer: O=Google TESTING; CN=Intermediate CA
   SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
   Using HTTP2, server supports multi-use
   Connection state changed (HTTP/2 confirmed)
   Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
   Using Stream ID: 1 (easy handle 0x561a6b0e3ea0)
   > GET / HTTP/1.1
   > Host: IP_ADDRESS
   > User-Agent: curl/7.52.1
   > Accept: /
   >
   Connection state changed (MAX_CONCURRENT_STREAMS updated)!
   < HTTP/2 200
   < date: Fri, 07 Aug 2020 05:07:18 GMT
   < server: Apache/2.4.25 (Debian)
   < last-modified: Thu, 06 Aug 2020 13:30:21 GMT
   < etag: "2c-5ac357d7a47ec"
   < accept-ranges: bytes
   < content-length: 44
   < content-type: text/html
   < via: 1.1 google
   <
   Page served from: l7-ilb-backend-https-w11t
   Curl_http_done: called premature == 0
   Connection #1 to host IP_ADDRESS left intact

המאמרים הבאים

• במאמר סקירה כללית על מאזן עומסים פנימי של אפליקציות מוסבר איך מאזני עומסים פנימיים של אפליקציות פועלים.

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

• ניקוי ההגדרות של מאזן העומסים