लोड बैलेंसर के लिए Cloud NGFW Essentials

1. परिचय

इस कोडलैब में, इंटरनल ऐप्लिकेशन लोड बैलेंसर (एएलबी) और प्रॉक्सी नेटवर्क लोड बैलेंसर (एनएलबी) के लिए, Cloud Next Generation Firewall (NGFW) Essentials के बारे में बताया गया है. इसमें क्षेत्रीय नेटवर्क फ़ायरवॉल की नीतियों का इस्तेमाल किया गया है.

Cloud NGFW, पूरी तरह से डिस्ट्रिब्यूट की गई फ़ायरवॉल सेवा है. इसमें खतरों से बचाने की बेहतर सुविधाएं और माइक्रो-सेगमेंटेशन की क्षमताएं होती हैं. इनकी मदद से, Google Cloud वर्कलोड को सुरक्षित रखा जा सकता है. लोड बैलेंसर लेवल पर Cloud NGFW चालू करने से, फ़ायरवॉल की नीति से जुड़े नियम, इंटरनल प्रॉक्सी पर आधारित लोड बैलेंसर में आने वाले किसी भी TCP ट्रैफ़िक पर लागू होते हैं. इससे संगठन के लिए सुरक्षा से जुड़ी सेटिंग को आसानी से कॉन्फ़िगर किया जा सकता है. इसके लिए, सभी सेवाओं पर नीतियों को ज़्यादा बेहतर तरीके से लागू किया जाता है.

इस कोडलैब में, Cloud NGFW और Cloud Load Balancer के इन प्रॉडक्ट और सुविधाओं के बारे में बताया गया है:

Cloud NGFW Essentials
देश या इलाके के हिसाब से नेटवर्क फ़ायरवॉल की नीतियां
रीजनल इंटरनल ऐप्लिकेशन लोड बैलेंसर
बैकएंड मैनेज किया गया इंस्टेंस ग्रुप (एमआईजी) और Private Service Connect (पीएससी) नेटवर्क एंडपॉइंट ग्रुप (एनईजी)

ध्यान दें: लोड बैलेंसर टारगेट के लिए फ़ायरवॉल नीति के नियमों से जुड़ी, नई सुविधाओं और सीमाओं के बारे में जानने के लिए, Cloud NFGW का दस्तावेज़ देखें.

आपको ये सब सीखने को मिलेगा

लोड बैलेंसर को टारगेट करने वाले, Cloud NGFW की फ़ायरवॉल नीति के बुनियादी नियमों को चालू करना
वीएम इंस्टेंस और पीएससी बैकएंड की मदद से, इंटरनल कंज्यूमर लोड बैलेंसर सेवा को सुरक्षित करना
क्लाइंट के ऐक्सेस की जांच करना और फ़ायरवॉल लॉग की पुष्टि करना

आपको इन चीज़ों की ज़रूरत पड़ेगी

Google Cloud प्रोजेक्ट
Google Cloud के नेटवर्किंग कॉन्सेप्ट और Google Cloud CLI का इस्तेमाल करने के बारे में जानकारी
IAM अनुमतियां: roles/compute.instanceAdmin.v1, roles/compute.networkAdmin, roles/compute.securityAdmin, और roles/storage.admin

2. कॉन्सेप्ट

फ़ायरवॉल की सुविधाओं के टियर

Cloud NGFW में तीन सुविधा टियर होते हैं: Essentials, Standard, और Enterprise. हर प्रोग्रेसिव टियर में, नेटवर्क ट्रैफ़िक को फ़िल्टर करने और उसकी जांच करने की अतिरिक्त सुविधाएं मिलती हैं.

Cloud NGFW Essentials की फ़िल्टर करने की सुविधाओं के बारे में खास जानकारी:

टियर	अनुमति	नेटवर्क लेयर	नियम के पैरामीटर के उदाहरण
Essentials	आईपी पते और रेंज के हिसाब से फ़िल्टर करना	आईपी	`--src-ip-ranges=1.1.1.0/24,2.2.2.2/32`
Essentials	पते के ग्रुप	आईपी	`--src-address-groups=special-ranges`
Essentials	प्रोटोकॉल और पोर्ट फ़िल्टर करना	टीसीपी	`--layer4-configs=tcp`
Essentials	सुरक्षित टैग	मेटाडेटा	`--src-secure-tags=tagValues/987654321098`
Essentials	नेटवर्क टाइप के हिसाब से फ़िल्टर करना	आईपी / मेटाडेटा	`--src-network-type=INTRA_VPC`

लोड बैलेंसर के फ़ॉरवर्डिंग नियमों में, डेस्टिनेशन टीसीपी पोर्ट के बारे में साफ़ तौर पर बताया जाता है. फ़ायरवॉल के नियम --layer4-configs= पैरामीटर में सिर्फ़ tcp को सेट किया जा सकता है. पोर्ट की वैल्यू, फ़ॉरवर्ड करने के नियम से ही तय होती है.

फ़ायरवॉल की नीति के नियमों को ज़्यादा असरदार बनाने के लिए, पता ग्रुप और नेटवर्क टाइप का इस्तेमाल किया जा सकता है. लोड बैलेंसर के लिए फ़ायरवॉल की नीति से जुड़े नियमों के साथ, नेटवर्क टाइप VPC_NETWORKS और INTRA_VPC काम करते हैं.

ध्यान दें: लोड बैलेंसर के लिए फ़ायरवॉल नीति के नियम, सिर्फ़ --direction=INGRESS के साथ काम करते हैं. इन नियमों को इसलिए बनाया गया है, ताकि लोड बैलेंसर की ओर से उपलब्ध कराई गई सेवाओं का ऐक्सेस कंट्रोल किया जा सके.

डेटा प्लेन फ़िल्टरिंग

Cloud NFGW Essentials की सुविधाओं में, लेयर 3 (आईपी पता) और लेयर 4 (टीसीपी पोर्ट) के बुनियादी स्टेटफ़ुल फ़ायरवॉल नियम शामिल हैं. फ़ायरवॉल नीति के नियम से जुड़ी ये सभी सुविधाएं, लोड बैलेंसर के डेटा प्लेन में बिना पूरे पैकेट की जांच किए, बेहतर तरीके से काम करती हैं.

Cloud NGFW Essentials की नीति के नियम, वीएम इंस्टेंस को टारगेट करते हैं. इन्हें डिस्ट्रिब्यूट किए गए वीपीसी नेटवर्क फ़ैब्रिक में लागू किया जाता है. यह Google Cloud के सॉफ़्टवेयर-डिफ़ाइंड नेटवर्क (Andromeda) का हिस्सा है. पैकेट फ़िल्टर करने और फ़ायरवॉल की नीति से जुड़े नियमों को, हर वीएम इंस्टेंस के हाइपरवाइज़र लेवल पर लागू किया जाता है. ऐसा तब किया जाता है, जब पैकेट वीएम इंस्टेंस के नेटवर्क इंटरफ़ेस तक पहुंचता है.

