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

‫Google מציעה מגוון שירותים של קצה רשת שיכולים לשפר את היכולות והאבטחה של שירותים שמבוססים מחוץ ל- Google Cloud(שירותים מקומיים ושירותי ענן מרובים) – למשל, במרכז נתונים מקומי או בענן ציבורי אחר.

שירותי קצה הרשת האלה מאפשרים לכם:

  • קבלת תעבורת נתונים של לקוחות חיצוניים וניתוב שלה ברחבי העולם באמצעות כתובת VIP אחת מסוג Anycast.

  • הפחתת עומס השרת על ידי סיום תעבורת TLS בקצה הרשת באמצעות מאזן עומסים חיצוני של אפליקציות ואישורי SSL בניהול Google.

  • מפעילים כללים מוגדרים מראש של חומת אש לאפליקציות אינטרנט (WAF) ומחילים רשימות של כתובות IP מותרות ורשימות של כתובות IP חסומות על תעבורה נכנסת באמצעות Google Cloud Armor.

  • שליטה בגישת משתמשים לאפליקציות ולמשאבים באמצעות שרת proxy לאימות זהויות (IAP).

  • אפשר לבצע אופטימיזציה של העברת התוכן ושל זמן האחזור של משתמשי הקצה באמצעות Cloud CDN.

דוגמה לשירותים בקצה הרשת.
דוגמה לשירותים של קצה הרשת (לחצו כדי להגדיל)

כדי ליהנות מהיתרונות האלה בשירותים פרטיים, בשירותים מקומיים או בשירותי ריבוי עננים, צריך לפרוס מאזן עומסים חיצוני של אפליקציות (ALB) כדי לקבל תעבורה מהאינטרנט הציבורי. מאזן העומסים החיצוני של האפליקציות מעביר את התעבורה לשרת proxy אמצעי שמוגדר על ידי Cloud Service Mesh. הפרוקסי האמצעי הזה מעביר את התנועה לסביבה המקומית או לסביבה שאינהGoogle Cloud באמצעות Cloud VPN או Cloud Interconnect.

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

השלמתם את המשימות הבאות:

  1. פריסת Envoy כשרת proxy ביניים בקבוצה של מופעי מכונה מנוהלים (MIG). פרוקסי Envoy הזה מחובר אוטומטית ל-Cloud Service Mesh.
  2. יצירת מופע מדומה של מכונה וירטואלית (VM) פרטית מקומית. בדוגמה מהעולם האמיתי, סביר להניח שכבר יש לכם מכונה וירטואלית מקומית.
  3. מגדירים את Cloud Service Mesh לניתוב כל הבקשות שמגיעות לשרת ה-proxy האמצעי למכונה הווירטואלית המקומית המדומה.
  4. יוצרים מאזן עומסים חיצוני של אפליקציות (ALB) כדי לקבל תעבורה מהאינטרנט הציבורי ולהעביר אותה לשרת ה-proxy האמצעי.
  5. מצרפים מדיניות אבטחה של Cloud Armor למאזן עומסים חיצוני של אפליקציות (ALB).

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

דרישות מוקדמות

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

  • קוראים את המאמר הכנה להגדרה של Cloud Service Mesh עם Envoy ומשלימים את כל המשימות הנדרשות, כולל מתן ההרשאות והתפקידים הנדרשים והפעלת Cloud Service Mesh API.

  • מוודאים שאפשר להגיע לנקודות הקצה הפרטיות שלכם ברשת המקומית מתוך רשת הענן הווירטואלי הפרטי (VPC) שלכם באמצעות Cloud VPN או Cloud Interconnect. Google Cloud בדוגמה שבה נעשה שימוש במדריך הזה, התעבורה מנותבת רק לנקודת קצה בתוך Google Cloud, כך שלא צריך להגדיר קישוריות היברידית כדי להמשיך. בתרחיש פריסה בעולם האמיתי, נדרשת הגדרה של קישוריות היברידית.

  • מוודאים שטווחי ה-CIDR של רשתות המשנה ב-VPC לא מתנגשים עם טווחי ה-CIDR המרוחקים. כשכתובות ה-IP חופפות, נתיבי תת-הרשת מקבלים עדיפות על פני קישוריות מרוחקת.

  • כדי להשתמש בהדגמה הזו, צריך לקבל את ההרשאות הנדרשות ליצירה ולעדכון של כללי אבטחה ב-Cloud Armor. יכול להיות שההרשאות יהיו שונות אם רוצים להשתמש בשירות אחר, כמו Cloud CDN.

