Cloud Run-იდან ლოკალურ VPN-ზე: პირდაპირი VPC გასვლის კონფიგურაცია

გვირაბი მუშაობს, VM აღწევს ლოკალურ სერვერამდე, ხოლო Cloud Run სერვისს იმავე ჰოსტზე დრო ამოეწურება. ეს ამ ამოცანის ჩვეულებრივი საწყისი წერტილია და გვირაბი იშვიათად არის ის, რაც არასწორია. Cloud Run რევიზია ნაგულისხმევად თქვენს VPC-ში არ ზის, და როცა ზის, იყენებს საკუთარ წყაროს მისამართებს და არა იმ VM ქვექსელს, რომელიც უკვე დაამარშრუტეთ. ქვემოთ მოცემული runbook აკავშირებს სერვისს, დაამარშრუტებს მის რეალურ წყაროს დიაპაზონს და შემდეგ ამტკიცებს გზას იმ რევიზიიდან, რომელმაც მოთხოვნას მოემსახურა. შეასრულეთ იმავე თანმიმდევრობით, რადგან პირველი ნაბიჯის გამოტოვება არის მიზეზი, რომ ამ შემთხვევების ბევრი VPN-ის ისეთი ცვლილებით სრულდება, რომელიც არაფერს ასწორებს.

დაუკავშირეთ რევიზია გვირაბის გამართვამდე

Cloud Run მხარს უჭერს პირდაპირ VPC გასვლას, რომელიც სერვისის ტრაფიკს თქვენი VPC-ის ქვექსელზე ათავსებს Serverless VPC Access კონექტორის გარეშე. არსებული სერვისისთვის განახლება ასე გამოიყურება:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

შეცვალეთ დამჭერები, გადახედეთ რას აკეთებს განლაგება ცოცხალ ტრაფიკთან და აირჩიეთ ქვექსელი სერვისის რეგიონში საკმარისი მისამართების ტევადობით და სწორი ქსელური ნებართვებით.

აირჩიეთ დანიშნულების შესაბამისი გასვლის რეჟიმი

private-ranges-only აგზავნის დანიშნულებებს, რომლებსაც კერძოდ აკლასიფიცირებს, VPC-ის გავლით. ეს არ ნიშნავს «ყველაფერს, რაც VPN-ით ხელმისაწვდომია», და ეს ნაპრალი მაშინ ჩნდება, როცა ლოკალური სერვისი იმ დიაპაზონშია, რომელსაც პარამეტრი ასე არ აკლასიფიცირებს. თუ დანიშნულება დაფარული არ არის, მაშინ all-traffic დოკუმენტირებული მეორე რეჟიმია და ყველაფერს VPC-ის გავლით აგზავნის, მათ შორის სერვისის საჯარო დამოკიდებულებებს. აირჩიეთ გააზრებულად და შედეგი ჩაწერეთ ცვლილების ჩანაწერში.

სერვისს, რომელიც უკვე იყენებს კონექტორს, მიგრაცია სჭირდება და არა გადამრთველი, ამიტომ დაგეგმეთ ის, ორივეს კონფიგურაციის ნაცვლად.

დაამარშრუტეთ Cloud Run-ის წყარო და არა VM-ის წყარო

პირდაპირი VPC გასვლა დროებით მისამართებს ანაწილებს არჩეული ქვექსელიდან და ლოკალურმა მხარემ ტრაფიკი იმ დიაპაზონში უნდა დააბრუნოს. სხვა VM ქვექსელისთვის დაწერილი დაბრუნების მარშრუტი ან firewall-ის ნებართვა დიაგრამაზე სწორად გამოჩნდება და პრაქტიკაში ჩავარდება. ქვექსელის CIDR აიღეთ VPC-დან და არა მეხსიერებიდან, შემდეგ დაადასტურეთ, რომ დისტანციური მოწყობილობის crypto ACL ან მარშრუტიზაციის ცხრილი მას შეიცავს.

დინამიკური მარშრუტიზაციისას შეამოწმეთ, რას აცხადებს Cloud Router რეალურად და რას იმპორტირებს VPC, ნებისმიერი მორგებული განცხადების პოლიტიკის ჩათვლით. მარშრუტი, რომელიც კონსოლში არსებობს, მაგრამ ამ დანიშნულებისთვის არჩეული არ არის, იგივეა, რაც მარშრუტის არარსებობა.