Cloud NGFW Essentials के नीति नियमों को लागू करने के लिए, Google Cloud के लोड बैलेंसर की बुनियादी टेक्नोलॉजी का इस्तेमाल किया जाता है. ये नियम, लोड बैलेंसर को टारगेट करते हैं. खास तौर पर, Envoy सेवा के प्रॉक्सी इन्फ़्रास्ट्रक्चर का इस्तेमाल किया जाता है. Cloud NFGW के एक ही रिसॉर्स मॉडल और नियम के स्ट्रक्चर का इस्तेमाल करके, स्टेटफ़ुल पैकेट फ़िल्टरिंग को सीधे तौर पर प्रॉक्सी-आधारित लोड बैलेंसर के डेटा प्लेन में लागू किया जाता है.

लोड बैलेंसर के टारगेट

लोड बैलेंसर को टारगेट करने वाली Cloud NGFW नीतियों और वीएम इंस्टेंस को टारगेट करने वाली नीतियों के बीच कुछ मुख्य अंतर होते हैं.

फ़ायरवॉल की नीति के नियमों को एक लोड बैलेंसर पर लागू किया जा सकता है. इसके लिए, लोड बैलेंसर फ़ॉरवर्डिंग के नियम --target-forwarding-rules=FR_NAME के खास रेफ़रंस के साथ --target-type=INTERNAL_MANAGED_LB तय करें. अगर आपको वीपीसी नेटवर्क के उस इलाके में सभी लोड बैलेंसर फ़ॉरवर्डिंग नियमों को टारगेट करना है जहां नीति के दायरे में इलाका आता है, तो खास रेफ़रंस को हटा देना चाहिए. साथ ही, सिर्फ़ --target-type=INTERNAL_MANAGED_LB फ़्लैग की ज़रूरत होती है.

अगर नियम के कॉन्फ़िगरेशन में --target-type पैरामीटर सेट नहीं किया गया है, तो नियम डिफ़ॉल्ट रूप से सभी वीएम इंस्टेंस पर अपने-आप लागू हो जाता है. हालांकि, यह लोड बैलेंसर पर लागू नहीं होता है.

ध्यान दें: लोड बैलेंसर के लिए, फ़ायरवॉल की नीति से जुड़े नियम का डिफ़ॉल्ट तरीका action=allow है. फ़ायरवॉल की नीतियां लागू नहीं होने पर, इंटरनल लोड बैलेंसर के लिए यह सामान्य व्यवहार है. हालांकि, यह उन लोड बैलेंसर पर भी लागू होता है जिनके साथ फ़ायरवॉल की नीतियां जुड़ी होती हैं. ऐसा तब होता है, जब पैकेट किसी भी तय किए गए नियम से मेल नहीं खाते. डिफ़ॉल्ट व्यवहार को बदलने के लिए, "सभी को अनुमति नहीं है" वाला नियम कॉन्फ़िगर करें. इस नियम की प्राथमिकता कम (ज़्यादा प्राथमिकता वाला नंबर) होनी चाहिए, ताकि यह सभी अनुरोधों पर लागू हो सके.

कोडलैब नेटवर्क

इस कोडलैब में, एक ही प्रोजेक्ट का इस्तेमाल किया जाता है. इसमें एक वीपीसी नेटवर्क और ये संसाधन होते हैं:

दो रीजनल सबनेट
एक रीजनल नेटवर्क फ़ायरवॉल नीति
तीन रीजनल इंटरनल ऐप्लिकेशन लोड बैलेंसर
- वीएम इंस्टेंस ग्रुप बैकएंड वाली www एचटीटीपी सेवा
- api वीएम इंस्टेंस ग्रुप बैकएंड वाली एचटीटीपी सेवा
- gcs Google के एपीआई के लिए, PSC NEG बैकएंड के साथ एचटीटीपीएस सेवा
अनुमति देने और अस्वीकार करने की अलग-अलग नीतियों को आज़माने के लिए, दो वीएम इंस्टेंस

पहली इमेज. कोडलैब नेटवर्क

लोड बैलेंसर को टारगेट करने वाले फ़ायरवॉल की नीति से जुड़े नियम, लोड बैलेंसर फ़ॉरवर्डिंग नियम के संसाधनों से लिंक होते हैं. लोड बैलेंसर खुद अलग-अलग संसाधनों से मिलकर बने होते हैं. इन्हें एक साथ कॉन्फ़िगर किया जाता है, ताकि लोड बैलेंसिंग की पूरी सेवा दी जा सके. फ़ॉरवर्डिंग के नियम की परिभाषा, सीधे तौर पर उस टारगेट प्रॉक्सी संसाधन का रेफ़रंस देती है जिसे इसके लिए तय किया गया है.

पहली इमेज. लोड बैलेंसर संसाधनों के लिए Cloud NFGW

Cloud NGFW Essentials फ़िल्टर को लोड बैलेंसर के डेटा प्लेन में प्रोग्राम किया जाता है. साथ ही, इन्हें टारगेट प्रॉक्सी सेवा लेयर में लागू किया जाता है. यह वीएम इंस्टेंस इंटरफ़ेस के जैसा होता है. नीतियों को लागू करने के लिए, फ़ायरवॉल के डिस्ट्रिब्यूटेड और एक जैसे मेकेनिज़्म का इस्तेमाल किया जाता है.

3. प्रोजेक्ट सेटअप करना

अपने प्रोजेक्ट को ऐक्सेस करना

इस कोडलैब में, Google Cloud के किसी एक प्रोजेक्ट का इस्तेमाल किया जाता है. कॉन्फ़िगरेशन के चरणों में, gcloud cli सीएलआई और Linux शेल कमांड का इस्तेमाल किया जाता है.

इसके लिए, सबसे पहले अपने Google Cloud प्रोजेक्ट की कमांड लाइन ऐक्सेस करें:

Cloud Shell में shell.cloud.google.com पर क्लिक करें या
gcloud सीएलआई इंस्टॉल किया गया स्थानीय टर्मिनल

प्रोजेक्ट आईडी सेट करना

gcloud config set project YOUR_PROJECT_ID_HERE

एपीआई सेवाएं चालू करना

gcloud services enable \
  cloudresourcemanager.googleapis.com \
  compute.googleapis.com \
  dns.googleapis.com \
  networksecurity.googleapis.com \
  certificatemanager.googleapis.com

शेल एनवायरमेंट वैरिएबल सेट करना

# set your region preference
export REGION_1="us-west1"

# set your zone preference
export ZONE_1="us-west1-c"

# fetch project info and verify vars set
export PROJECT_ID=$(gcloud config list --format="value(core.project)")
export PROJECT_NO=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
echo ${REGION_1}
echo ${ZONE_1}
echo ${PROJECT_ID}
echo ${PROJECT_NO}

4. नेटवर्क फ़ाउंडेशन

इस सेक्शन में, आपको इन सुविधाओं के साथ नेटवर्क फ़ाउंडेशन डिप्लॉय करने का तरीका बताया जाएगा:

ग्लोबल वीपीसी नेटवर्क और रीजनल सबनेट
VPC नेटवर्क को सुरक्षित करने के लिए, देश या इलाके के हिसाब से नेटवर्क फ़ायरवॉल की नीति
सॉफ़्टवेयर पैकेज फ़ेच करने के लिए, सर्वर के लिए Cloud Router और Cloud NAT
लोड बैलेंसर इनग्रेस के लिए आईपी पते के रिज़र्वेशन और डीएनएस रिकॉर्ड