פריסת שרת proxy אמצעי במכונות וירטואליות ב-Compute Engine

בקטע הזה מוסבר איך לפרוס את Envoy כשרת proxy באמצע ב-Compute Engine כדי לקבל תנועה ממאזן העומסים החיצוני ולהעביר אותה ליעד המרוחק.

יצירת תבנית של הגדרות מכונה לשרת ה-proxy האמצעי

תבנית של הגדרות מכונה מציינת את ההגדרות של מכונות וירטואליות בקבוצת מופעי מכונה מנוהלים (MIG).

  1. אפשר להשתמש בתבנית הבאה כדי ליצור מכונות וירטואליות עם שרת proxy של Envoy שמחובר ל-Cloud Service Mesh:

    gcloud compute instance-templates create td-middle-proxy \
    --service-proxy=enabled \
    --tags=allow-hc

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

יצירת קבוצת MIG לשרת ה-proxy האמצעי

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

    gcloud compute instance-groups managed create td-middle-proxy-us-central1-a \
    --zone=us-central1-a \
    --template=td-middle-proxy \
    --size=1

  2. כדי להשתמש בה בעתיד להגדרות ולאימות, צריך לזהות את כתובת ה-IP הפנימית של המופע ב-MIDDLE_PROXY_IP ולשמור אותה:

    MIDDLE_PROXY_IP=$(gcloud compute instances list \
    --filter="name~'td-middle-proxy-us-central1-a-.*'" \
    --zones=us-central1-a \
    --format="value(networkInterfaces.networkIP)")

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

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

פריסת השירות המקומי המדומה

בקטע הזה מוסבר איך פורסים קבוצה של נקודות קצה ברשת (NEG) עם קישוריות היברידית. בפריסה של סביבת ייצור, קבוצת נקודות הקצה הזו תכיל נקודת קצה (IP:port) שמפנה לשרת המקומי שלכם. בדוגמה הזו, יוצרים מכונה וירטואלית ב-Compute Engine שאפשר להגיע אליה בכתובת IP:port. המכונה הווירטואלית הזו משמשת כשרת מקומי מדומה.

יצירת מכונה וירטואלית מקומית מדומה

  1. פריסת מכונה וירטואלית אחת כדי לדמות שרת פרטי מקומי:

    gcloud compute instances create on-prem-vm \
    --zone=us-central1-a \
    --metadata startup-script='#! /bin/bash
## Installs apache and a custom homepage
sudo su -
apt-get update
apt-get install -y apache2
cat <<EOF > /var/www/html/index.html
<html><body><h1>Hello world from on-premises!</h1></body></html>
EOF'

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

    ON_PREM_IP=$(gcloud compute instances describe on-prem-vm \
    --zone=us-central1-a \
    --format="value(networkInterfaces.networkIP)" | sed "s/['\[\]]*//g")

יצירת ה-NEG

