יצירת תחום העברה

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

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

• ההבדלים בין ניתוב רגיל לניתוב פרטי, כפי שמתואר בקטע יעדי העברה ושיטות ניתוב
• שיטות העברת ה-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, יוצרים כלל של חומת אש שמאפשר תעבורת נתונים נכנסת (ingress) ביציאה 53 של TCP ו-UDP, שחלה על יעדי ההעברה בכל רשת VPC מורשית. ליעדים מסוג 2, צריך להגדיר חומת אש מקומית וציוד דומה כדי לאפשר את יציאת ה-TCP ו-UDP 53.

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

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

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

  ליעדים מסוג 1, Trusted Cloud משתמש בנתיב ניתוב מיוחד ליעד 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 מתעלם מהתגובה. מטעמי אבטחה, Trusted Cloud מצפה שכתובת המקור של התשובה של כל שרת שמות יעד ב-DNS תתאים לכתובת ה-IP של יעד ההעברה.

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

אי אפשר לשלוח תשובות מיעדים להעברה מסוג 2 דרך האינטרנט או דרך רשת VPC אחרת ב-Cloud DNS. התשובות חייבות לחזור לאותה רשת 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 של היעד. לאחר מכן, אפשר לפתור את יעד ההעברה המפורט לכתובות IP של עד 50 מכשירים, שיכולות להיות כתובות IPv4 או IPv6. בהתאם לרשת של יעד ההעברה המאוחד, ליעד מסוג 4 יש את אותן דרישות רשת כמו ליעד מסוג 1, 2 או 3.

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

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

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