नेटवर्क संसाधन बनाना

# create vpc network
gcloud compute networks create vnet-foo --subnet-mode=custom

# create subnet for clients
gcloud compute networks subnets create subnet-foo-1 \
  --network=vnet-foo \
  --region=${REGION_1} \
  --range=10.0.0.0/24 \
  --enable-private-ip-google-access

# create subnet for backend servers
gcloud compute networks subnets create subnet-foo-2 \
  --network=vnet-foo \
  --region=${REGION_1} \
  --range=172.16.0.0/24 \
  --enable-private-ip-google-access

# create proxy subnet
gcloud compute networks subnets create subnet-foo-3 \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --network=vnet-foo \
  --region=${REGION_1} \
  --range=172.16.128.0/23

फ़ायरवॉल कॉम्पोनेंट बनाना

यहां बनाई गई बुनियादी रीजनल नेटवर्क फ़ायरवॉल नीति का इस्तेमाल बाद में, लोड बैलेंसर के लिए खास टारगेट जोड़ते समय किया जाएगा. नीति, लोड बैलेंसर वाले क्षेत्र में ही होनी चाहिए.

पता ग्रुप बनाना

सबसे पहले, एक पता ग्रुप बनाएं. इससे लोड बैलेंसर की सुविधा के साथ काम करने वाली, सोर्स हेल्थ चेक प्रोब आईपी रेंज की पहचान की जा सकेगी. लोड बैलेंसर बैकएंड को सही तरीके से काम करने के लिए, इन रेंज की अनुमति देना ज़रूरी है. इसका इस्तेमाल बाद में, लोड बैलेंसर को टारगेट करने वाले फ़ायरवॉल की नीति से जुड़े नियमों के साथ भी किया जाएगा.

# create address group
gcloud network-security address-groups create uhc-probes \
  --description="health check probes" \
  --type=IPv4 \
  --capacity=42 \
  --location=${REGION_1}

# add ip ranges to address group
gcloud network-security address-groups add-items uhc-probes \
  --items=35.191.0.0/16,130.211.0.0/22 \
  --location=${REGION_1}

फ़ायरवॉल की नीति बनाना

# create fw policy
gcloud compute network-firewall-policies create fw-policy-foo-${REGION_1} \
  --description="foo fw ${REGION_1}" \
  --region=${REGION_1}

# create fw policy rule to allow in iap
gcloud compute network-firewall-policies rules create 1001 \
  --description="allow iap for ssh" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:22 \
  --src-ip-ranges=35.235.240.0/20

# create fw policy rule to allow in health checks
gcloud compute network-firewall-policies rules create 1002 \
  --description="allow health checks to backends" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-address-groups=projects/${PROJECT_ID}/locations/${REGION_1}/addressGroups/uhc-probes

# create fw policy rule to allow in lb proxies
gcloud compute network-firewall-policies rules create 1003 \
  --description="allow lb proxy" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:80,tcp:443,tcp:8080 \
  --src-ip-ranges=172.16.128.0/23

# associate fw policy to vnet
gcloud compute network-firewall-policies associations create \
  --name=fw-policy-association-foo-${REGION_1} \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --network=vnet-foo \
  --firewall-policy-region=${REGION_1}

नेटवर्क सेवाएं कॉन्फ़िगर करना

Cloud Router और NAT गेटवे बनाना

# create router for nat
gcloud compute routers create cr-nat-foo \
  --network=vnet-foo \
  --asn=16550 \
  --region=${REGION_1}

# create nat gateway
gcloud compute routers nats create natgw-foo \
  --router=cr-nat-foo \
  --region=${REGION_1} \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

आईपी पते रिज़र्व करना

# reserve vip for lb www service
gcloud compute addresses create vip-foo-www \
  --region=${REGION_1} \
  --subnet=subnet-foo-1 \
  --addresses=10.0.0.101

# reserve vip for lb api service
gcloud compute addresses create vip-foo-api \
  --region=${REGION_1} \
  --subnet=subnet-foo-1 \
  --addresses=10.0.0.102

# reserve vip for lb gcs service
gcloud compute addresses create vip-foo-gcs \
  --region=${REGION_1} \
  --subnet=subnet-foo-1 \
  --addresses=10.0.0.103

डीएनएस रिकॉर्ड बनाना

# create dns zone
gcloud dns managed-zones create zone-foo \
  --description="private zone for foo" \
  --dns-name=foo.com \
  --networks=vnet-foo \
  --visibility=private

# create dns record for www service
gcloud dns record-sets create www.foo.com \
  --zone=zone-foo \
  --type=A \
  --ttl=300 \
  --rrdatas="10.0.0.101"

# create dns record for api service
gcloud dns record-sets create api.foo.com \
  --zone=zone-foo \
  --type=A \
  --ttl=300 \
  --rrdatas="10.0.0.102"

# create dns record for gcs service
gcloud dns record-sets create gcs.foo.com \
  --zone=zone-foo \
  --type=A \
  --ttl=300 \
  --rrdatas="10.0.0.103"

नेटवर्क सेटअप करने का तरीका यहां खत्म होता है... अब लोड बैलेंसर कॉन्फ़िगर करने का तरीका जानें.

5. लोड बैलेंसर सेवाएं

इस सेक्शन में, तीन सेवाओं के लिए लोड बैलेंसर कॉम्पोनेंट (बैकएंड सेवाएं, यूआरएल मैप, टारगेट प्रॉक्सी, और फ़ॉरवर्डिंग के नियम) डिप्लॉय किए जाएंगे:

पोर्ट 80 पर www सेवा (ilb-foo-www)
पोर्ट 8080 पर api सेवा (ilb-foo-api)
gcs सेवा (ilb-foo-gcs) को पोर्ट 443 पर TLS सर्टिफ़िकेट के साथ इस्तेमाल किया जा रहा है

साथ ही, बैकएंड के इन संसाधनों का इस्तेमाल किया जाता है:

मैनेज किए गए इंस्टेंस ग्रुप में एचटीटीपी सर्वर चलाने वाले वीएम इंस्टेंस
Google API के लिए Private Service Connect (PSC) नेटवर्क एंडपॉइंट ग्रुप (एनईजी)
Google Cloud Storage (GCS) बकेट

बैकएंड रिसॉर्स सेट अप करना

VM इंस्टेंस ग्रुप सर्वर बनाना

www लोड बैलेंसर, वीएम इंस्टेंस ग्रुप के उन बैकएंड सर्वर का इस्तेमाल करेगा जो Apache वेब सर्वर चला रहे हैं और पोर्ट 80 पर सुन रहे हैं.

api लोड बैलेंसर, पोर्ट 8080 पर लिसन करने वाले उसी वीएम इंस्टेंस ग्रुप का इस्तेमाल करेगा.

