הגדרת גישה לאינטרנט וכללים לחומת אש

במאמר הזה מוסבר איך לבצע את הפעולות הבאות:

• הגדרת מכונות וירטואליות (VM) של Dataflow לגישה לאינטרנט
• שימוש בתגים כדי לאבטח את הרשת של ה-worker VM.
• הגדרת כללים של חומת אש לרשת שמשויכת למשימות Dataflow

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

הערה: ברשת default יש הגדרות שמאפשרות להריץ משימות ב-Dataflow. עם זאת, יכול להיות שגם שירותים אחרים משתמשים ברשת הזו. חשוב לוודא שהשינויים ברשת default תואמים לכל השירותים. לחלופין, אפשר ליצור רשת נפרדת ל-Dataflow.

גישה ל- Google Cloud ממשקי API של Dataflow

המכונות הווירטואליות (VM) של ה-workers ב-Dataflow צריכות להגיע לממשקי ה-API ולשירותים שלGoogle Cloud . קבוצת נקודות הקצה (endpoints) התלויות של Google Cloud עשויה להשתנות עם הזמן, אבל כולן תומכות ב-VPC Service Controls. כדי להגדיר גישה לממשקי ה-API של Google Cloud , אפשר להשתמש באחת מהשיטות הבאות:

• מגדירים גישה פרטית ל-Google. באמצעות גישה פרטית ל-Google, למכונות וירטואליות שיש להן רק כתובות IP פנימיות יכולה להיות גישה לכתובות IP של Google Cloud ושל שירותים.

• מגדירים כתובת IP של נקודת קצה (endpoint) ב-Private Service Connect כדי לגשת לממשקי ה-API ולשירותים של Google Cloud .

• הגדרת כתובות IP חיצוניות למכונות הווירטואליות של ה-workers.

כברירת מחדל, הכללים של חומת האש והגדרות ה-DNS מאפשרים גישה לממשקי ה-API שלGoogle Cloud . עם זאת, יכול להיות שאתם מגבילים באופן פעיל את הגישה לקבוצת משנה של ממשקי API של Google Cloud , למשל אם אתם משתמשים ב-VPC Service Controls. במקרה כזה, צריך לתת גישה לפחות ל-restricted.googleapis.com. אם אתם משתמשים ב-Private Service Connect, תנו גישה לחבילת vpc-sc. כדי לקבל את הפונקציונליות הנדרשת, אפשר גם לתת גישה לדומיינים עם הרשאות רחבות יותר, כמו private.googleapis.com.

כדי לאפשר גישה לממשקי ה-API הנדרשים של Google Cloud דרך דומיין מסוים, הסביבה שלכם צריכה לעמוד בדרישות הבאות:

• כללי חומת האש חייבים לאפשר תעבורת נתונים יוצאת (egress) לכל טווחי הכתובות בדומיין שנבחר.

• ה-DNS צריך לפתור את *.googleapis.com לדומיין שבחרת.

לדוגמה, אם כללי חומת האש מגבילים את התעבורה היוצאת לטווח הכתובות restricted.googleapis.com, אז *.googleapis.com צריך לפתור את הכתובות בטווח הזה. למידע נוסף, קראו את המאמר הגדרת DNS ל-googleapis.com.

באופן דומה, אם אתם משתמשים ב-Private Service Connect, אתם צריכים ליצור רשומות DNS לדומיין ברירת המחדל של googleapis.com כדי להבטיח גישה לפחות לכל השירותים בחבילה של vpc-sc.

גישה לאינטרנט ב-Dataflow

בהתאם לתרחיש לדוגמה, יכול להיות שהמכונות הווירטואליות יצטרכו גם גישה למשאבים מחוץ ל-Google Cloud. כדי להגדיר גישה לאינטרנט ל-Dataflow, אפשר להשתמש באחת מהשיטות הבאות:

• מגדירים את ה-worker VMs עם כתובת IP חיצונית כדי שיעמדו בדרישות הגישה לאינטרנט.

