უნდა ჩართოთ AWS VPN გვირაბის ჟურნალები მოქმედ გვირაბზე?

Site-to-Site VPN-ისთვის გვირაბის აქტივობის ჟურნალების ჩართვა პატარა ცვლილებაა, რომელმაც შეიძლება ჩამოაგდოს გვირაბი, რომელსაც ის ზომავს. AWS აფრთხილებს, რომ არსებულ გვირაბზე ჟურნალირების ჩართვამ შეიძლება ის რამდენიმე წუთით შეწყვიტოს, ამიტომ საინტერესო კითხვა არ არის როგორ გადავატრიალოთ დროშა, არამედ რომელ გვირაბზე და როდის. რიგს სამი პირობა განსაზღვრავს: გადააქვს თუ არა მეორე გვირაბს რეალურად მარშრუტები, გჭირდებათ სერვისის მოვლენები თუ BGP მოვლენები, და ცვლილება კონსოლით მიდის თუ გვირაბის პარამეტრების API-ით. თუ ამაში შეცდებით, ან შეწყვეტით დარჩებით, ან არაფრით სავსე ჟურნალების ჯგუფით.

რიგს სამი პირობა განსაზღვრავს

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

დანიშნულება იმავე რეგიონში CloudWatch ჟურნალების ჯგუფია, იმ შენახვისა და წვდომის პოლიტიკით, რომელიც ნამდვილად გსურთ. AWS ამ ჯგუფებისთვის /aws/vendedlogs/ პრეფიქსს გირჩევთ, რადგან ის თავიდან აიცილებს რესურსის პოლიტიკის ზომის ლიმიტებს, რომლებსაც ჩვეულებრივი სახელები შეიძლება წააწყდეს. /aws/vendedlogs/vpn/branch-a-activity-ის მსგავსი სახელი მხოლოდ მაგალითია; მთავარია, რომ ჯგუფი არსებობს, მიწოდების როლი მასში წერას ახერხებს და ორივეს VPN კონფიგურაციის მფლობელი მართავს. სახელი ნებართვებს არ იძლევა, ხოლო მიწოდების პოლიტიკის გარეშე შექმნილი ჯგუფი შეცდომის ნაცვლად სიჩუმეს ქმნის.

პირველი პირობა: სარეზერვო გვირაბი, რომელიც რეალურად ატარებს ტრაფიკს

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

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

მეორე პირობა: აქტივობის ჟურნალი თუ BGP ჟურნალი

ეს განსაზღვრავს, რისი წაკითხვა შეძლებთ სინამდვილეში. აქტივობის ჩანაწერები მოიცავს სერვისის მოვლენებს, როგორიცაა IKE-ისა და IPsec-ის მდგომარეობის გადასვლები და DPD შეტყობინებები, რაც გსურთ, როცა გვირაბი არ ადის ან მუდმივად აახლებს გასაღებებს. BGP ჩანაწერები ცალკე ნაკადია საკუთარი კონტროლით და სხვა კითხვას პასუხობს: გაიცვალა და გაუქმდა თუ არა მარშრუტები როგორც მოსალოდნელი იყო.

აქტივობის დროშის ჩართვა არ არის მოთხოვნა ყველა ნაკადზე, რომელიც სერვისს შეუძლია გამოუშვას. თუ ეჭვი მარშრუტიზაციაშია, ჩართეთ ორივე; თუ ეჭვი 1-ლი თუ მე-2 ფაზის მოლაპარაკებაშია, აქტივობის ნაკადია ის, რაც ამას აჩვენებს.

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

მესამე პირობა: კონსოლით ცვლილება თუ გვირაბის პარამეტრების API

თუ ადამიანი ერთჯერად ცვლილებას აკეთებს, კონსოლის გზა ნორმალურია: VPC console, Site-to-Site VPN connections, აირჩიეთ კავშირი, Actions, Modify VPN tunnel options, აირჩიეთ გარე IP, ჩართეთ Tunnel activity log, აირჩიეთ ჯგუფი და გამოსავლის ფორმატი, შეინახეთ ფანჯრის შიგნით. თუ VPN კოდად იმართება, იგივე დაწკაპუნება დრიფტია, რომელსაც მოგვიანებით შეათანხმებთ.

ავტომატიზაციისთვის გვირაბის პარამეტრების აქტივობის-ჟურნალის ნაწილს ფიქსირებული ფორმა აქვს: LogOptions შეიცავს CloudWatchLogOptions-ს LogEnabled, LogGroupArn და LogOutputFormat ველებით. ეს ბლოკი ფრაგმენტია და არა მოთხოვნა; modify-vpn-tunnel-options კვლავ სჭირდება კავშირის ID და გვირაბის გარე IP, დარჩენილი გვირაბის პარამეტრები კი შაბლონის მფლობელმა უნდა შეინარჩუნოს. BGP ჟურნალირება იყენებს საკუთარ BgpLogEnabled, BgpLogGroupArn და BgpLogOutputFormat გასაღებებს იმავე სტრუქტურაში. წაიკითხეთ ცვლილება უკან describe-vpn-connections-ით, ნაცვლად იმისა, რომ დაიჯეროთ გამოძახების გამოყენება.

რა შეიძლება და რა არ შეიძლება გითხრან ჩანაწერებმა

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

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

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