נבדק לאחרונה: מאי 2026
בנו את שירותי AWS של בחינת PCNE עם Terraform פשוט — בלוק אחד בכל פעם, כאשר כל אחד מהם מקושר בחזרה לתחום במבחן. אותו הקוד עובד גם ב-OpenTofu.
עד סוף מעבדה זו תספק, באמצעות Terraform רגיל, תשתית רשת בתצורת PCNE — הפעלת פרויקט מארח ב-Shared VPC, VPC מותאם אישית עם תת-רשת אזורית אחת המשתמשת ב-Private Google Access, נתב ענן (Cloud Router) + NAT ענן (Cloud NAT) ליציאה בלבד, שני כללי חומת אש עם יומני זרימה של VPC (VPC Flow Logs) על תת-הרשת, ואזור פרטי של Cloud DNS לרזולוציית שמות פנימית. חמש אבני בניין; תצורת הייחוס של PCNE: VPC רכזת + יציאה + DNS.
הכנס את הקטעים לקובץ main.tf אחד, הרץ terraform init, ולאחר מכן terraform apply צעד אחר צעד.
הערה: מעבדת פרויקט יחיד זו מדגימה את הפעלת פרויקט מארח של Shared VPC אך אינה משתפת בפועל את ה-VPC עם פרויקט שירות אחר (שדורש הרשאות מנהל ארגוני + שני פרויקטים, וזה מחוץ לתחום מעבדה מהירה).
>= 1.5 או OpenTofu >= 1.6.roles/compute.xpnAdmin בהיקף ארגוני — ללא הרשאות ברמת הארגון, המשאב google_compute_shared_vpc_host_project ייכשל. דלג על שלב 2 והסר אותו מ-main.tf אם יש לך רק הרשאות ברמת הפרויקט.your-project-id בבלוק ה-provider.כמעט בחינם:
כ-0$/חודש. זול להשאיר פועל.
הפעל את ממשקי ה-API של Compute, DNS ו-Logging.
terraform {
required_version = ">= 1.5"
required_providers {
google = { source = "hashicorp/google", version = "~> 6.0" }
}
}
provider "google" {
project = "your-project-id" # REPLACE
region = "us-central1"
}
locals {
labels = {
project = "certlabpro-pcne"
managed_by = "terraform"
}
}
resource "google_project_service" "compute" {
service = "compute.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "dns" {
service = "dns.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "logging" {
service = "logging.googleapis.com"
disable_on_destroy = false
}Shared VPC הוא תבנית הרשת הרב-פרויקטים הקאנונית של PCNE — פרויקט מארח אחד מחזיק ב-VPC, מספר פרויקטי שירות צורכים אותו באמצעות חיבורים. עומסי עבודה בפרויקטי שירות מקבלים כתובות IP מתת-הרשתות של ה-VPC המארח מבלי שהפרויקט המארח יהיה הבעלים של משאבי שכבת העבודה. בחינת PCNE בודקת את ההפרדה הזו של מארח מול שירות כתבנית קנה מידה נושאת עומס.
אנו מפעילים מצב פרויקט מארח בפרויקט הנוכחי (google_compute_shared_vpc_host_project), ולאחר מכן יוצרים תת-רשת /20 עם Private Google Access מופעל (המאפשר ל-VMs ללא כתובות IP חיצוניות להגיע ל-*.googleapis.com) וVPC Flow Logs מופעלים.
data "google_project" "current" {}
resource "google_compute_shared_vpc_host_project" "host" {
project = data.google_project.current.project_id
depends_on = [google_project_service.compute]
}
resource "google_compute_network" "main" {
name = "certlabpro-pcne-vpc"
auto_create_subnetworks = false
routing_mode = "REGIONAL"
depends_on = [google_project_service.compute]
}
resource "google_compute_subnetwork" "main" {
name = "certlabpro-pcne-subnet"
ip_cidr_range = "10.10.0.0/20"
region = "us-central1"
network = google_compute_network.main.id
private_ip_google_access = true
log_config {
aggregation_interval = "INTERVAL_5_SEC"
flow_sampling = 0.5
metadata = "INCLUDE_ALL_METADATA"
}
}Cloud NAT מעניק לתת-רשתות גישת אינטרנט יוצאת ללא כתובות IP חיצוניות לכל VM — תבנית היציאה הקאנונית של PCNE פרטי כברירת מחדל. התצורה: Cloud Router הוא הפרימיטיב של שכבת הבקרה של BGP (בשימוש על ידי NAT, VPN, Interconnect); Cloud NAT מתחבר אליו ומספק את שכבת הנתונים.
אנו מפעילים NAT עם הקצאת IP של NAT מסוג AUTO_ONLY (גוגל בוחרת את הכתובות; פריסות בייצור מקבעות כתובות IP שמורות ספציפיות לרשימות היתרים של חומת אש קדמית). רישום יומן לשגיאות בלבד — מצב רישום יומן מלא מייצר נפח ניכר של Cloud Logging.
resource "google_compute_router" "nat_router" {
name = "certlabpro-pcne-router"
region = "us-central1"
network = google_compute_network.main.id
}
resource "google_compute_router_nat" "nat" {
name = "certlabpro-pcne-nat"
router = google_compute_router.nat_router.name
region = "us-central1"
nat_ip_allocate_option = "AUTO_ONLY"
source_subnetwork_ip_ranges_to_nat = "LIST_OF_SUBNETWORKS"
subnetwork {
name = google_compute_subnetwork.main.id
source_ip_ranges_to_nat = ["ALL_IP_RANGES"]
}
log_config {
enable = true
filter = "ERRORS_ONLY"
}
}תצורת חומת האש המומלצת ב-PCNE: מניעת כניסה כברירת מחדל (ברירת המחדל של GCP), אפשור רק מה שנחוץ. אנו מוסיפים אישור פנימי לכל (כל TCP / UDP / ICMP בין VMs בתת-הרשת) + אישור IAP SSH (TCP/22 מטווח שער ה-IAP של גוגל, כך ש-VMs ללא כתובות IP ציבוריות עדיין נגישים באמצעות SSH דרך gcloud compute ssh --tunnel-through-iap).
זוהי אותה תבנית של שני כללים כמו במעבדת ACE — PCNE מעמיק אותה עם מדיניות חומת אש בהיקף ארגוני / תיקיות (חומות אש היררכיות המשתלבות עם כללים ברמת הפרויקט; מחוץ לתחום כאן).
resource "google_compute_firewall" "allow_internal" {
name = "certlabpro-pcne-allow-internal"
network = google_compute_network.main.name
direction = "INGRESS"
source_ranges = ["10.10.0.0/20"]
allow {
protocol = "tcp"
}
allow {
protocol = "udp"
}
allow {
protocol = "icmp"
}
}
resource "google_compute_firewall" "allow_iap_ssh" {
name = "certlabpro-pcne-allow-iap-ssh"
network = google_compute_network.main.name
direction = "INGRESS"
source_ranges = ["35.235.240.0/20"]
allow {
protocol = "tcp"
ports = ["22"]
}
}תבנית קאנונית של PCNE: שמות מארחים פנימיים נפתרים באמצעות אזור פרטי של Cloud DNS המצורף ל-VPC. VMs ב-VPC רואים את רשומות האזור הזה; VMs מחוץ ל-VPC אינם רואים אותם. מקרה שימוש: שמות מארחים יציבים וקריאים לבני אדם עבור שירותים (api.internal.acme.com, db.internal.acme.com) הנפתרים לכתובת ה-IP הפרטית של ה-VM.
אנו יוצרים את האזור internal.acme.com + רשומת A לדוגמה אחת. פריסות בייצור לרוב משלבות זאת עם העברת DNS של Cloud DNS עבור הגדרות היברידיות (שאילתות DNS מקומיות מועברות לאזור הענן, ולהיפך באמצעות מדיניות שרת נכנסת). עם חמשת אבני הבניין במקומן (provider+APIs, Shared VPC + תת-רשת + יומני זרימה, Cloud NAT, חומות אש, אזור פרטי של Cloud DNS), תשתית ה-PCNE מושלמת.
resource "google_dns_managed_zone" "internal" {
name = "certlabpro-pcne-internal"
dns_name = "internal.acme.com."
description = "PCNE lab private DNS zone"
visibility = "private"
private_visibility_config {
networks {
network_url = google_compute_network.main.id
}
}
labels = local.labels
depends_on = [google_project_service.dns]
}
resource "google_dns_record_set" "api_example" {
managed_zone = google_dns_managed_zone.internal.name
name = "api.${google_dns_managed_zone.internal.dns_name}"
type = "A"
ttl = 300
rrdatas = ["10.10.0.10"]
}terraform destroy מפרק הכל. פרויקט מארח של Shared VPC מושבת (יש להסיר קודם כל חיבורי פרויקטי שירות — אין כאלה במעבדה זו). Cloud NAT + router מתנתקים בצורה נקייה. VPC + תת-רשת + חומות אש נהרסים. אזור פרטי של Cloud DNS נהרס (רשומת הדוגמה נמחקת יחד איתו). VPC Flow Logs מפסיקים לקלוט נתונים.
PCNE מכסה משטחי רשת רבים שמעבדה זו אינה יכולה להכיל — Cloud VPN (HA / Classic), Cloud Interconnect (Dedicated / Partner), Network Connectivity Center (NCC — מישור הבקרה של hub-and-spoke), Cross-Cloud Interconnect, Private Service Connect (PSC עבור תבניות שירות / נקודת קצה / מפרסם), VPC Peering בין VPCs (נפרד מ-Shared VPC), Cloud Load Balancing (כל משפחת ה-LB — HTTP(S) גלובלי, פנימי אזורי, network LB, proxy network LB), Cloud CDN, Cloud Armor (WAF / DDoS), Identity-Aware Proxy (IAP), העברת DNS של Cloud DNS / מדיניות שרת נכנסת (תצורת ה-DNS ההיברידית), Cloud DNS DNSSEC, תצורת Default Firewall Rules המיושנת, מדיניות חומת אש היררכית בהיקף ארגוני / תיקיות, Network Intelligence Center (בדיקות קישוריות / לוח מחוונים ביצועים / תובנות חומת אש / טופולוגיית רשת), והיקפי VPC Service Controls (מכוסים ב- [[gcp-pcse]] מזווית מניעת דליפת נתונים).
אנו נצמדים לפרימיטיבים של Shared VPC + תת-רשת + NAT + חומת אש + DNS פרטי מכיוון שהם הבסיס של PCNE שכל תבנית רשת מתקדמת יותר מתבססת עליו. Cloud VPN / Interconnect מתחברים לאותו Cloud Router. Load Balancers עומדים לפני אותם VMs המוגנים בחומת אש. PSC מפרסם שירותים לאותו VPC. חומות אש היררכיות מורכבות מעל הכללים ברמת הפרויקט. שלוט בתשתית.
לכיסוי קונספטואלי לפי שירות, עיין במקטעים עיון, מדריך, ו-Editorial בדף אישור זה.