# create vm startup config with http server
cat > vm-server-startup.sh << 'OEOF'
#! /bin/bash
set -e
apt-get update
apt-get install apache2 -y
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
vm_zone="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/zone | cut -d/ -f4)"
echo "www served from: $vm_hostname in zone $vm_zone on port 80" | \
tee /var/www/html/index.html
echo "Listen 8080" | tee -a /etc/apache2/ports.conf
mkdir -p /var/www/api
echo "api served from: $vm_hostname in zone $vm_zone on port 8080" | \
tee /var/www/api/index.html
tee /etc/apache2/sites-available/api.conf << EOF
<VirtualHost *:8080>
    DocumentRoot /var/www/api
</VirtualHost>
EOF
a2ensite api.conf
systemctl restart apache2
OEOF

# create managed instance group template
gcloud compute instance-templates create mig-template-foo \
  --machine-type=e2-micro \
  --network=vnet-foo \
  --region=${REGION_1} \
  --subnet=subnet-foo-2 \
  --no-address \
  --shielded-secure-boot \
  --metadata-from-file=startup-script=vm-server-startup.sh

# create regional managed instance group
gcloud compute instance-groups managed create mig-foo \
  --region=${REGION_1} \
  --size=2 \
  --template=mig-template-foo \
  --base-instance-name=service-foo

# create named ports for instance group
gcloud compute instance-groups managed set-named-ports mig-foo \
  --named-ports=www-port:80,api-port:8080 \
  --region=${REGION_1}

स्टोरेज बकेट बनाना

gcs लोड बैलेंसर, PSC NEG बैकएंड का इस्तेमाल करेगा. इससे वह Google APIs फ़्रंटएंड के ज़रिए Cloud Storage बकेट से कनेक्ट हो पाएगा.

# create random bucket name
export BUCKET=$(openssl rand -hex 12)
echo ${BUCKET}

ध्यान दें: शेल सेशन बंद होने के बाद, एनवायरमेंट वैरिएबल मिट जाते हैं. अगर आपको यह काम बाद में करना है, तो बकेट का नाम नोट कर लें.

# create bucket
gcloud storage buckets create gs://${BUCKET} --location=${REGION_1}

# give compute sa object admin role on bucket
gcloud storage buckets add-iam-policy-binding gs://${BUCKET} \
  --member=serviceAccount:${PROJECT_NO}-compute@developer.gserviceaccount.com \
  --role=roles/storage.objectAdmin

प्रमाणपत्र बनाएं

gcs लोड बैलेंसर, क्लाइंट के एचटीटीपीएस अनुरोधों को बंद कर देगा. इसके लिए, टारगेट एचटीटीपीएस प्रॉक्सी पर डिप्लॉय किए गए, खुद के हस्ताक्षर वाले सर्टिफ़िकेट का इस्तेमाल किया जाएगा.

# create cert
openssl req -x509 -newkey rsa:2048 \
  -nodes \
  -days 365 \
  -keyout foo-gcs-key.pem \
  -out foo-gcs-cert.pem \
  -subj "/CN=Foo, Inc." \
  -addext "subjectAltName=DNS:gcs.foo.com"

# upload to certificate manager
gcloud certificate-manager certificates create cert-foo-gcs \
  --private-key-file=foo-gcs-key.pem \
  --certificate-file=foo-gcs-cert.pem \
  --location=${REGION_1}

लोड बैलेंसर कॉम्पोनेंट बनाना

लोड बैलेंसर कॉम्पोनेंट को अपने-आप डिप्लॉय करने के लिए, इस स्क्रिप्ट का इस्तेमाल करें. इससे कॉन्फ़िगरेशन के सभी एलिमेंट को तेज़ी से और सटीक तरीके से प्रोसेस करने में मदद मिलेगी.

लोड बैलेंसर बनाने की स्क्रिप्ट डिप्लॉय करना

# create script file
cat > create_lbs.sh << EOF
#!/bin/bash
set -e

# --- Create load balancer for www service port 80 ---
echo "--- Creating Load Balancer for WWW Service (ilb-foo-www) on port 80 ---"

echo "ilb-foo-www: creating health check (hc-foo-www)"
gcloud compute health-checks create http hc-foo-www \
  --use-serving-port \
  --region=${REGION_1}

echo "ilb-foo-www: creating backend service (bes-foo-www)"
gcloud compute backend-services create bes-foo-www \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --port-name=www-port \
  --health-checks=hc-foo-www \
  --health-checks-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-www: adding managed instance group (mig-foo) to backend service (bes-foo-www)"
gcloud compute backend-services add-backend bes-foo-www \
  --balancing-mode=UTILIZATION \
  --instance-group=mig-foo \
  --instance-group-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-www: creating url map (ilb-foo-www)"
gcloud compute url-maps create ilb-foo-www \
  --default-service=bes-foo-www \
  --region=${REGION_1}

echo "ilb-foo-www: creating target http proxy (proxy-foo-www)"
gcloud compute target-http-proxies create proxy-foo-www \
  --url-map=ilb-foo-www \
  --url-map-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-www: creating forwarding rule (fr-foo-www)"
gcloud compute forwarding-rules create fr-foo-www \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-foo \
  --subnet=subnet-foo-1 \
  --subnet-region=${REGION_1} \
  --address=vip-foo-www \
  --ports=80 \
  --target-http-proxy=proxy-foo-www \
  --target-http-proxy-region=${REGION_1} \
  --region=${REGION_1}

echo "--- Successfully created Load Balancer for WWW Service (ilb-foo-www) ---"
echo

# --- Create load balancer for api service port 8080 ---
echo "--- Creating Load Balancer for API Service (ilb-foo-api) on port 8080 ---"

echo "ilb-foo-api: creating health check (hc-foo-api)"
gcloud compute health-checks create http hc-foo-api \
  --use-serving-port \
  --region=${REGION_1}

echo "ilb-foo-api: creating backend service (bes-foo-api)"
gcloud compute backend-services create bes-foo-api \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --port-name=api-port \
  --health-checks=hc-foo-api \
  --health-checks-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-api: adding managed instance group (mig-foo) to backend service (bes-foo-api)"
gcloud compute backend-services add-backend bes-foo-api \
  --balancing-mode=UTILIZATION \
  --instance-group=mig-foo \
  --instance-group-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-api: creating url map (ilb-foo-api)"
gcloud compute url-maps create ilb-foo-api \
  --default-service=bes-foo-api \
  --region=${REGION_1}

echo "ilb-foo-api: creating target http proxy (proxy-foo-api)"
gcloud compute target-http-proxies create proxy-foo-api \
  --url-map=ilb-foo-api \
  --url-map-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-api: creating forwarding rule (fr-foo-api)"
gcloud compute forwarding-rules create fr-foo-api \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-foo \
  --subnet=subnet-foo-1 \
  --subnet-region=${REGION_1} \
  --address=vip-foo-api \
  --ports=8080 \
  --target-http-proxy=proxy-foo-api \
  --target-http-proxy-region=${REGION_1} \
  --region=${REGION_1}

echo "--- Successfully created Load Balancer for API Service (ilb-foo-api) ---"
echo

# --- Create load balancer for gcs service port 443 ---
echo "--- Creating Load Balancer for GCS Service (ilb-foo-gcs) on port 443 ---"

