Google HA VPN Cisco-ის როუტერთან: ჯერ თანატოლის რესურსი დაგეგმეთ
Cisco როუტერის კონფიგურაციამდე დაასახელეთ Google-ის ორივე ინტერფეისი, თანატოლის რესურსი, IKEv2 კონტრაქტი და ყოველი BGP სესია, შემდეგ აირჩიეთ ერთი თანატოლი ან ორი.
Cisco-დან Google-მდე HA VPN-ში პირველი გადაწყვეტილება არ არის რომელი კრიპტო პროფილი გამოიყენოს, არამედ ის, ერთი ლოკალური მოწყობილობა დაასრულებს გვირაბებს თუ ორი. Google-ის HA VPN კარიბჭეს ორი ინტერფეისი აქვს და თითოეული შესაბამის თანატოლის გვირაბს ელის. ეს გაძლევთ ორ გვირაბს, ორი როუტერი გაქვთ თუ არა, და განსხვავება იმაშია, შეუძლია თუ არა ერთ კვების წყაროს ან პროგრამული განახლების მთელი დიზაინის ჩამოშლა.
გადაწყვეტილება არის ერთი თანატოლი მოწყობილობა თუ ორი
აირჩიეთ განლაგება სამი პირობის მიხედვით: შეგიძლიათ თუ არა ლოკალური ჩავარდნის წერტილის მიღება, საჭიროა თუ არა ორივე ღრუბლოვანი ინტერფეისის გამოყენება და რამდენ ხელახალ კონვერგენციას იტანს თქვენი დატვირთვები. თუ სამიდან რომელიმე მკაცრი მოთხოვნაა, ორი თანატოლი მოწყობილობაა პატიოსანი პასუხი.
გადაწყვიტეთ ეს კონსოლის გახსნამდე, რადგან პასუხი ცვლის, რამდენი გვირაბი და BGP სესია უნდა აღწეროს სამუშაო ფურცელმა.
დაწერეთ სამუშაო ფურცელი ნებისმიერ ბრძანებამდე
სამუშაო ფურცელს ხუთი სტრიქონი აქვს და თითოეულს მფლობელი სჭირდება:
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
გარე თანატოლის რესურსი აღწერს თქვენს ინტერფეისებს Google Cloud-ში და მისი შექმნა არ აკონფიგურირებს Cisco როუტერს. ეს ასიმეტრია აკვირვებს მათ, ვინც ელოდება, რომ ღრუბლოვანი კონსოლი იქნება სიმართლის წყარო ორივე ბოლოსთვის. ეს არის განცხადება იმის შესახებ, თუ რას უნდა ელოდოს Google-ი, და როუტერს მაინც უნდა შეესაბამებოდეს მას. Google-ის თანატოლის კარიბჭის სახელმძღვანელო ამ განცხადებას ასახავს გვირაბის, BGP-ის, ფაირვოლის და IKE-ის იმ სამუშაოზე, რომელიც ჯერ კიდევ გაქვთ.
თუ სტრიქონს მფლობელი არ ჰყავს, მას შეავსებს ის, ვინც გადასვლის დროს ცვლაშია.
სამი მისამართის როლი ცალ-ცალკე შეინახეთ
საჯარო თანატოლის მისამართები გარე IPsec გაცვლას ატარებენ. შიდა BGP წყვილი ეკუთვნის დაცულ ლოგიკურ კავშირს, რომელიც მის თავზე გადის. გამოცხადებული LAN და VPC პრეფიქსები აღწერს იმ კავშირის უკან არსებულ დატვირთვებს. VM-ის შიდა მისამართის გარე თანატოლის ველში კოპირება ერთმანეთში ურევს პირველ ორ როლს, და ჩავარდნა მოლაპარაკების პრობლემას ჰგავს და არა მონაცემთა შეყვანის შეცდომას.
დაგეგმეთ ორი შესაბამისი თანატოლის გვირაბი, თითო ყოველი HA VPN ინტერფეისისთვის. ორივე ღრუბლოვანი ინტერფეისის გამოყენება თავისთავად არ აქრობს ლოკალურ ჩავარდნის წერტილს, რადგან ორივე გვირაბი მაინც შეიძლება ერთსა და იმავე კორპუსზე დაეშვას.
დაწერეთ მისამართის როლი სამუშაო ფურცლის ყოველი მნიშვნელობის გვერდით. ეს ერთი ჩვევა ხელს უშლის შერევის უმეტეს ნაწილს.
თარგმნეთ სამუშაო ფურცელი Cisco-ის გამოშვებაში
დაიწყეთ მხარდაჭერილი თანატოლის დოკუმენტაციიდან ან თქვენი პლატფორმისთვის შესაფერისი Google კონფიგურაციის შაბლონიდან, შემდეგ შეათანხმეთ ყოველი დროებითი ადგილი სამუშაო ფურცელთან. შეამოწმეთ IKEv2 ავთენტიფიკაცია, ESP შეთავაზებები, PFS და გვირაბისა და მარშრუტიზაციის მოდელი ერთად, რადგან ერთ მათგანში შეუსაბამობა ჩვეულებრივ ვლინდება როგორც შეუსაბამობა მეორეში. გამოიყენეთ ფაქტობრივი პლატფორმა და პროგრამული გამოშვება იმის ასარჩევად, თუ რა არის მხარდაჭერილი, ვინაიდან Classic VPN-ის რეცეპტი სხვა საწყისი წერტილია.
შეინახეთ საერთო საიდუმლო ეკრანის სურათებისგან, ბილეთის დანართებისგან და მხარდაჭერის ჩანაწერებისგან მოშორებით. საქმის კომენტარში ჩასმული წინასწარ გაზიარებული გასაღები სერტიფიკატების გამჟღავნებაა და არა ხარვეზების აღმოფხვრის არტეფაქტი.
თუ შაბლონი და სამუშაო ფურცელი არ ემთხვევა, გაჩერდით და ქაღალდზე გადაწყვიტეთ. მოწყობილობა თქვენ ნაცვლად არ იმსჯელებს.
მიიღეთ ყოველი გვირაბი მისივე მტკიცებულებით
HA VPN-ს BGP სესიები სჭირდება და წარმატებული IKE მოლაპარაკება მხოლოდ პირველ ეტაპს ამყარებს. შიდა სესია უნდა ამოვიდეს, განზრახული პრეფიქსები უნდა გამოცხადდეს და მიღებულ იქნას, და სასარგებლო მარშრუტები პლუს ფაირვოლის ნებართვები უნდა არსებობდეს სანამ დატვირთვის ტრაფიკი გადაადგილდება. ამ ყველაფრის ერთ მწვანე შუქად ჩაწერა მალავს, რომელი ეტაპი რეალურად ჩავარდა.
ჩაწერეთ მიღების მტკიცებულებები თითოეული გვირაბისთვის: შეთანხმებული უსაფრთხოების ასოციაციები, BGP მეზობლის მდგომარეობა, მოსალოდნელი ნასწავლი პრეფიქსები და განზრახული დატვირთვის გზა. შემდეგ ჩაატარეთ კონტროლირებული ჩავარდნისა და აღდგენის შემოწმება, რადგან გვირაბი, რომელსაც არასდროს უჩავარდნია, არის გვირაბი, რომლის აღდგენის გზა არ გამოცდილა.
ეს ჩანაწერი ხელახლა გამოსაყენებელია შემდეგ ჯერზე, როცა დიზაინი შეიცვლება, და ეს არის განსხვავება თავსებადობასა და ბრძანების ფრაგმენტს შორის, რომლის ვარაუდები დაიკარგა.