• להגדיר פתרון NAT, כמו Cloud NAT. האפשרות הזו מיועדת להרצת משימות שניגשות לממשקי API ולשירותים מחוץ ל- Google Cloud שדורשים גישה לאינטרנט. לדוגמה, יכול להיות שמשימות של Python SDK יצטרכו גישה לאינדקס החבילות של Python ‏(PyPI) כדי להוריד יחסי תלות של צינורות עיבוד נתונים. במקרה כזה, צריך להגדיר את ה-worker VMs עם כתובות IP חיצוניות או להשתמש ב-Cloud NAT. אפשר גם לספק יחסי תלות של צינור עיבוד נתונים ב-Python במהלך שליחת המשימה. לדוגמה, אתם יכולים להשתמש בקונטיינרים בהתאמה אישית כדי לספק יחסי תלות של צינור עיבוד נתונים ב-Python, וכך להסיר את הצורך לגשת ל-PyPI בזמן הריצה.

  מידע נוסף זמין במאמר ניהול יחסי תלות של צינור עיבוד נתונים ב-Python במסמכי התיעוד של Apache Beam.

השבתת כתובת ה-IP החיצונית

כברירת מחדל, Dataflow מקצה ל-workers גם כתובות IP חיצוניות וגם כתובות IP פנימיות. כשמשביתים את כתובות ה-IP החיצוניות, למשימת Dataflow יש גישה רק למשאבים במקומות הבאים:

• מכונה אחרת באותה רשת VPC
• רשת VPC משותפת
• רשת שמופעל בה קישור בין רשתות VPC שכנות (peering)

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

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

אם משביתים את כתובות ה-IP החיצוניות, למשימות של Dataflow אין גישה לממשקי API ולשירותים מחוץ ל- Google Cloud שדורשים גישה לאינטרנט.

כדי להשבית כתובות IP חיצוניות, מבצעים אחת מהפעולות הבאות:

Java

1. מפעילים גישה פרטית ל-Google ברשת או ברשת המשנה.
2. בפרמטרים של משימת Dataflow, מציינים את --usePublicIps=false ואת --network=NETWORK-NAME או --subnetwork=SUBNETWORK-NAME.

   בהתאם לבחירה שלכם, מחליפים את אחד מהערכים הבאים:

   • ‫NETWORK-NAME: השם של רשת Compute Engine
   • ‫SUBNETWORK-NAME: השם של רשת המשנה של Compute Engine

Python

1. כדי להכין את כל יחסי התלות של חבילות Python, פועלים לפי ההוראות ליחסי תלות של צינור עיבוד נתונים של Apache Beam.
2. מפעילים גישה פרטית ל-Google ברשת או ברשת המשנה.

3. בפרמטרים של משימת Dataflow, מציינים את --no_use_public_ips ואת --network=NETWORK או --subnetwork=SUBNETWORK.

   בהתאם לבחירה שלכם, מחליפים את אחד מהערכים הבאים:

   • ‫NETWORK-NAME: השם של רשת Compute Engine
   • ‫SUBNETWORK-NAME: השם של רשת המשנה של Compute Engine

המשך

1. מפעילים גישה פרטית ל-Google ברשת או ברשת המשנה.

2. בפרמטרים של משימת Dataflow, מציינים את --no_use_public_ips ואת --network=NETWORK או --subnetwork=SUBNETWORK.

   בהתאם לבחירה שלכם, מחליפים את אחד מהערכים הבאים:

   • ‫NETWORK-NAME: השם של רשת Compute Engine
   • ‫SUBNETWORK-NAME: השם של רשת המשנה של Compute Engine

gcloud

1. מפעילים את גישה פרטית ל-Google ברשת או ברשת המשנה.

