Cloud VPN-ის საზღვრები, რომელთა რეგულირებაც შეუძლებელია: IKE-ის ვადა და peer-ის NAT
Cloud VPN IKE-ის ვადებზე მოლაპარაკებას ფიქსირებულ საზღვრებში აწარმოებს და peer-ის მხარეს ერთ-ერთზე NAT-ს მოითხოვს. დაგეგმეთ დისტანციური მოწყობილობა ამის მიხედვით, და არა Google-ის მხარის მიხედვით.
მიეცით დისტანციურ მოწყობილობას 24-საათიანი 1-ლი ფაზის ვადა და Cloud VPN-ის გვირაბი ქვევით დარჩება, მაშინაც კი როცა Google-ის მხარეს ყველაფერი სწორად არის კონფიგურირებული. Peer-ი გვთავაზობს მნიშვნელობას, რომელსაც პასუხისმგებელი არ მიიღებს, ამიტომ მოლაპარაკება ან სრულად იშლება, ან უსასრულოდ იწყება ხელახლა. Cloud VPN 1-ელ ფაზას 36,000 წამით, ანუ ათი საათით ზღუდავს და ეს ზღვარი არ არის პარამეტრი, რომლის აწევაც შეგიძლიათ. ცვლილება დისტანციურ მოწყობილობას ეკუთვნის.
Peer-ი კითხულობს, პასუხისმგებელი წყვეტს
IKE ორი წინადადებათა ნაკრების შეჯერების სავარჯიშოა. გვირაბი მხოლოდ იქ იქმნება, სადაც ნაკრებები პასუხისმგებლის მისაღებ საზღვრებში ემთხვევა, ამიტომ დიაპაზონს გარეთ ვადა ნაწილობრივ გვირაბსაც არ ქმნის. ჩვეულებრივი შეცდომაა peer-ის კონფიგურაციის წინადადებად კი არა, სურვილების სიად მიჩნევა. ცარიელი კვეთა გვირაბს ქვევით ტოვებს, რამდენად სწორიც არ უნდა იყოს მარშრუტიზაცია და სელექტორები.
საქმის გახსნამდე წაიკითხეთ თავად გვირაბის მდგომარეობა, რადგან დეტალური სტატუსი ჩვეულებრივ ასახელებს იმ ეტაპს, რომელიც ჩავარდა:
gcloud compute vpn-tunnels describe office-tunnel \
--region europe-west1 \
--format="value(status,detailedStatus)"
შეადარეთ დაბრუნებული შედეგი თქვენი კარიბჭის ტიპისა და IKE-ის ვერსიისთვის მხარდაჭერილ ნაკრებს და იქ ყოფნისას ორივე ტრაფიკის სელექტორი ჩაიწერეთ. სელექტორის შეუსაბამობა იმავე „გვირაბი ქვევით“ სიმპტომს იძლევა, რასაც ალგორითმის შეუსაბამობა, და ალგორითმისგან განსხვავებით, ეს თქვენ უნდა გამოასწოროთ.
36,000 წამია ზღვარი
1-ლი ფაზა 36,000 წამზე ჩერდება. 86,400-ზე დაყენებული მოწყობილობა ითხოვს იმას, რასაც პასუხისმგებელი არასოდეს დათანხმდება და განმეორებითი ცდა მის აზრს არ ცვლის. დააბრუნეთ დისტანციური წინადადება დიაპაზონში და იგივე კონფიგურაცია დამყარდება; ასიმეტრია მთელი გაკვეთილია, რადგან საკუთარი მნიშვნელობის დაწევა შეგიძლიათ, Google-ისა კი ვერ აწევთ.
ჩაწერეთ არჩეული მნიშვნელობა დიზაინის ჩანაწერებში. თორემ შემდეგი ინჟინერი 24-საათიან ექსპერიმენტს გაიმეორებს და იმავე კედელს მიაღწევს.
მხარდაჭერილი ნაკრები ქვეყნდება კარიბჭის ტიპისა და IKE-ის ვერსიის მიხედვით Cloud VPN-ის მიმოხილვაში, ამიტომ წაიკითხეთ თქვენი ტოპოლოგიის განყოფილება და არა ზოგადი IKE-ის გზამკვლევი.
გვირაბი, რომელიც გრაფიკის მიხედვით ვარდება
2-ლი ფაზა სხვაგვარად იქცევა: როცა ორი ბოლო არ თანხმდება, გასაღებების განახლება უფრო მოკლე ინტერვალს მიჰყვება. Peer-ი, რომელიც შეუსაბამობას ფატალურად მიიჩნევს, ნაცვლად ამისა გვირაბს აგდებს, ამიტომ ერთი შეუსაბამობა ორ დაუკავშირებელ ხარვეზად შეიძლება გამოიყურებოდეს. აკვირდით გასაღების განახლების რიტმს და არა მხოლოდ პირველ დაკავშირებას. გვირაბი, რომელიც ადის და შემდეგ რეგულარულ ტაქტში ვარდება, უფრო ხშირად ვადის შეუსაბამობაა, ვიდრე მარშრუტიზაციის ხარვეზი.
სანამ რამეს შეცვლით, დაუკავშირეთ ის ვარდნის დროის ნიშნები თავად peer-ის ჟურნალებს, რადგან სელექტორის ან მარშრუტის ცვლილებამ შეიძლება იგივე რიტმი მიბაძოს. თუ ტაქტი 2-ლი ფაზის ტაიმერს ემთხვევა, მიზეზი ნაპოვნია წინადადების შეხების გარეშე.
ნაკრებები კარიბჭის ტიპიდან მოდის
შიფრაციისა და მთლიანობის ნაკრებები არ არის თითო გვირაბის პროფილი, რომელსაც strongSwan-ივით არედაქტირებთ. თქვენ მათ ირჩევთ კარიბჭის ტიპისა და IKE-ის ვერსიის მიხედვით, და არარსებული პროფილის ძებნა მთელ შუადღეს ხარჯავს.
ძველი მოწყობილობა, რომელიც მხარდაჭერილი ნაკრების ფარგლებში არაფერს გთავაზობთ, ორ პატიოსან გზას ტოვებს: შეცვალეთ მოწყობილობა, ან დაასრულეთ თქვენს მიერ კონტროლირებად პროგრამულ კარიბჭეზე და იქიდან მარშრუტიზაცია გაუკეთეთ VPC-ს. ყველაფერი დანარჩენი შემოვლითი გადაწყვეტაა, რომელიც შემდეგ განხილვაზე ჩავარდება.
ერთი გარე მისამართი თითო მოწყობილობაზე
Peer-ის გარე მისამართი ერთ-ერთზე უნდა აისახოს მის შიდა მისამართზე. გადატვირთული PAT აუზი ვერ იმუშავებს, რადგან ერთი საჯარო მისამართის უკან მყოფი რამდენიმე ჰოსტი პასუხისმგებელს მათი გამიჯვნის არავითარ საშუალებას არ აძლევს. სადაც რამდენიმე ჰოსტმა უნდა გაიზიაროს მისამართი, გვირაბი უნდა დასრულდეს იქ, სადაც მათი გარჩევა შეიძლება.
ეს გარე მისამართიც სტაბილურად შეინახეთ. გადაიტანეთ მოწყობილობა სხვა NAT-ის უკან და კავშირი გაწყდება, თუმცა ყველა წინადადება ჯერ კიდევ ემთხვევა. ღირს ჩაწერა, რომელი მნიშვნელობებია Google-ის და რომელი თქვენი: ვადები, ნაკრებები და ერთ-ერთზე NAT მათ მხარეს ფიქსირებულია, ხოლო წინადადებები, სელექტორები, მარშრუტიზაცია და BGP პრიორიტეტები თქვენია.