יצירת אזור העברה

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

לפני שמתחילים, חשוב לוודא שהבנתם את הנקודות הבאות:

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

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

gcloud dns managed-zones create NAME \
    --description=DESCRIPTION \
    --dns-name=DNS_SUFFIX \
    --networks=VPC_NETWORK_LIST \
    --forwarding-targets=FORWARDING_TARGETS_LIST \
    --private-forwarding-targets=PRIVATE_FORWARDING_TARGETS_LIST \
    --visibility=private

resource "google_dns_managed_zone" "private_zone" {
  name        = "private-zone"
  dns_name    = "private.example.com."
  description = "Example private DNS zone"
  labels = {
    foo = "bar"
  }

  visibility = "private"

  private_visibility_config {
    networks {
      network_url = google_compute_network.network_1.id
    }
    networks {
      network_url = google_compute_network.network_2.id
    }
  }

  forwarding_config {
    target_name_servers {
      ipv4_address = "172.16.1.10"
    }
    target_name_servers {
      ipv4_address = "172.16.1.20"
    }
  }
}

resource "google_compute_network" "network_1" {
  name                    = "network-1"
  auto_create_subnetworks = false
}

resource "google_compute_network" "network_2" {
  name                    = "network-2"
  auto_create_subnetworks = false
}

POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones
{

    "name": "NAME",
    "description": "DESCRIPTION",
    "dnsName": "DNS_NAME",
    "visibility": "private"
    "privateVisibilityConfig": {
        "kind": "dns#managedZonePrivateVisibilityConfig",
        "networks": [{
                "kind": "dns#managedZonePrivateVisibilityConfigNetwork",
                "networkUrl": VPC_NETWORK_1
            },
            {
                "kind": "dns#managedZonePrivateVisibilityConfigNetwork",
                "networkUrl": VPC_NETWORK_2
            },
            ....
        ]
    },
    "forwardingConfig": {
        "kind": "dns#managedZoneForwardingConfig",
        "targetNameServers": [{
                "kind": "dns#managedZoneForwardingConfigNameServerTarget",
                "ipv4Address": FORWARDING_TARGET_1
            },
            {
                "kind": "dns#managedZoneForwardingConfigNameServerTarget",
                "ipv4Address": FORWARDING_TARGET_2
            },
            ....
        ]
    },
}

דרישות לגבי רשתות יעד להעברת נתונים

כש-Cloud DNS שולח בקשות ליעדי העברה, הוא שולח חבילות עם טווחי המקור שמופיעים בטבלה הבאה.

יעדים מסוג 1 ויעדים מסוג 2

כדי לגשת ליעד מסוג 1 או מסוג 2, צריך להגדיר את הדברים הבאים ב-Cloud DNS. הדרישות האלה זהות בין אם היעד הוא כתובת IP מסוג RFC 1918 ואתם משתמשים בניתוב רגיל, ובין אם אתם בוחרים בניתוב פרטי:

• הגדרת חומת אש עבור 177.222.82.0/25

  למטרות יעד מסוג 1, יוצרים כלל חומת אש שמאפשר תעבורת נתונים נכנסת ביציאות TCP ו-UDP‏ 53, שרלוונטי למטרות ההעברה ברשתות ה-VPC המורשות. עבור יעדים מסוג 2, צריך להגדיר חומת אש ברשת מקומית וציוד דומה כדי לאפשר יציאת TCP ו-UDP 53.

• ניתוב ליעד ההעברה

  עבור יעדים מסוג 1, ‏ Cloud DNS משתמש בניתוב תת-רשת כדי לגשת ליעד ברשת ה-VPC שאושרה לשימוש באזור ההעברה. כדי לגשת ליעד ההעברה, Cloud DNS משתמש במסלולים דינמיים מותאמים אישית או במסלולים סטטיים מותאמים אישית, למעט מסלולים סטטיים מתויגים, עבור יעדי שמות מסוג 2.

• נתיב חזרה אל 177.222.82.0/25 דרך אותה רשת VPC

  ליעדים מסוג 1, Cloud de Confiance המערכת משתמשת בנתיב ניתוב מיוחד עבור 177.222.82.0/25היעד. במטרות מסוג 2, ברשת המקומית צריך להיות נתיב ליעד 177.222.82.0/25, שהניתוב הבא שלו הוא באותה רשת VPC שממנה הגיעה הבקשה, דרך מנהרת Cloud VPN או צירוף ל-VLAN ל-Cloud Interconnect. מידע על עמידה בדרישה הזו זמין במאמר בנושא אסטרטגיות של מסלולי חזרה ליעדים מסוג 2.

• תגובה ישירה מהיעד

  ב-Cloud DNS, יעד ההעברה שמקבל חבילות חייב להיות זה ששולח תשובות ל-177.222.82.0/25. אם יעד ההעברה שולח את הבקשה לשרת שמות אחר, ושרת השמות האחר הזה מגיב ל-177.222.82.0/25, מערכת Cloud DNS מתעלמת מהתגובה. מטעמי אבטחה,מערכת Cloud de Confiance מצפה שכתובת המקור של תשובת ה-DNS של כל שרת שמות יעד תהיה זהה לכתובת ה-IP של יעד ההעברה.

שיטות לניתוב החזרה ליעדים מסוג 2

‫Cloud DNS לא יכול לשלוח תגובות מיעדי העברה מסוג 2 דרך האינטרנט או דרך רשת VPC אחרת. התשובות חייבות לחזור לאותה רשת VPC, אבל הן יכולות להשתמש בכל מנהרת Cloud VPN או בכל צירוף ל-VLAN באותה רשת.

• למנהרות Cloud VPN שמשתמשות בניתוב סטטי, צריך ליצור באופן ידני נתיב ברשת המקומית שהיעד שלו הוא 177.222.82.0/25 והקפיצה הבאה שלו היא מנהרת Cloud VPN. במנהרות Cloud VPN שמשתמשות בניתוח נתיבים מבוסס-מדיניות, צריך להגדיר את בורר התנועה המקומית של Cloud VPN ואת בורר התנועה המרוחקת של שער ה-VPN המקומי כך שיכללו את 177.222.82.0/25.
• במנהרות Cloud VPN שמשתמשות בניתוב דינמי או ב-Cloud Interconnect, צריך להגדיר פרסום של מסלול מותאם אישית עבור 177.222.82.0/25 בסשן BGP של Cloud Router שמנהל את המנהרה או את חיבור ה-VLAN.

יעדים מסוג 4

יעד מסוג 4 קודם כול פותר את כתובות ה-IP של היעד. אפשר לפתור את בעיית היעד להעברה קדימה על ידי שימוש בעד 50 כתובות IP, כולל כתובות IPv4 ו-IPv6. בהתאם לרשת של יעד ההעברה שנפתר, ליעד מסוג 4 יש את אותן דרישות רשת כמו ליעד מסוג 1, 2 או 3.

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

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

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