echo "ilb-foo-gcs: creating network endpoint group (neg-psc-gcs)"
gcloud compute network-endpoint-groups create neg-psc-gcs \
  --network-endpoint-type=private-service-connect \
  --psc-target-service=storage.${REGION_1}.rep.googleapis.com \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating backend service (bes-foo-gcs)"
gcloud compute backend-services create bes-foo-gcs \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTPS \
  --region=${REGION_1}

echo "ilb-foo-gcs: adding network endpoint group (neg-psc-gcs) to backend service (bes-foo-gcs)"
gcloud compute backend-services add-backend bes-foo-gcs \
  --network-endpoint-group=neg-psc-gcs \
  --network-endpoint-group-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating url map (ilb-foo-gcs)"
gcloud compute url-maps create ilb-foo-gcs \
  --default-service=bes-foo-gcs \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating target https proxy (proxy-foo-gcs)"
gcloud compute target-https-proxies create proxy-foo-gcs \
  --url-map=ilb-foo-gcs \
  --url-map-region=${REGION_1} \
  --certificate-manager-certificates=cert-foo-gcs \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating forwarding rule (fr-foo-gcs)"
gcloud compute forwarding-rules create fr-foo-gcs \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-foo \
  --subnet=subnet-foo-1 \
  --subnet-region=${REGION_1} \
  --address=vip-foo-gcs \
  --ports=443 \
  --target-https-proxy=proxy-foo-gcs \
  --target-https-proxy-region=${REGION_1} \
  --region=${REGION_1}

echo "--- Successfully created Load Balancer for GCS Service (ilb-foo-gcs) ---"
echo

echo "All load balancers created successfully."
EOF

# make script executable
chmod +x create_lbs.sh

# run script
./create_lbs.sh

ध्यान दें: इस स्क्रिप्ट को पूरा होने में कुछ मिनट लगते हैं.

लोड बैलेंसर बनाने की पुष्टि करना

पुष्टि करें कि फ़ॉरवर्ड करने के नियम और बैकएंड सेवाएं लागू की गई हैं.

# check forwarding rules
gcloud compute forwarding-rules list

# check backend services
gcloud compute backend-services list

लोड बैलेंसर सेटअप करने का तरीका यहां खत्म होता है... अब क्लाइंट वीएम इंस्टेंस कॉन्फ़िगर करने का तरीका जानें.

6. क्लाइंट का ऐक्सेस

वीएम क्लाइंट संसाधन बनाना

इस सेक्शन में, क्लाइंट डिप्लॉय किए जाएंगे और एंड-टू-एंड कनेक्टिविटी की पुष्टि की जाएगी.

वीएम इंस्टेंस बनाना

# set variables for client ip addresses
export VM_ALLOW_IP="10.0.0.11"
export VM_DENY_IP="10.0.0.12"
echo ${VM_ALLOW_IP}
echo ${VM_DENY_IP}

# create client 1 vm
gcloud compute instances create vm-allow \
  --machine-type=e2-micro \
  --zone=${ZONE_1} \
  --subnet=subnet-foo-1 \
  --no-address \
  --private-network-ip=${VM_ALLOW_IP} \
  --scopes=cloud-platform \
  --shielded-secure-boot

# create client 2 vm
gcloud compute instances create vm-deny \
  --machine-type=e2-micro \
  --zone=${ZONE_1} \
  --subnet=subnet-foo-1 \
  --no-address \
  --private-network-ip=${VM_DENY_IP} \
  --scopes=cloud-platform \
  --shielded-secure-boot

बेसलाइन सेवा की जांच करना

क्लाइंट `vm-allow` से टेस्ट

ध्यान दें: instances create कमांड जारी करने के कुछ समय बाद, वर्चुअल मशीन के इंस्टेंस ऑनलाइन हो जाएंगे और IAP का इस्तेमाल करके ssh पर ऐक्सेस किए जा सकेंगे. अगर पहली बार में अनुरोध पूरा नहीं होता है, तो आपको कुछ देर इंतज़ार करना पड़ सकता है.

# send request to foo www service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s www.foo.com"

# send request to foo api service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

लोड बैलेंसर के ज़रिए, Google Cloud Storage में कोई फ़ाइल अपलोड करके देखें.

# send request to foo gcs service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  echo 'test one on the way' > test-upload-1.txt
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k -X POST \"https://gcs.foo.com/upload/storage/v1/b/${BUCKET}/o?uploadType=media&name=test-upload-object-1.txt\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -H \"Content-Type: text/plain\" \
  --data-binary @test-upload-1.txt"

Cloud Storage API से मिले जवाब से पुष्टि होती है कि नेटवर्क पाथ सही तरीके से काम कर रहा है.

क्लाइंट `vm-deny` से टेस्ट

# send request to foo www service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s www.foo.com"

# send request to foo api service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

# send request to foo gcs service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  echo 'test two on the way' > test-upload-2.txt
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k -X POST \"https://gcs.foo.com/upload/storage/v1/b/${BUCKET}/o?uploadType=media&name=test-upload-object-2.txt\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -H \"Content-Type: text/plain\" \
  --data-binary @test-upload-2.txt"

ध्यान दें: ये जांचें भी पास होनी चाहिए, क्योंकि फ़ायरवॉल के किसी भी नियम ने अब तक लोड बैलेंसर को टारगेट नहीं किया है.

सेटअप के सभी मुख्य हिस्से पूरे हो गए हैं... अब लोड बैलेंसर के फ़ायरवॉल के नियम बनाए जाएंगे.

7. लोड बैलेंसर फ़ायरवॉल

इस सेक्शन में, लोड बैलेंसर को टारगेट करने वाले फ़ायरवॉल नीति के नियमों को डिप्लॉय किया जाएगा. कॉन्फ़िगरेशन का क्रम, सुरक्षा से जुड़ी ऐसी स्थिति की ओर ले जाएगा जिसमें vm-allow को ऐक्सेस करने की अनुमति होगी. साथ ही, सभी सेवाओं के लिए vm-deny ट्रैफ़िक को ब्लॉक किया जाएगा.

चुनिंदा ट्रैफ़िक को `fr-foo-www` पर जाने की अनुमति दें

मौजूदा फ़ायरवॉल नीति में नया फ़ायरवॉल नीति नियम जोड़ें fw-policy-foo-${REGION_1}

सोर्स आईपी पतों की ऐसी रेंज को अनुमति दें जिसमें vm-allow शामिल हो और vm-deny आईपी पते शामिल न हों
लोड बैलेंसर को टारगेट करने वाले फ़ायरवॉल की नीति के नियम में नेटवर्क टाइप का इस्तेमाल करने के लिए, एक और सोर्स फ़िल्टर INTRA_VPC जोड़ें

INTRA_VPC और VPC_NETWORKS के सोर्स नेटवर्क टाइप को फ़ायरवॉल की नीतियों के उन नियमों में इस्तेमाल किया जा सकता है जो लोड बैलेंसर को टारगेट करते हैं. हालांकि, ऐसा तब ही किया जा सकता है, जब इन्हें किसी दूसरे सोर्स पैरामीटर के साथ इस्तेमाल किया जाए. आकलन का लॉजिक, दोनों सोर्स पैरामीटर के बीच का AND है. यहां, ट्रैफ़िक को अनुमति देने के लिए, INTRA_VPC और --src-ip-ranges=${VM_ALLOW_IP}/32 की शर्तों को पूरा करना ज़रूरी है.