כדי ליצור את ה-NEG להדגמה הזו, מציינים את non-gcp-private-ip-port סוג נקודת הקצה ברשת. מוסיפים את כתובת ה-IP והיציאה של המכונה הווירטואלית המדומה בפריסה המקומית כנקודת קצה ל-NEG הזה. בהמשך לשלב הקודם, כתובת ה-IP מאוחסנת במשתנה הסביבה ON_PREM_IP.

  1. יוצרים את ה-NEG:

    gcloud compute network-endpoint-groups create td-on-prem-neg \
    --network-endpoint-type=non-gcp-private-ip-port \
    --zone=us-central1-a

  2. מוסיפים את IP:port ל-NEG החדש:

    gcloud compute network-endpoint-groups update td-on-prem-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=$ON_PREM_IP,port=80"

הגדרת Cloud Service Mesh עם רכיבי Cloud Load Balancing

בקטע הזה מוסבר איך להגדיר את Cloud Service Mesh ולאפשר לשרת ה-proxy האמצעי להעביר תעבורה לשירות הפרטי המקומי. מגדירים את הרכיבים הבאים:

  • בדיקת תקינות. בדיקת תקינות כזו מתנהגת קצת אחרת מבדיקות התקינות שמוגדרות לסוגים אחרים של NEG.

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

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

יצירת בדיקת התקינות

בדיקות התקינות מאמתות שהנקודות שלכם תקינות ויכולות לקבל בקשות. בדיקת התקינות של סוג ה-NEG הזה מתבססת על מנגנון בדיקת התקינות המבוזר של Envoy.

סוגים אחרים של קבוצות NEG משתמשים במערכת המרכזית לבדיקת תקינות של Google Cloud:

gcloud compute health-checks create http td-on-prem-health-check

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

  1. יוצרים שירות לקצה העורפי עם סכימת איזון העומסים INTERNAL_SELF_MANAGED לשימוש עם Cloud Service Mesh. כשיוצרים את שירות ה-Backend הזה, מציינים את בדיקת התקינות שיצרתם קודם:

    gcloud compute backend-services create td-on-prem-backend-service \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --health-checks=td-on-prem-health-check

  2. מוסיפים את ה-NEG שיצרתם קודם כ-backend של שירות לקצה העורפי הזה:

    gcloud compute backend-services add-backend td-on-prem-backend-service \
    --global \
    --network-endpoint-group=td-on-prem-neg \
    --network-endpoint-group-zone=us-central1-a \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=5

יצירת מפת כללי הניתוב

מפת כללי הניתוב מגדירה איך Cloud Service Mesh מנתב תעבורה לשירות לקצה העורפי שלכם.

  1. יוצרים מפת URL שמשתמשת בשירות לקצה העורפי שהוגדר קודם לכן:

    gcloud compute url-maps create td-hybrid-url-map \
    --default-service=td-on-prem-backend-service

  2. יוצרים קובץ בשם target_proxy.yaml עם התוכן הבא:

    name: td-hybrid-proxy
proxyBind: true
urlMap: global/urlMaps/td-hybrid-url-map

  3. משתמשים בפקודה import כדי ליצור את ה-proxy של יעד ה-HTTP (למידע נוסף, ראו Target proxies for Cloud Service Mesh):

    gcloud compute target-http-proxies import td-hybrid-proxy \
    --source=target_proxy.yaml

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

    gcloud compute forwarding-rules create td-hybrid-forwarding-rule \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --address=0.0.0.0 \
    --target-http-proxy=td-hybrid-proxy \
    --ports=8080 \
    --network=default

מוודאים שה-proxy האמצעי יכול לנתב בקשות לשירות המקומי המדומה