2. כשמפעילים את משימת Dataflow, צריך לכלול את הדגל --disable-public-ips ולציין את הדגל --network או --subnetwork. אפשר להשתמש באחת מהפקודות הבאות:

   • gcloud dataflow jobs run
   • gcloud dataflow flex-template run
   • gcloud dataflow yaml run

   בדוגמה הבאה משתמשים בפקודה gcloud dataflow jobs run:

   gcloud dataflow jobs run JOB_NAME \
       --gcs-location=gs://TEMPLATE_BUCKET/templates/TEMPLATE_NAME \
       --region=REGION \
       --staging-location=gs://TEMP_BUCKET/staging \
       --network=NETWORK_NAME \
       --subnetwork=SUBNETWORK_NAME \
       --disable-public-ips
   

   מחליפים את הערכים הבאים:

   • ‫JOB_NAME: שם ייחודי למשימת Dataflow.
   • ‫TEMPLATE_BUCKET ו-TEMPLATE_NAME: הקטגוריה של Cloud Storage והנתיב לקובץ התבנית.
   • ‫REGION: האזור ב-Dataflow שבו רוצים לפרוס את המשימה, למשל us-central1.
   • ‫TEMP_BUCKET: הקטגוריה של Cloud Storage לקבצים זמניים ולקבצים בינאריים.
   • ‫NETWORK_NAME: השם של רשת ה-VPC.
   • ‫SUBNETWORK_NAME: השם או כתובת ה-URL של רשת המשנה של ה-VPC.

API

1. מפעילים את גישה פרטית ל-Google ברשת או ברשת המשנה.

2. כשמפעילים את התבנית או המשימה של Dataflow באמצעות השיטה projects.locations.templates.launch של Dataflow REST API, באובייקט environment מגדירים את השדה ipConfiguration לערך WORKER_IP_PRIVATE ומציינים את network או את subnetwork:

   POST https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/templates:launch?gcsPath=gs://TEMPLATE_BUCKET/templates/TEMPLATE_NAME
   {
     "jobName": "JOB_NAME",
     "parameters": {
       "PARAM_KEY": "PARAM_VALUE"
     },
     "environment": {
       "tempLocation": "gs://TEMP_BUCKET/temp",
       "network": "NETWORK_NAME",
       "subnetwork": "SUBNETWORK_NAME",
       "ipConfiguration": "WORKER_IP_PRIVATE"
     }
   }
   

   מחליפים את הערכים הבאים:

   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
   • ‫REGION: האזור ב-Dataflow שבו רוצים לפרוס את המשימה, למשל us-central1.
   • ‫TEMPLATE_BUCKET ו-TEMPLATE_NAME: הקטגוריה של Cloud Storage והנתיב לקובץ התבנית.
   • ‫JOB_NAME: שם ייחודי למשימת Dataflow.
   • ‫PARAM_KEY ו-PARAM_VALUE: כל הפרמטרים של התבנית שנדרשים לצינור עיבוד הנתונים.
   • ‫TEMP_BUCKET: השם של הקטגוריה ב-Cloud Storage לקבצים זמניים.
   • ‫NETWORK_NAME: השם של רשת ה-VPC.
   • ‫SUBNETWORK_NAME: כתובת ה-URL המלאה או הנתיב של רשת המשנה של ה-VPC.

   השדה ipConfiguration הוא מסוג WorkerIPAddressConfiguration, ואפשר להזין בו את ערכי ה-enum הבאים:

   • ‫WORKER_IP_PRIVATE: ל-workers מוקצות רק כתובות IP פנימיות. כתובות IP ציבוריות מושבתות. נדרשת גישה פרטית ל-Google.
   • ‫WORKER_IP_PUBLIC: ל-workers מוקצות כתובות IP ציבוריות ופנימיות.
   • ‫WORKER_IP_UNSPECIFIED: שימוש בהגדרת ברירת המחדל (ה-workers מקבלים גם כתובות IP ציבוריות וגם כתובות IP פנימיות).

שימוש בתגים לאבטחת הרשת של ה-worker VM

בעזרת תגים אפשר להחיל כללים של חומת אש ברשת על מכונות וירטואליות ספציפיות. כשמריצים משימה ב-Dataflow, אפשר לציין תגים למכונות הווירטואליות של ה-workers ב-Dataflow שמבצעות את המשימה. כל כללי חומת האש של התגים האלה יחולו על ה-worker VMs של Dataflow.

ב-Dataflow יש תמיכה בשני סוגים של תגים לרשתות של מכונות וירטואליות:

• תגים מאובטחים
• תגי רשת

שימוש בתגים מאובטחים עם Dataflow

