წყაროს/დანიშნულების შემოწმება ერთი კარიბჭეა, და არა მთელი VPN გზა

VPN მთავრდება EC2 ინსტანსზე, შეგიძლიათ მიაღწიოთ ამ ინსტანსის გვირაბის მისამართს, და ტრაფიკი, რომელიც უნდა გასულიყო მის გავლით სხვა კერძო ჰოსტისკენ, ქრება. ეს ორი განსხვავებული ტესტია და მათი შერევა საათებს კარგავს. პირველი კითხულობს, შეგიძლიათ თუ არა ინსტანსამდე მისვლა; მეორე მოითხოვს, რომ მან გადასცეს ტრაფიკი ისეთი დანიშნულებისთვის, რომელიც მისი საკუთარი არ არის, რაც მოითხოვს Linux გადაცემას, firewall პოლიტიკას, მარშრუტს შორეულ მხარეს და AWS დონის ნებართვას, რომელსაც არაფერი აქვს საერთო სტუმარ ოპერაციულ სისტემასთან. კონსოლში არაფერი ამახვილებს ყურადღებას ამ განსხვავებაზე. სიმპტომი მარშრუტიზაციის ხარვეზს ჰგავს და ჩვეულებრივ ასე არ არის.

გაყავით ორი ტესტი, სანამ რამეს შეცვლით

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

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

ჩაწერეთ გზა, სანამ რომელიმე პარამეტრს შეეხებით

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

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

ოთხი საზღვარი, და შემოწმება მხოლოდ ერთია მათგან

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

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

თარგმნა ცვლის, რომელ წყაროს ხედავს დანიშნულება

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

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

ტესტეთ ორიგინალური კლიენტიდან, შემდეგ შეინარჩუნეთ ცვლილება

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

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