ההגדרה של Cloud Service Mesh הסתיימה והכול מוכן לניתוב תעבורת הנתונים דרך שרת ה-proxy האמצעי לשירות הפרטי המדומה שלכם, שנמצא בשרת מקומי. כדי לוודא שההגדרה הזו נכונה, אפשר ליצור VM של לקוח לבדיקה, להתחבר ל-VM הזו ולשלוח בקשה לשרת ה-proxy האמצעי שמריץ את Envoy. אחרי שמאמתים את ההגדרה, מוחקים את המכונה הווירטואלית של לקוח הבדיקה.

  1. מקבלים את כתובת ה-IP של שרת ה-Proxy האמצעי. הפרטים האלה נדרשים רק בשלב האימות:

    gcloud compute instances list

  2. רושמים את כתובת ה-IP של המכונה ב-td-middle-proxy-us-central1-a MIG.

  3. יוצרים מכונה לדוגמה של לקוח:

    gcloud compute instances create test-client \
    --zone=us-central1-a

  4. משתמשים בקוד ssh כדי להיכנס ללקוח הבדיקה:

    gcloud compute ssh test-client
    --zone=us-central1-a

  5. שולחים בקשה למכונה הווירטואלית של ה-proxy האמצעי, ומחליפים את כתובת ה-IP שקיבלתם קודם לכן ב-MIDDLE_PROXY_IP:

    curl $MIDDLE_PROXY_IP:8080

    הפלט הבא אמור להתקבל:

    Hello world from on-premises!

  6. יוצאים מה-VM של לקוח הבדיקה. אחרי שיוצאים, אפשר למחוק את המכונה הווירטואלית:

    gcloud compute instances delete test-client \
    --zone=us-central1-a

פריסת מאזן עומסים חיצוני של אפליקציות (ALB)

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

שמירת כתובת IP חיצונית

יוצרים כתובת IP חיצונית סטטית גלובלית (external-lb-vip) שאליה לקוחות חיצוניים ישלחו תעבורה. תקבלו את כתובת ה-IP החיצונית הזו בשלב האימות בהמשך המדריך הזה.

gcloud compute addresses create external-lb-vip \
    --ip-version=IPV4 \
    --global

הגדרת מאזן עומסים חיצוני מסוג HTTP

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

  1. יוצרים בדיקת תקינות שמשמשת לקביעה אם ה-MIG שמריץ את ה-proxy האמצעי תקין ויכול לקבל תנועה:

    gcloud compute health-checks create tcp tcp-basic-check \
    --port=8080

  2. יוצרים כלל חומת אש שמאפשר בדיקת תקינות. כאן משתמשים שוב בתג allow-hc כדי להחיל את כלל חומת האש על המכונות הווירטואליות של ה-proxy האמצעי:

    gcloud compute firewall-rules create fw-allow-health-checks \
    --network=default \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=35.191.0.0/16,130.211.0.0/22 \
    --target-tags=allow-hc \
    --rules=tcp

  3. יוצרים שירות לקצה העורפי:

    gcloud compute backend-services create td-middle-proxy-backend-service \
    --protocol=HTTP \
    --health-checks=tcp-basic-check \
    --global

  4. מוסיפים את ה-MIG של ה-proxy האמצעי כקצה עורפי לשירות הקצה העורפי הזה:

    gcloud compute backend-services add-backend td-middle-proxy-backend-service \
    --instance-group=td-middle-proxy-us-central1-a \
    --instance-group-zone=us-central1-a \
    --global

  5. יוצרים מפת URL כדי לנתב את הבקשות הנכנסות לשרת ה-Proxy האמצעי כשירות ברירת המחדל לקצה העורפי:

    gcloud compute url-maps create lb-map-http \
    --default-service=td-middle-proxy-backend-service

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

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

  7. יוצרים כלל העברה גלובלי כדי לנתב בקשות נכנסות אל שרת ה-proxy של HTTP:

    gcloud compute forwarding-rules create http-forwarding-rule \
    --address=external-lb-vip\
    --global \
    --load-balancing-scheme=EXTERNAL \
    --target-http-proxy=http-lb-proxy \
    --ports=80

הגדרת יציאה בעלת שם ב-MIG

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