`vm-allow` टारगेटिंग `fr-foo-www` की अनुमति देने के लिए नियम बनाना

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2001 \
  --description="allow vm traffic to fr-www" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-network-type=INTRA_VPC \
  --src-ip-ranges=${VM_ALLOW_IP}/32 \
  --target-type=INTERNAL_MANAGED_LB \
  --target-forwarding-rules=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo-www

क्लाइंट `vm-allow` से टेस्ट

# send request to foo www service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s www.foo.com"

क्लाइंट `vm-deny` से टेस्ट

# send request to foo www service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s www.foo.com"

ध्यान दें: ऐसा इसलिए हुआ, क्योंकि लोड बैलेंसर के लिए फ़ायरवॉल की नीति से जुड़े नियम के काम करने का लागू डिफ़ॉल्ट तरीका --action=allow है. इसे बदलने के लिए, डिफ़ॉल्ट (कैचल) अस्वीकार करने का नियम ज़रूरी है.

`fr-foo-www` के लिए डिफ़ॉल्ट ट्रैफ़िक को अस्वीकार करें

कम प्राथमिकता (ज़्यादा प्राथमिकता वाला नंबर) वाला फ़ायरवॉल की नीति से जुड़ा नया नियम जोड़ें.

किसी भी सोर्स आईपी पते से आने वाले सभी ट्रैफ़िक को अस्वीकार करना
अस्वीकार करने का नियम लागू होने से पहले, vm-allow से fr-foo-www तक के ट्रैफ़िक को अनुमति दी जाएगी

`fr-foo-www` को टारगेट करने वाले ट्रैफ़िक को अस्वीकार करने का नियम बनाएं

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2999 \
  --description="allow vm traffic to fr-www" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=deny \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-ip-ranges=0.0.0.0/0 \
  --target-type=INTERNAL_MANAGED_LB \
  --target-forwarding-rules=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo-www

हेल्थ चेक के लिए ज़रूरी बातें

फ़ायरवॉल की नीति के नियम, वीएम इंस्टेंस को टारगेट करते हैं. इसी तरह, इन्ग्रेस डेटा ट्रैफ़िक को डिफ़ॉल्ट रूप से ब्लॉक करने वाला नियम, लोड बैलेंसर बैकएंड तक पहुंचने वाले, हेल्थ चेक प्रोब रेंज से मिले ट्रैफ़िक को ब्लॉक करता है. इसलिए, इन्ग्रेस हेल्थ चेक प्रोब रेंज को अनुमति देने के लिए, अनुमति देने से जुड़ा एक नियम कॉन्फ़िगर किया गया था. नियम 1002 देखें.

अहम जानकारी: इसी तरह, लोड बैलेंसर टारगेट के लिए, सभी अनुरोधों को अस्वीकार करने वाला (एक्सप्लिसिट) इनग्रेस नियम बनाते समय, ज़्यादा प्राथमिकता (कम प्राथमिकता वाला नंबर) वाला दूसरा नियम बनाना ज़रूरी है. इससे हेल्थ चेक प्रोब रेंज से इनग्रेस की अनुमति दी जा सकेगी. इस नियम को लोड बैलेंसर को टारगेट करना चाहिए.

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2002 \
  --description="allow health checks to fr-www" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-address-groups=projects/${PROJECT_ID}/locations/${REGION_1}/addressGroups/uhc-probes \
  --target-type=INTERNAL_MANAGED_LB \
  --target-forwarding-rules=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo-www

क्लाइंट `vm-deny` से टेस्ट

# send request to foo www service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s www.foo.com"

अब यह अनुरोध पूरा नहीं होगा, क्योंकि फ़ायरवॉल के नियम 2999 के तहत, वीपीसी नेटवर्क से आने वाले सभी ट्रैफ़िक को अस्वीकार कर दिया जाता है. ज़्यादा प्राथमिकता (कम प्राथमिकता वाला नंबर) वाले नियम 2001 में, सिर्फ़ ऐसी सोर्स रेंज की अनुमति दी गई थी जिसमें vm-allow शामिल हो.

Ctrl+C दबाकर, curl की प्रोसेस बंद करें.

# send request to foo api service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

vm-deny के पास अब भी एपीआई सेवा का ऐक्सेस है! ऐसा इसलिए हुआ, क्योंकि फ़ायरवॉल का नियम सिर्फ़ फ़ॉरवर्ड करने के नियम fr-foo-www पर लागू किया गया था. साथ ही, इसने fr-foo-api को टारगेट नहीं किया था.

सभी लोड बैलेंसर को टारगेट करने के लिए, नियमों को अपडेट करें

ध्यान दें: वीपीसी नेटवर्क में मौजूद सभी लोड बैलेंसर पर फ़ायरवॉल नीति के नियमों को लागू किया जा सकता है. इसके लिए, --target-forwarding-rules=FR_NAME को हटा दें.

फ़ायरवॉल नीति के नियमों में बदलाव करें, ताकि वे अब वीपीसी नेटवर्क में लोड बैलेंसर फ़ॉरवर्डिंग के सभी नियमों के टारगेट पर लागू हों.

वीएम ट्रैफ़िक (vm-allow आईपी रेंज) की अनुमति देने के लिए, सभी फ़ॉरवर्डिंग नियमों को टारगेट करने वाला नया इन्ग्रेस अनुमति दें नियम 2003 बनाएं
सभी फ़ॉरवर्डिंग नियमों को टारगेट करने वाला, नया इनग्रेस अनुमति दें नियम 2004 बनाएं, ताकि हेल्थ चेक (uhc-probes पता ग्रुप) ट्रैफ़िक की अनुमति दी जा सके.
सभी फ़ॉरवर्डिंग नियमों को टारगेट करने वाला, इन्ग्रेस deny का नया नियम 2998 बनाएं, ताकि अन्य सभी ट्रैफ़िक को रोका जा सके

सभी लोड बैलेंसर को टारगेट करने के लिए, फ़ायरवॉल के नियमों में बदलाव करें

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2003 \
  --description="allow vm traffic to all vnet lb fr" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp  \
  --src-ip-ranges=${VM_ALLOW_IP}/32 \
  --target-type=INTERNAL_MANAGED_LB

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2004 \
  --description="allow health checks to all vnet lb fr" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-address-groups=projects/${PROJECT_ID}/locations/${REGION_1}/addressGroups/uhc-probes \
  --target-type=INTERNAL_MANAGED_LB

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2998 \
  --description="deny all vnet traffic to all vnet lb fr" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=deny \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-ip-ranges=0.0.0.0/0 \
  --target-type=INTERNAL_MANAGED_LB