תגים מאובטחים, שנקראים גם תגים שמנוהלים באמצעות הממשק לניהול זהויות והרשאות גישה (IAM), הם צמדי מפתח/ערך שיוצרים ומנהלים ב-Resource Manager. בניגוד לתגי רשת, תגים מאובטחים תומכים בבקרת גישה באמצעות IAM.

היתרונות של שימוש בתגים מאובטחים במקום בתגי רשת כוללים:

• תגים מאובטחים מונעים שינויים לא מורשים בתגים, וכתוצאה מכך שינויים לא רצויים בכללי חומת האש.

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

• תגים מאובטחים עוברים בירושה ממשאבי הורה בהיררכיית Google Cloud , וכך אתם יכולים להגדיר תגים ברמות גבוהות יותר, כמו ברמת הארגון. מידע נוסף מופיע במאמר ירושה של תגים.

• באמצעות תגים מאובטחים, כללי חומת אש לתעבורת נתונים נכנסת יכולים לכלול מקורות ברשתות VPC שמחוברות באמצעות קישור VPC בין רשתות שכנות (peering). במשימות Dataflow, המשמעות היא שכלל חומת אש יכול לכלול מקורות גם ברשת של ה-worker VM וגם ברשתות VPC שמקושרות לרשתות שכנות.

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

כדי להחיל תגים מאובטחים על משימת Dataflow, מבצעים את הפעולות הבאות:

1. הגדרת תגים מאובטחים למדיניות חומת האש. מידע נוסף זמין במאמר הגדרת תגים מאובטחים.

2. מקצים את התפקיד משתמש בתגים (roles/resourcemanager.tagUser) לחשבון השירות של Dataflow במשאב (ערכי התגים). מידע נוסף על ההרשאות הנדרשות זמין במאמר ניהול תגים במשאבים.

3. כשיוצרים את משימת Dataflow, משתמשים בuse_vm_tagsאפשרות השירות בפורמט הבא:

Java

--dataflowServiceOptions=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

Python

--dataflow_service_options=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

המשך

--dataflow_service_options=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

gcloud

משתמשים בפקודה gcloud dataflow jobs run עם האפשרות additional-experiments. אם אתם משתמשים בתבניות Flex, השתמשו בפקודה gcloud dataflow flex-template run.

--additional-experiments=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

שימוש בתגי רשת ב-Dataflow

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

כדי להחיל תגי רשת על משימת Dataflow, משתמשים בניסוי use_network_tags באופן הבא:

Java

--dataflowServiceOptions=use_network_tags=TAG_NAME

Python

--dataflow_service_options=use_network_tags=TAG_NAME

המשך

--dataflow_service_options=use_network_tags=TAG_NAME

gcloud

משתמשים בפקודה gcloud dataflow jobs run עם האפשרות additional-experiments. אם אתם משתמשים בתבניות Flex, השתמשו בפקודה gcloud dataflow flex-template run.

--additional-experiments=use_network_tags=TAG_NAME

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

מחליפים את TAG_NAME בשמות של התגים. אם מוסיפים יותר מתג אחד, צריך להפריד בין התגים באמצעות נקודה ופסיק (;), כך: TAG_NAME_1;TAG_NAME_2;TAG_NAME_3;....

אחרי שהמשימה מתחילה, אי אפשר להוסיף לה עוד תגי רשת.

‫Dataflow תמיד מוסיף את תג הרשת שמוגדר כברירת מחדל, dataflow, לכל מכונת worker VM שהוא יוצר.

המגבלות שחלות על תגי רשת.

כללי חומת אש ל-Dataflow

כללי חומת אש מאפשרים תעבורה או מונעים אותה מהמכונות הווירטואליות ואליהן. אם במשימות Dataflow נעשה שימוש בארגון נתונים של Dataflow או במנוע סטרימינג, צריך רק לוודא שכללי חומת האש מאפשרים גישה לממשקי ה-API של Google Cloud . אחרת, צריך להגדיר כללים נוספים של חומת אש כדי שהמכונות הווירטואליות של Dataflow יוכלו לשלוח ולקבל תנועה ברשת ביציאת TCP‏ 12345 למשימות סטרימינג וביציאת TCP‏ 12346 למשימות באצווה. בעלי הפרויקט, עורכים או אדמינים של אבטחה צריכים ליצור את כללי חומת האש הנדרשים ברשת ה-VPC שבה משתמשים במכונות הווירטואליות של Dataflow.