gcloud compute instance-groups managed set-named-ports td-middle-proxy-us-central1-a \
    --named-ports=http:8080 \
    --zone=us-central1-a

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

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

  1. אמורה להיות לכם אפשרות לשלוח בקשה ל-VIP של מאזן העומסים ולקבל תגובה מה-VM המקומי המדומה:

    PUBLIC_VIP=gcloud compute addresses describe external-lb-vip \
    --format="get(address)" \
    --global

  2. שולחים בקשת curl לכתובת ה-IP החיצונית (PUBLIC_VIP) ומוודאים שמקבלים את ההודעה Hello world:

    curl $PUBLIC_VIP

    הפלט הבא מוצג:

    Hello world from on-premises!

הפעלת Cloud Armor

מגדירים את מדיניות האבטחה של Cloud Armor כך שתאפשר גישה לשירות רק מכתובת ה-IP החיצונית של מכשיר הלקוח שרוצים לבדוק, למשל "192.0.2.0/24".CLIENT_IP_RANGE

המדיניות הזו מוחלת על שירות הקצה העורפי של מאזן העומסים החיצוני (בדוגמה הזו, td-hybrid-backend-service שמצביע על שרת ה-proxy האמצעי). למידע נוסף על ההרשאות שנדרשות להגדרת הכללים האלה, אפשר לעיין במאמר הגדרת מדיניות אבטחה ב-Cloud Armor.

  1. יוצרים את מדיניות האבטחה של Cloud Armor:

    gcloud compute security-policies create external-clients-policy \
    --description="policy for external clients"

  2. מעדכנים את הכלל שמוגדר כברירת מחדל במדיניות האבטחה כך שידחה את כל התנועה:

    gcloud compute security-policies rules update 2147483647 \
    --security-policy=external-clients-policy \
    --action="deny-404"

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

    gcloud compute security-policies rules create 1000 \
    --security-policy=external-clients-policy \
    --description="allow traffic from CLIENT_IP_RANGE" \
    --src-ip-ranges="CLIENT_IP_RANGE" \
    --action="allow"

  4. מצרפים את כללי מדיניות האבטחה של Cloud Armor לשירות הקצה העורפי:

    gcloud compute backend-services update td-middle-proxy-backend-service \
    --security-policy=external-clients-policy

אימות סופי

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

    curl $PUBLIC_VIP

    הפלט הבא מוצג:

    Hello world from on-premises!

  2. צריך לשלוח את אותה בקשת curl ממכשיר לקוח אחר שכתובת ה-IP שלו לא נמצאת בטווח CLIENT_IP_RANGE, או לעדכן את כלל מדיניות האבטחה כך שלא יכלול יותר את כתובת ה-IP של הלקוח. עכשיו אמורה להופיע שגיאת 404 Not Found.

פתרון בעיות

בהוראות הבאות מוסבר איך לפתור בעיות בהגדרות.

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

בהנחה שהשירות המקומי שלכם כבר נגיש במכונות הווירטואליותGoogle Cloud שבהן פועלים ה-Envoy, פועלים לפי השלבים הבאים כדי לפתור בעיות בהגדרה:

  1. מוודאים ש-Envoy MIG מדווח כבריא. Google Cloud במסוף Google Cloud , עוברים אל Network services > איזון עומסים ולוחצים על url-map lb-map-http כדי לראות את הפרטים. אמורה להיות לך אפשרות לראות שמתוך 1/1 מהמופעים ב-td-middle-proxy-us-central1-a, המופע תקין.

  2. אם המצב לא תקין, צריך לבדוק אם הוגדר כלל חומת אש שמאפשר תעבורת נתונים נכנסת (ingress) של בדיקות תקינות למכונות הווירטואליות שבהן פועל Envoy: Google Cloud 

    gcloud compute firewall-rules describe fw-allow-health-check

    הפלט הבא אמור להתקבל:

    allowed:
‑ IPProtocol: tcp
...
direction: INGRESS
disabled: false
...
...
sourceRanges:
‑ 130.211.0.0/22
‑ 35.191.0.0/16
targetTags:
‑ allow-hc

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