एक्सप्लिसिट लोड बैलेंसर फ़ॉरवर्डिंग के नियमों को टारगेट करने वाले फ़ायरवॉल की पिछली नीति के नियमों को हटाया जा सकता है. ऐसा इसलिए, क्योंकि अब वे VPC नेटवर्क में फ़ॉरवर्डिंग के सभी नियमों को टारगेट करने वाले नियमों के साथ काम नहीं करते.

# delete redundant fw policy rules
gcloud beta compute network-firewall-policies rules delete 2001 \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

gcloud beta compute network-firewall-policies rules delete 2002 \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

gcloud beta compute network-firewall-policies rules delete 2999 \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

क्लाइंट `vm-deny` से टेस्ट

# send request to foo api service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

अब यह अनुरोध पूरा नहीं होना चाहिए, क्योंकि fr-foo-api को फ़ायरवॉल की नीति से जुड़े उन सभी नियमों के तहत भी टारगेट किया जाता है जिनमें --target-type=INTERNAL_MANAGED_LB शामिल है.

Ctrl+C दबाकर, curl की प्रोसेस बंद करें.

लोड बैलेंसर के ज़रिए, Google Cloud Storage से कोई फ़ाइल डाउनलोड करके देखें.

# send request to foo gcs service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k \"https://gcs.foo.com/storage/v1/b/${BUCKET}/o/test-upload-object.txt?alt=media\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -o test-download.txt"

Ctrl+C दबाकर, curl की प्रोसेस बंद करें.

क्लाइंट `vm-allow` से टेस्ट

# send request to foo www service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s www.foo.com"

# send request to foo api service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

# send request to foo gcs service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k \"https://gcs.foo.com/storage/v1/b/${BUCKET}/o/test-upload-object-1.txt?alt=media\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -o test-download-1.txt"

डाउनलोड किए गए कॉन्टेंट की पुष्टि करना

# send request from vm
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  cat test-download-1.txt"

लोड बैलेंसर की सभी सेवाएं vm-allow के लिए उपलब्ध हैं और vm-deny के लिए ब्लॉक कर दी गई हैं.

टेस्टिंग का हिस्सा यहीं खत्म होता है... अब लॉगिंग के बारे में थोड़ी जानकारी.

8. फ़ायरवॉल के नियमों के लिए लॉगिंग

फ़ायरवॉल लॉग फ़ॉर्मैट में, लोड बैलेंसर (--target-type=INTERNAL_MANAGED_LB) को टारगेट करने वाले नियमों के लिए फ़ील्ड और रिकॉर्ड होते हैं.

लॉग में एक और फ़ील्ड शामिल होगा, जिसे load_balancer_details के तौर पर लेबल किया गया है. इसमें उस लोड बैलेंसर के बारे में ज़्यादा जानकारी होगी जिस पर फ़ायरवॉल नीति के नियम को टारगेट किया गया था. यह InstanceDetails फ़ील्ड फ़ॉर्मैट के जैसा ही होता है. इसका इस्तेमाल तब किया जाता है, जब फ़ायरवॉल नीति के नियमों में वीएम इंस्टेंस को टारगेट किया जाता है.

load_balancer_details.forwarding_rule_name, फ़ायरवॉल की नीति से जुड़े नियम के लिए कॉल को दूसरे नंबर पर भेजे जाने से जुड़ा टारगेट नियम दिखाता है
load_balancer_details.type से पता चलता है कि प्रॉक्सी पर आधारित लोड बैलेंसर के किस फ़्लेवर को टारगेट किया गया है
load_balancer_details.url_map_name इस कुकी का इस्तेमाल तब किया जाता है, जब टाइप ऐप्लिकेशन लोड बैलेंसर होता है. यह कुकी, इस्तेमाल किए गए यूआरएल मैप रिसॉर्स को लॉग करती है

लॉग देखें

फ़ायरवॉल की नीति से जुड़े नियमों के नतीजे देखने के लिए, फ़ायरवॉल के लॉग क्वेरी करें.

gcloud logging read \
  "logName=projects/${PROJECT_ID}/logs/compute.googleapis.com%2Ffirewall \
  AND (jsonPayload.connection.src_ip=\"${VM_ALLOW_IP}\" OR jsonPayload.connection.src_ip=\"${VM_DENY_IP}\")" \
  --project=${PROJECT_ID} \
  --freshness=30m \
  --limit=50 \
  --format="table(
    timestamp:label=TIMESTAMP,
    jsonPayload.connection.src_ip:label=SRC_IP,
    jsonPayload.connection.src_port:label=SRC_PORT,
    jsonPayload.connection.dest_ip:label=DEST_IP,
    jsonPayload.connection.dest_port:label=DEST_PORT,
    jsonPayload.disposition:label=ACTION,
    jsonPayload.rule_details.priority:label=PRIORITY,
    jsonPayload.load_balancer_details.forwarding_rule_name:label=FWD_RULE
  )"

लॉग आउटपुट में, नीति के तहत लागू किए गए नियम दिखते हैं:

सभी लोड बैलेंसर के लिए, vm-allow से आने वाले सभी ट्रैफ़िक को नियम 2011 के तहत अनुमति दी गई है
लोड बैलेंसर पर जाने वाले सभी ट्रैफ़िक को नियम 2998 के तहत अस्वीकार कर दिया गया है

TIMESTAMP                       SRC_IP     SRC_PORT  DEST_IP     DEST_PORT  ACTION   PRIORITY  FWD_RULE
YYYY-MM-DDTHH:MM:SS.850967068Z  10.0.0.11  48480     10.0.0.103  443        ALLOWED  2003      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.418613380Z  10.0.0.11  37340     10.0.0.101  80         ALLOWED  2003      fr-foo-www
YYYY-MM-DDTHH:MM:SS.213234118Z  10.0.0.12  55950     10.0.0.103  443        DENIED   2998      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.981484412Z  10.0.0.11  41738     10.0.0.101  80         ALLOWED  2003      fr-foo-www
YYYY-MM-DDTHH:MM:SS.189358071Z  10.0.0.12  55950     10.0.0.103  443        DENIED   2998      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.061463883Z  10.0.0.12  55950     10.0.0.103  443        DENIED   2998      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.965498098Z  10.0.0.12  53284     10.0.0.102  8080       DENIED   2998      fr-foo-api

लॉग एक्सप्लोरर का इस्तेमाल करके, Google Cloud Console में भी लॉग देखे जा सकते हैं. console.cloud.google.com/logs/query पर जाएं और स्टैंडर्ड वीपीसी फ़ायरवॉल लॉग compute.googleapis.com/firewall का इस्तेमाल करें.

logName=projects/${PROJECT_ID}/logs/compute.googleapis.com%2Ffirewall

लॉगिंग का हिस्सा यहीं खत्म होता है... अब क्लीन अप करते हैं!

9. साफ़-सफ़ाई सेवा

# delete client compute resources
gcloud -q compute instances delete vm-deny --zone=${ZONE_1}

gcloud -q compute instances delete vm-allow --zone=${ZONE_1}

# next

# delete load balancer resources for gcs
gcloud -q compute forwarding-rules delete fr-foo-gcs --region=${REGION_1}

gcloud -q compute target-https-proxies delete proxy-foo-gcs --region=${REGION_1}

gcloud -q compute url-maps delete ilb-foo-gcs --region=${REGION_1}