לפני שאתם מגדירים כללים של חומת אש ל-Dataflow, קראו את המסמכים הבאים:

• סקירה כללית על כללי חומת האש של VPC ושימוש בכללי חומת האש של VPC

• סקירה כללית של מדיניות חומת אש היררכית ושימוש במדיניות חומת אש היררכית ובכללים

כשיוצרים כללים של חומת אש ל-Dataflow, צריך לציין את תגי הרשת של Dataflow. אחרת, כללי חומת האש חלים על כל המכונות הווירטואליות ברשת ה-VPC.

במקרים הרלוונטיים, מדיניות חומת האש ההיררכית נבדקת קודם, והכללים האלה מקבלים עדיפות על פני כללי חומת האש של VPC. אם משימת Dataflow נמצאת בפרויקט שהוא חלק מתיקייה או מארגון שבהם משתמשים במדיניות חומת אש היררכית, נדרש התפקיד compute.orgFirewallPolicyAdmin כדי לבצע שינויים במדיניות.

אם לא יוצרים תגי רשת בהתאמה אישית כשמריצים את קוד צינור עיבוד הנתונים, המכונות הווירטואליות של Dataflow משתמשות בתג ברירת המחדל dataflow. אם אין תגי רשת בהתאמה אישית, יוצרים את הכללים של חומת האש עם תג ברירת המחדל dataflow.

אם יוצרים תגי רשת בהתאמה אישית כשמריצים את קוד צינור עיבוד הנתונים, המכונות הווירטואליות של Dataflow משתמשות בתגים האלה. יוצרים את הכללים של חומת האש עם התגים בהתאמה אישית.

חלק מרשתות ה-VPC, כמו הרשת default שנוצרת באופן אוטומטי, כוללות כלל default-allow-internal שעומד בדרישות של חומת האש של Dataflow.

דוגמה לכלל תעבורת נתונים נכנסת (ingress) של חומת אש

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

בדוגמה הבאה, נוצר כלל כניסה של חומת אש ל-Dataflow, שבו לכל worker VM יש את תג הרשת שמוגדר כברירת מחדל dataflow. Project Owner, עורכים או Security Admin יכולים להשתמש בפקודה הבאה של gcloud כדי ליצור כלל כניסה שמאפשר תנועה ביציאות TCP‏ 12345 ו-12346 ממכונות וירטואליות עם תג הרשת dataflow למכונות וירטואליות אחרות עם אותו תג:

gcloud compute firewall-rules create FIREWALL_RULE_NAME_INGRESS \
    --action=allow \
    --direction=ingress \
    --network=NETWORK  \
    --target-tags=CUSTOM_TAG \
    --source-tags=CUSTOM_TAG \
    --priority=PRIORITY_NUM \
    --rules tcp:12345-12346

מחליפים את מה שכתוב בשדות הבאים:

• ‫FIREWALL_RULE_NAME_INGRESS: שם לכלל של חומת האש

• ‫NETWORK: השם של הרשת שבה משתמשים ה-worker VMs

• ‫CUSTOM_TAG: רשימה של תגי רשת מופרדים בפסיקים

  ההנחיות הבאות מסבירות איך להשתמש בתגי רשת:

  • אם לא מציינים את --target-tags, הכלל חל על כל המכונות הווירטואליות ברשת ה-VPC.

  • אם משמיטים את --source-tags ואת כל שאר מפרטי המקור, תתאפשר תנועה מכל מקור.

  • אם לא ציינתם תגי רשת בהתאמה אישית ואתם רוצים שהכלל יהיה ספציפי למכונות וירטואליות של Dataflow, השתמשו ב-dataflow בתור תג הרשת.

  • אם ציינתם תגי רשת בהתאמה אישית ואתם רוצים שהכלל יהיה ספציפי למכונות הווירטואליות של Dataflow, השתמשו בתגי הרשת בהתאמה אישית.

