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

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

ნაბიჯი 1: დააკავშირეთ ღრუბლის NIC-ები სტუმრის მოწყობილობებს

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

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

ნაბიჯი 2: დაასახელეთ ორი მარშრუტიზაციის გადაწყვეტილება

პირველი გადაწყვეტილება სტუმარს ეკუთვნის: რომელი ინტერფეისი და რომელი წყაროს მისამართი ამ პაკეტისთვის. მეორე ღრუბელს ეკუთვნის: რას უშვებს VPC-ის მარშრუტები და firewall პოლიტიკა ამ ინტერფეისის გარშემო.

VPN-ისკენ მიმართულ VPC-ში ხილული მარშრუტი არ ხდება სტუმრის მარშრუტი, რომელიც ამ NIC-ს აირჩევს. ღრუბლის მარშრუტი აღწერს, რისი მიწოდება შეუძლია ქსელს, ხოლო სტუმრის მარშრუტი წყვეტს, რას აკეთებს პაკეტი.

ნაბიჯი 3: აირჩიეთ დაბრუნების გზის პოლიტიკა

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

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

ნაბიჯი 4: შეამოწმეთ სტუმრის საკუთარი ფილტრები

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

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

ნაბიჯი 5: გამოსცადეთ ერთი დინება თითოეული გზისთვის

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

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

რასაც მეორე NIC არ გაძლევთ

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

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

დაკავშირებული სტატიები