gcloud -q compute backend-services delete bes-foo-gcs --region=${REGION_1}

gcloud -q compute addresses delete vip-foo-gcs --region=${REGION_1}

# next

# delete load balancer resources for api
gcloud -q compute forwarding-rules delete fr-foo-api --region=${REGION_1}

gcloud -q compute target-http-proxies delete proxy-foo-api --region=${REGION_1}

gcloud -q compute url-maps delete ilb-foo-api --region=${REGION_1}

gcloud -q compute backend-services delete bes-foo-api --region=${REGION_1}

gcloud -q compute health-checks delete hc-foo-api --region=${REGION_1}

gcloud -q compute addresses delete vip-foo-api --region=${REGION_1}

# next

# delete load balancer resources for www
gcloud -q compute forwarding-rules delete fr-foo-www --region=${REGION_1}

gcloud -q compute target-http-proxies delete proxy-foo-www --region=${REGION_1}

gcloud -q compute url-maps delete ilb-foo-www --region=${REGION_1}

gcloud -q compute backend-services delete bes-foo-www --region=${REGION_1}

gcloud -q compute health-checks delete hc-foo-www --region=${REGION_1}

gcloud -q compute addresses delete vip-foo-www --region=${REGION_1}

# next

# delete service backend resources
gcloud -q storage rm --recursive gs://${BUCKET}

gcloud -q certificate-manager certificates delete cert-foo-gcs --location=${REGION_1}

gcloud -q compute network-endpoint-groups delete neg-psc-gcs --region=${REGION_1}

gcloud -q compute instance-groups managed delete mig-foo --region=${REGION_1}

gcloud -q compute instance-templates delete mig-template-foo --global

# next

# delete dns, nat, fw resources
gcloud -q dns record-sets delete gcs.foo.com --type=A --zone=zone-foo

gcloud -q dns record-sets delete api.foo.com --type=A --zone=zone-foo

gcloud -q dns record-sets delete www.foo.com --type=A --zone=zone-foo

gcloud -q dns managed-zones delete zone-foo

gcloud -q compute routers delete cr-nat-foo --region=${REGION_1}

gcloud -q compute network-firewall-policies associations delete \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --name=fw-policy-association-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

gcloud -q compute network-firewall-policies delete fw-policy-foo-${REGION_1} --region=${REGION_1}

gcloud -q network-security address-groups delete uhc-probes --location=${REGION_1}

# next

# delete network resources
gcloud -q compute networks subnets delete subnet-foo-3 --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-foo-2 --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-foo-1 --region=${REGION_1}

gcloud -q compute networks delete vnet-foo

# next

# delete shell variables and local files
unset PROJECT_ID REGION_1 ZONE_1 VM_ALLOW_IP VM_DENY_IP BUCKET

rm vm-server-startup.sh create_lbs.sh foo-gcs-key.pem foo-gcs-cert.pem

# end

10. नतीजा

बधाई हो! आपने लोड बैलेंसर के लिए, Cloud NGFW Essentials को कॉन्फ़िगर कर लिया है!

इस फ़ीडबैक फ़ॉर्म का इस्तेमाल करके, बेझिझक कोई टिप्पणी करें, सवाल पूछें या सुधार के बारे में बताएं

धन्यवाद!

लोड बैलेंसर के लिए Cloud NGFW Essentials

1. परिचय

आपको ये सब सीखने को मिलेगा

आपको इन चीज़ों की ज़रूरत पड़ेगी

2. कॉन्सेप्ट

फ़ायरवॉल की सुविधाओं के टियर

डेटा प्लेन फ़िल्टरिंग

लोड बैलेंसर के टारगेट

कोडलैब नेटवर्क

3. प्रोजेक्ट सेटअप करना

अपने प्रोजेक्ट को ऐक्सेस करना

प्रोजेक्ट आईडी सेट करना

एपीआई सेवाएं चालू करना

शेल एनवायरमेंट वैरिएबल सेट करना

4. नेटवर्क फ़ाउंडेशन

नेटवर्क संसाधन बनाना

फ़ायरवॉल कॉम्पोनेंट बनाना

पता ग्रुप बनाना

फ़ायरवॉल की नीति बनाना

नेटवर्क सेवाएं कॉन्फ़िगर करना

Cloud Router और NAT गेटवे बनाना

आईपी पते रिज़र्व करना

डीएनएस रिकॉर्ड बनाना

5. लोड बैलेंसर सेवाएं

बैकएंड रिसॉर्स सेट अप करना

VM इंस्टेंस ग्रुप सर्वर बनाना

स्टोरेज बकेट बनाना

प्रमाणपत्र बनाएं

लोड बैलेंसर कॉम्पोनेंट बनाना

लोड बैलेंसर बनाने की स्क्रिप्ट डिप्लॉय करना

लोड बैलेंसर बनाने की पुष्टि करना

6. क्लाइंट का ऐक्सेस

वीएम क्लाइंट संसाधन बनाना

वीएम इंस्टेंस बनाना

बेसलाइन सेवा की जांच करना

क्लाइंट vm-allow से टेस्ट

क्लाइंट vm-deny से टेस्ट

7. लोड बैलेंसर फ़ायरवॉल

चुनिंदा ट्रैफ़िक को fr-foo-www पर जाने की अनुमति दें

vm-allow टारगेटिंग fr-foo-www की अनुमति देने के लिए नियम बनाना

क्लाइंट vm-allow से टेस्ट

क्लाइंट vm-deny से टेस्ट

fr-foo-www के लिए डिफ़ॉल्ट ट्रैफ़िक को अस्वीकार करें

fr-foo-www को टारगेट करने वाले ट्रैफ़िक को अस्वीकार करने का नियम बनाएं

हेल्थ चेक के लिए ज़रूरी बातें

क्लाइंट vm-deny से टेस्ट

सभी लोड बैलेंसर को टारगेट करने के लिए, नियमों को अपडेट करें

सभी लोड बैलेंसर को टारगेट करने के लिए, फ़ायरवॉल के नियमों में बदलाव करें

क्लाइंट vm-deny से टेस्ट

क्लाइंट vm-allow से टेस्ट

8. फ़ायरवॉल के नियमों के लिए लॉगिंग

लॉग देखें

9. साफ़-सफ़ाई सेवा

10. नतीजा

क्लाइंट `vm-allow` से टेस्ट

क्लाइंट `vm-deny` से टेस्ट

चुनिंदा ट्रैफ़िक को `fr-foo-www` पर जाने की अनुमति दें

`vm-allow` टारगेटिंग `fr-foo-www` की अनुमति देने के लिए नियम बनाना

क्लाइंट `vm-allow` से टेस्ट

क्लाइंट `vm-deny` से टेस्ट

`fr-foo-www` के लिए डिफ़ॉल्ट ट्रैफ़िक को अस्वीकार करें

`fr-foo-www` को टारगेट करने वाले ट्रैफ़िक को अस्वीकार करने का नियम बनाएं

क्लाइंट `vm-deny` से टेस्ट

क्लाइंट `vm-deny` से टेस्ट

क्लाइंट `vm-allow` से टेस्ट