רפליקציה של חבילות נתונים

בדף הזה מופיעה סקירה כללית של רפליקציה של חבילות נתונים ברשת VPC. אם אתם רוצים לנתח את תעבורת הרשת של עומסי העבודה שלכם בקנה מידה גדול ולעקוב אחרי תעבורת הרשת באמצעות מכשירים וירטואליים של צד שלישי, השתמשו ב-Network Security Integration Packet Mirroring. מידע נוסף זמין במאמר סקירה כללית על אינטגרציה מחוץ לפס.

התכונה רפליקציה של חבילות נתונים משכפלת את התנועה של מופעים ספציפיים ברשת ה-VPC ומעבירה אותה לבדיקה. רפליקציה של חבילות נתונים מתעדת את כל התנועה ואת נתוני המנות, כולל מטען ייעודי (payload) וכותרות. אפשר להגדיר את הלכידה לתעבורת נתונים יוצאת (egress) ונכנסת (ingress), רק לתעבורת נתונים נכנסת או רק לתעבורת נתונים יוצאת.

השיקוף מתבצע במופעים של מכונות וירטואליות (VM), ולא ברשת. כתוצאה מכך, רפליקציה של חבילות נתונים צורכת רוחב פס נוסף במכונות הווירטואליות.

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

איך זה עובד

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

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

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

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

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

סינון

כברירת מחדל, התכונה 'רפליקציה של חבילות נתונים' אוספת את כל תעבורת הנתונים של IPv4 במופעים משוכפלים. במקום לאסוף את כל תעבורת הנתונים של IPv4, אפשר להשתמש במסננים כדי להרחיב את תעבורת הנתונים שנאספת כך שתכלול את כל תעבורת הנתונים של IPv6 או חלק ממנה. אפשר גם להשתמש במסננים כדי לצמצם את התנועה שמשוכפלת, וכך להגביל את רוחב הפס שמשמש את המופעים המשוכפלים.

אתם יכולים להגדיר מסננים לאיסוף תעבורת נתונים לפי פרוטוקול, טווחי CIDR ‏(IPv4,‏ IPv6 או שניהם), כיוון תעבורת הנתונים (נכנסת בלבד, יוצאת בלבד או שניהם) או שילוב של האפשרויות האלה.

סדר המדיניות

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

בהתאם למסנן של כל מדיניות, Google Cloud המערכת בוחרת מדיניות לכל זרימה. אם יש לכם מדיניות שונה, Google Cloud משתמש במדיניות המתאימה לתנועה המשוכפלת. לדוגמה, יכול להיות שיש לכם מדיניות אחת עם המסנן 198.51.100.3/24:TCP ומדיניות אחרת עם המסנן 2001:db8::/64:TCP:UDP. המדיניות הזו שונה מהמדיניות של Google Cloud , ולכן אין ספק לגבי המדיניות שבה נעשה שימוש.

עם זאת, אם יש לכם מדיניות חופפת, Google Cloud המסננים שלה מוערכים כדי לבחור באיזו מדיניות להשתמש. לדוגמה, יכול להיות שיש לכם שתי מדיניות, אחת עם מסנן ל-10.0.0.0/24:TCP ואחת ל-10.0.0.0/16:TCP. יש חפיפה בין המדיניות האלה כי יש חפיפה בין טווחי ה-CIDR שלהן.

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

Google Cloud בוחר מדיניות על סמך מסנן:

  • אם למדיניות יש טווחי CIDR שונים אבל חופפים, ואותם פרוטוקולים בדיוק, Google Cloud בוחר את המדיניות שמשתמשת בטווח ה-CIDR הספציפי ביותר. נניח שהיעד של חבילת TCP שיוצאת ממופע משוכפל הוא 10.240.1.4, ויש שתי מדיניות עם המסננים הבאים: 10.240.1.0/24:ALL ו-10.240.0.0/16:TCP. ההתאמה הספציפית ביותר ל-10.240.1.4 היא 10.240.1.0/24:ALL, ולכןGoogle Cloud משתמש במדיניות עם המסנן 10.240.1.0/24:ALL.

  • אם במדיניות מצוין אותו טווח CIDR בדיוק עם פרוטוקולים חופפים,Google Cloud בוחר במדיניות עם הפרוטוקול הספציפי ביותר. לדוגמה, למסננים הבאים יש את אותו טווח אבל פרוטוקולים חופפים: 10.240.1.0/24:TCP ו-10.240.1.0/24:ALL. כדי להתאים לתנועת TCP,‏ Google Cloud משתמש במדיניות 10.240.1.0/24:TCP. המדיניות של 10.240.1.0/24:ALL חלה על תנועת גולשים תואמת לכל הפרוטוקולים האחרים.

  • אם למדיניות יש בדיוק את אותו טווח CIDR אבל פרוטוקולים שונים, המדיניות לא חופפת. Google Cloud משתמש במדיניות שמתאימה לפרוטוקול של תעבורת הנתונים המשוכפלת. לדוגמה, יכול להיות שיש לכם מדיניות ל-2001:db8::/64:TCP ומדיניות אחרת ל-2001:db8::/64:UDP. בהתאם לפרוטוקול של תעבורת הנתונים המשוכפלת, Google Cloud משתמש במדיניות TCP או UDP.

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