• ‫PRIORITY_NUM: העדיפות של כלל חומת האש

  מספרים נמוכים יותר מייצגים עדיפויות גבוהות יותר, ו-0 היא העדיפות הגבוהה ביותר.

דוגמה לכלל חומת אש לתעבורת נתונים יוצאת (egress)

כלל חומת האש לתעבורת נתונים יוצאת מאפשר למכונות הווירטואליות של Dataflow לשלוח חבילות זו לזו. אם יצרתם כללים לחומת האש שחוסמים תעבורת נתונים יוצאת, יכול להיות שתצטרכו ליצור ברשת ה-VPC כללים מותאמים אישית לחומת האש שמאפשרים תעבורת נתונים יוצאת.

בדוגמה הזו, כלל תעבורת הנתונים היוצאת של חומת האש נוצר בשביל Dataflow, שבו לכל ה-worker VMs יש את תג הרשת שמוגדר כברירת מחדל, dataflow. בעלי פרויקט, עורכים או אדמינים של אבטחה יכולים להשתמש בפקודת gcloud הבאה כדי ליצור כלל לאישור תעבורת נתונים יוצאת, שמאפשר תעבורת נתונים מיציאות TCP‏ 12345 ו-12346 במכונות וירטואליות עם תג הרשת dataflow למכונות וירטואליות אחרות עם אותו תג:

gcloud compute firewall-rules create FIREWALL_RULE_NAME_EGRESS \
    --network=NETWORK \
    --action=allow \
    --direction=egress \
    --target-tags=CUSTOM_TAG \
    --source-tags=CUSTOM_TAG \
    --destination-ranges=DESTINATION-RANGES\
    --priority=PRIORITY_NUM  \
    --rules tcp:12345-12346

מחליפים את מה שכתוב בשדות הבאים:

• ‫FIREWALL_RULE_NAME_EGRESS: שם לכלל של חומת האש

• ‫NETWORK: השם של הרשת שבה משתמשים ה-worker VMs

• ‫CUSTOM_TAG: רשימה של תגי רשת מופרדים בפסיקים

  ההנחיות הבאות מסבירות איך להשתמש בתגי רשת:

  • אם לא מציינים את --target-tags, הכלל חל על כל המכונות הווירטואליות ברשת ה-VPC.

  • אם משמיטים את --source-tags ואת כל שאר מפרטי המקור, תתאפשר תנועה מכל מקור.

  • אם לא ציינתם תגי רשת בהתאמה אישית ואתם רוצים שהכלל יהיה ספציפי למכונות וירטואליות של Dataflow, השתמשו ב-dataflow בתור תג הרשת.

  • אם ציינתם תגי רשת בהתאמה אישית ואתם רוצים שהכלל יהיה ספציפי למכונות הווירטואליות של Dataflow, השתמשו בתגי הרשת בהתאמה אישית.

• ‫DESTINATION-RANGES: רשימה מופרדת בפסיקים של CIDR

  כולל את טווח כתובות ה-IP הראשי של רשת המשנה שנבחרה.

• ‫PRIORITY_NUM: העדיפות של כלל חומת האש

  מספרים נמוכים יותר מייצגים עדיפויות גבוהות יותר, ו-0 היא העדיפות הגבוהה ביותר.

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

גישת SSH למכונות וירטואליות של Worker

ב-Dataflow לא נדרש SSH, אבל הוא שימושי לפתרון בעיות.

אם ל-worker VM יש כתובת IP חיצונית, אתם יכולים להתחבר ל-VM באמצעות מסוף Google Cloud או באמצעות Google Cloud CLI. כדי להתחבר באמצעות SSH, צריך להגדיר כלל חומת אש שמאפשר חיבורים נכנסים ביציאת TCP‏ 22, לפחות מכתובת ה-IP של המערכת שבה מריצים את gcloud או של המערכת שבה מריצים את דפדפן האינטרנט שמשמש לגישה למסוףGoogle Cloud .

כדי לראות את הפעילות וההגדרות של הרשת, פותחים סשן SSH באחד מה-workers ומריצים את הפקודה iproute2. מידע נוסף זמין בדף iproute2 בוויקי של Linux Foundation.

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

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

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