GCP Cloud VPN: შეამოწმეთ კარიბჭე, გვირაბი და firewall თანმიმდევრობით

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

ამ მწვანე ხატულასა და პასუხს შორის ოთხი გადაწყვეტილება დგას და ისინი წინასწარმეტყველებადი თანმიმდევრობით ცდებიან. დაიწყეთ ყველაზე იაფიდან.

სამი ობიექტი, და მათგან მხოლოდ ერთი შიფრავს

VPN კარიბჭე ფლობს გარე მისამართს, რომელზეც თქვენი წყვილი შიფრავს. კონსოლში მას არასდროს ქმნით ხელით: აირჩიეთ ან დაჯავშნეთ მისამართი კავშირის ფორმის შიგნით და კარიბჭე მასთან ერთად გამოჩნდება. HA კარიბჭე ორ მისამართს იკავებს ორ ინტერფეისზე, რაც მოგვიანებით კვოტის შემოწმებისას მნიშვნელოვანია.

გვირაბი ამ კარიბჭისა და წყვილის დაწყვილებაა. ის ატარებს საერთო საიდუმლოს და ტრაფიკის სელექტორებს, რომელთა დაცვასაც პირდება. სწორედ ამ სელექტორებში იწყება უმეტესი ჩუმი ხარვეზი. გვირაბი, რომლის ლოკალური სელექტორი ფარავს 10.0.0.0/24-ს, არ მიაწვდის 10.0.1.0/24-ს, რაც არ უნდა ჯანსაღად გამოიყურებოდეს სტატუსი.

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

მარშრუტიზაციის ტიპი წყვეტს, რა აღწევს მარშრუტების ცხრილში

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

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

დინამიკური ერთადერთი ფორმაა, რომელიც დაცულ პრეფიქსებს გვირაბის ხელახლა აშენების გარეშე ცვლის საშუალებას აძლევს, და ის Cloud Router-ს ჩაგითრევთ იმ ობიექტების სიმრავლეში, რომლებიც უნდა გადაამოწმოთ. სტატიკური სელექტორები მუშაობადი რჩება, როცა წყვილი ტექნიკური firewall-ია, რომელსაც BGP არ შეუძლია. მაშინ ორივე ბოლოს ერთი და იგივე დიაპაზონები სჭირდება და უფრო კონკრეტულმა ჩანაწერმა ორივეგან უნდა გაიმარჯვოს. წყვილი, რომელიც ერთი ქვექსელით განსხვავდება, დამყარდება და შემდეგ თქვენი ტრაფიკის ნახევარს ატარებს.

იმპლიციტური უარი გვირაბის უკან ზის

შემომავალი ტრაფიკი ფასდება იმპლიციტური უარის წინააღმდეგ ყველაზე დაბალ პრიორიტეტზე და ამ წესს არ აინტერესებს, რომ პაკეტი დაშიფრული მოვიდა. სანამ firewall წესი არ დაასახელებს ლოკალურ დიაპაზონს და გამოყენებულ პორტს, პაკეტი გაშიფრდება, შემოწმდება და ჩამოგდება. VPN ჟურნალი მთელი დრო სუფთა რჩება, რადგან გვირაბმა ზუსტად ის გააკეთა, რაც პირდა.

ამის ნაცვლად წაიკითხეთ firewall-ის უარების ჟურნალი, როცა გვირაბი მუშაობს და შემოწმება დროში იწურება, შემდეგ შეზღუდეთ წესი წყაროს დიაპაზონსა და საჭირო პორტებზე:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

ერთი მიმართულების მუშაობა firewall-ის მინიშნებაა

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

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

სელექტორები, კვოტები, შემდეგ ოთხი შემოწმება

კონსოლში შექმნილი გვირაბები ზოგჯერ ცარიელ დისტანციურ ტრაფიკის სელექტორს აბრუნებენ gcloud compute vpn-tunnels describe-იდან, მაშინ როცა გენერირებული მარშრუტები ტრაფიკს სწორად ატარებენ. სანამ გვირაბს არასწორად ჩათვლით, შეადარეთ რასაც API აფიქსირებს იმ დიაპაზონებს, რომლებსაც რეალურად იცავთ. API-ის ან SDK-ის მეშვეობით შექმნა სელექტორს აშკარად ინახავს.

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

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