VPC Flow Logs

‫VPC Flow Logs לא מתעד מנות משוכפלות. אם מופעלים יומני תעבורה של VPC ברשת משנה שבה נמצא מופע של אוסף נתונים, התעבורה שנשלחת ישירות למופע של אוסף הנתונים מתועדת, כולל תעבורה ממופעים משוכפלים. כלומר, אם כתובת היעד המקורית של IPv4 או IPv6 תואמת לכתובת IPv4 או IPv6 של מופע האוסף, הזרימה מתועדת.

מידע נוסף על VPC Flow Logs זמין במאמר שימוש ב-VPC Flow Logs.

מאפיינים מרכזיים

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

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

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

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

  • אי אפשר לשקף ולאסוף תעבורה באותו ממשק רשת של מופע מכונה וירטואלית, כי פעולה כזו תגרום ללולאת שיקוף.

  • כדי לשקף את התעבורה שעוברת בין Pods באותו צומת Google Kubernetes Engine ‏ (GKE), צריך להפעיל Intranode visibility באשכול.

  • כדי לשכפל תעבורת IPv6, משתמשים במסננים כדי לציין את טווחי ה-CIDR של IPv6 של תעבורת ה-IPv6 שרוצים לשכפל. אתם יכולים לשכפל את כל תעבורת הנתונים ב-IPv6 באמצעות מסנן טווח CIDR של ::/0. אפשר לשכפל את כל תעבורת הנתונים של IPv4 ו-IPv6 באמצעות המסנן הבא של טווח CIDR מופרד בפסיקים: 0.0.0.0/0,::/0.

  • שיקוף התנועה צורך רוחב פס במופע המשוקף. לדוגמה, אם מכונה משוכפלת חווה תעבורת נתונים נכנסת של 1Gbps ותעבורת נתונים יוצאת של 1Gbps, תעבורת הנתונים הכוללת במכונות היא 1Gbps של תעבורת נתונים נכנסת ו-3Gbps של תעבורת נתונים יוצאת (1Gbps של תעבורת נתונים יוצאת רגילה ו-2Gbps של תעבורת נתונים יוצאת משוכפלת). כדי להגביל את התנועה שנאספת, אפשר להשתמש במסננים.

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

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

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

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

    • 5 תת-רשתות
    • ‫5 תגים
    • ‫50 מקרים

  • המספר המקסימלי של מסנני שיקוף מנות הוא 30, שהוא המספר של טווחי כתובות IPv4 ו-IPv6 כפול מספר הפרוטוקולים. לדוגמה, אפשר לציין 30 טווחים ופרוטוקול אחד, כלומר 30 מסננים. עם זאת, אי אפשר לציין 30 טווחי כתובות ו-2 פרוטוקולים, כי זה יוצר 60 מסננים, יותר מהמספר המקסימלי.

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

תרחישים לדוגמה

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

אבטחה לארגונים

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

לדוגמה, כדי להשתמש בכלי האבטחה הבאים, צריך ללכוד כמה חבילות:

  • כדי שמערכות לגילוי חדירות (IDS) יוכלו לזהות איומים מתמשכים, הן צריכות להתאים חתימה לכמה מנות של זרימה אחת.

  • מנועי בדיקה מעמיקה של מנות בודקים את נתוני המנות כדי לזהות אנומליות בפרוטוקול.

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

מעקב אחרי ביצועי אפליקציות

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

לדוגמה, מהנדסי רשת יכולים להשתמש בנתונים מ-Packet Mirroring כדי לבצע את המשימות הבאות:

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

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