სამი პირობა, რომლებიც ყველა უნდა სრულდებოდეს

მოქმედ გზას სჭირდება ყველა ქვემოთ ჩამოთვლილი და თითოეული თავისებურად ჩავარდება:

• მარშრუტი VPC-ში ლოკალური პრეფიქსისკენ განზრახული Cloud VPN კავშირის გავლით.
• უკუ მარშრუტი ლოკალურ მხარეს Cloud Run ქვექსელისთვის.
• firewall-ისა და IPsec-ის დაცვის არე, რომელიც უშვებს წყაროს, დანიშნულებას და პორტს.

დაკარგული მარშრუტი ჩვეულებრივ დროის ამოწურვას ჰგავს დისტანციურ მხარეს ყოველგვარი მტკიცებულების გარეშე. უკუ მარშრუტის პრობლემა ისე გამოიყურება, თითქოს მოთხოვნა მოდის და პასუხი ქრება. firewall-ის ან სელექტორის პრობლემა შეიძლება უარის ან ჩუმი ჩაშვების სახე ჰქონდეს, მოწყობილობის მიხედვით. იმის დადგენა, სამიდან რომელი გაქვთ, მომდევნო ბრძანებას საგრძნობლად ავიწროებს.

ნუ შეიტანთ ერთ დროებით Cloud Run მისამართს დაშვებულთა სიაში. გამოიყენეთ ქვექსელის დიაპაზონი და აპლიკაციის შესაბამისი ავტორიზაციის დიზაინი.

შეამოწმეთ ის რევიზია, რომელმაც მოთხოვნას მოემსახურა

შემოწმებამდე დაათვალიერეთ განლაგებული ქსელური პარამეტრები და ტრაფიკის განაწილება, რადგან განახლებამ შეიძლება ახალი რევიზია შექმნას, სანამ მოთხოვნები ჯერ კიდევ ძველს აღწევს. შემდეგ შეასრულეთ იგივე ოპერაცია, რომელსაც მომხმარებლის მოთხოვნა ასრულებს, სწორედ იმ რევიზიიდან. თუ დანიშნულება კერძო ჰოსტის სახელია, შეამოწმეთ მისი გარჩევა იმ გარემოში და მიღებული მისამართი, რადგან თქვენი ლეპტოპის კორპორატიული DNS-ის პასუხი სერვისის სახელთა სივრცეზე არაფერს ამტკიცებს. შეინარჩუნეთ TLS ჰოსტის სახელის შემოწმება და დისტანციური აპლიკაციის საკუთარი ავთენტიფიკაცია.

დაელოდეთ Direct VPC-ის დოკუმენტირებულ დაწყების კავშირის შეყოვნებებს და მიეცით კლიენტს მზაობის ან ხელახალი ცდის სტრატეგია, ყოველი ცივი გაშვების დაზიანებულ გვირაბად დიაგნოსტიკის ნაცვლად.

უკან დაბრუნება და რას არ აკეთებს ეს

უკან დასაბრუნებლად აღადგინეთ სერვისის ქსელური და გასვლის პარამეტრები მათ წინა მნიშვნელობებზე და დაადასტურეთ, რომ ადრინდელი რევიზია კვლავ ემსახურება ტრაფიკს. შეინახეთ gcloud ბრძანება ცვლილების ჩანაწერში, რადგან ნაწილობრივი ცვლილების საწინააღმდეგო ექვსი კვირის შემდეგ აშკარა არ არის. VPC-ის მიბმის მოხსნა სერვისს აბრუნებს მის წინა გასვლის გზაზე, რაც შეიძლება ზუსტად ის იყოს, რაც ინციდენტის დროს გსურთ.

ეს დიზაინი მოიცავს კავშირებს, რომლებსაც Cloud Run იწყებს, და მათ პასუხებს. ის ლოკალურ ქსელს არ აძლევს მისამართიან socket-ს სერვისის შიგნით, რადგან შიგნით გამოვლენა ingress გადაწყვეტილებაა.