דוגמאות לטופולוגיות של יעדי איסוף

אפשר להשתמש ברפליקציה של חבילות נתונים במגוון תצורות. בדוגמאות הבאות מוצג המיקום של יעדי איסוף הנתונים והמדיניות שלהם עבור תצורות שונות של רפליקציה של חבילות נתונים, כמו קישור בין רשתות VPC שכנות (peering) ו-VPC משותף.

יעד של איסוף נתונים באותה רשת

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

מדיניות רפליקציה של חבילות נתונים עם מקור משוכפל ואוסף יעד באותה רשת VPC.
מדיניות שיקוף מנות שכוללת את כל המשאבים באותה רשת VPC (לחצו כדי להגדיל).

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

יעד של אוסף ברשת עמיתים

אתם יכולים ליצור מודל מרכזי של איסוף נתונים, שבו מופעים ברשתות VPC שונות שולחים תעבורה משוכפלת ליעד איסוף ברשת VPC מרכזית. כך תוכלו להשתמש בכלי איסוף יחיד של נתוני יעד.

בדוגמה הבאה, מאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי collector-load-balancer נמצא באזור us-central1 ברשת ה-VPC‏ network-a ב-project-a. אפשר להשתמש באוסף היעד הזה בשתי מדיניות רפליקציה של חבילות נתונים:

  • ‫policy-1 אוסף חבילות ממקורות משוכפלים באזור us-central1 ברשת ה-VPC ‏network-a ב-project-a ושולח אותן ליעד collector-load-balancer.

  • ‫policy-2 אוסף חבילות ממקורות משוכפלים באזור us-central1 ברשת ה-VPC‏ network-b ב-project-b ושולח אותן לאותו יעד collector-load-balancer.

צריך שני כללי מדיניות של שיקוף כי מקורות משוקפים קיימים ברשתות VPC שונות.

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

בתרשים הקודם, יעד האוסף אוסף תנועה משוכפלת מרשתות משנה בשתי רשתות שונות. כל המשאבים (המקור והיעד) צריכים להיות באותו אזור. ההגדרה ב-network-a דומה לדוגמה שבה מקור המשוכפל ויעד האיסוף נמצאים באותה רשת VPC. ‫policy-1 מוגדר לאיסוף תנועה מ-subnet-a ולשליחה שלה אל collector-ilb.

המדפסת policy-2 מוגדרת ב-project-a אבל מצוינת כמקור משוקף subnet-b. מכיוון ש-network-a ו-network-b הם עמיתים, האוסף ביעד יכול לאסוף תנועה מ-subnet-b.

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

  • אם הבעלים של project-a יוצרים את מדיניות הרפליקציה של חבילות הנתונים, הם צריכים לקבל את התפקיד compute.packetMirroringAdmin ברשת, ברשת המשנה או במופעים שמשוכפלים ב-project-b.

  • אם הבעלים של project-b יוצרים את מדיניות הרפליקציה של חבילות הנתונים, צריך להיות להם תפקיד compute.packetMirroringUser ב-project-a.

מידע נוסף על הפעלת קישוריות פרטית בין שתי רשתות VPC זמין במאמר VPC Network Peering.

VPC משותף

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

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

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

יעד של כלי האיסוף בפרויקט השירות

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

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

בתרשים הקודם, פרויקט השירות מכיל את מופעי האוסף שמשתמשים בתת-רשת של האוסף ברשת ה-VPC המשותפת. מדיניות שיקוף החבילות נוצרה בפרויקט השירות והיא מוגדרת לשקף מופעים שיש להם ממשק רשת ב-subnet-mirrored.

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

יעד של השרת לאיסוף נתונים בפרויקט המארח

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

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

הקשר בין הפרויקט המארח לפרויקט השירות ב-Packet Mirroring.
יעד של מאסף בפרויקט המארח (לחצו כדי להגדיל).

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

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

מכונות וירטואליות עם כמה ממשקי רשת

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

מדיניות יכולה לשקף משאבים רק מרשת אחת. אם למופע עם כמה כרטיסי רשת (NIC) יש ממשקי רשת ברשתות שונות, אי אפשר ליצור מדיניות אחת לשיקוף התנועה לכל ממשקי הרשת. אם אתם צריכים לשכפל ממשקי רשת נוספים שמצורפים לרשתות שונות, אתם צריכים ליצור מדיניות אחת לרפליקציה של חבילות הנתונים לכל ממשק.

תמחור

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

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

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