ESXi სტუმარი VPN: მარშრუტიზაცია თუ ხიდი — გადაწყვიტეთ პორტის ჯგუფამდე
მარშრუტიზებულ TUN-ს დაბრუნების მარშრუტები სჭირდება; ხიდურ TAP-ს — მე-2 დონის წვდომა და უფრო ფართო პორტის ჯგუფის პოლიტიკა. განსაზღვრეთ როლი promiscuous რეჟიმის გაფართოებამდე.
მარშრუტიზაცია გაუკეთეთ პაკეტებს ან გააფართოვეთ Ethernet დომენი: პორტის ჯგუფის ცვლილება ამ არჩევანის შემდეგ მოდის. კერძო მისამართის მქონე აპლიკაციიდან შედეგები შეიძლება იდენტურად გამოიყურებოდეს, თუმცა ჰიპერვიზორის მოთხოვნები სრულიად განსხვავებულია. ამიტომ ჯერ პორტის ჯგუფი ფართოვდება, ხოლო დიზაინის კითხვას მეორე რიგში პასუხობენ, ჩვეულებრივ broadcast-ქარიშხლის შემდეგ. გაიარეთ ეს შემოწმებები თანმიმდევრობით და გაჩერდით, სანამ მოთხოვნა ბუნდოვანია, რადგან არცერთი პორტის ჯგუფის პარამეტრი არ ასწორებს დიზაინს, რომელიც არასდროს არჩეულა.
გადაწყვეტილება სერვისის მფლობელს ეკუთვნის; ჰიპერვიზორის კონფიგურაციამ ის უნდა განახორციელოს და არა შემთხვევით განსაზღვროს.
შეამოწმეთ, რა სჭირდება შორეულ მხარეს სინამდვილეში
ჩამოთვალეთ სერვისები, რომლებსაც დისტანციური კლიენტები უნდა მიაღწიონ, და პროტოკოლები, რომლებსაც იყენებენ. თუ სია ცნობილ პრეფიქსებზე რამდენიმე TCP სერვისია, მარშრუტიზაცია საკმარისია. თუ რაღაცას ნამდვილად სჭირდება მე-2 დონის მეზობლობა — broadcast-ზე დამოკიდებული აღმოჩენა, არა-IP პროტოკოლები, მოწყობილობა, რომელიც არ იღებს კარიბჭეს — მარშრუტიზაცია ამას ვერ მიბაძავს და ეს ადრე უნდა ითქვას. იყავით გულწრფელი ამ სიაში არა-IP ჩანაწერების მიმართ, რადგან სწორედ იქ იშლება მარშრუტიზებული დიზაინი ჩუმად ერთი კვირის შემდეგ.
შემდეგ შეამოწმეთ კლიენტების აუზი. მარშრუტიზებულ დიზაინს სჭირდება მისამართების დიაპაზონი და ცხადი დაბრუნების მარშრუტი შორეულ მხარეს; ხიდურ დიზაინს სჭირდება, რომ გაფართოებულ Ethernet დომენს ჰქონდეს მისამართების განაწილება და იზოლაცია. რასაც აირჩევთ, ამ VM-ის გარეთ ვიღაცამ უნდა დაეთანხმოს.
რას მოითხოვს ყოველი დიზაინი ვირტუალური ქსელისგან
ორი დიზაინი განსხვავდება იმით, რისი გადატანა უწევს ვირტუალურ ქსელს, და ცხრილი ამის დანახვის უმოკლესი გზაა:
| დიზაინი | როლი სტუმრის მხარეს | რა უნდა დაიტიოს ვირტუალურმა ქსელმა | მარცხის რეჟიმი არასწორი არჩევანისას |
|---|---|---|---|
| მარშრუტიზებული TUN | მარშრუტიზატორი ცალკეულ პრეფიქსებს შორის | მარშრუტიზებული კლიენტების აუზი და დაბრუნების გზები შორეულ მხარეს | კლიენტები აღწევენ კარიბჭეს და არასდროს აღწევენ მის უკან არსებულ სერვისს |
| ხიდური TAP | მე-2 დონის ხიდი მიერთებული კლიენტებისთვის | დამატებითი Ethernet იდენტობები, broadcast ტრაფიკი და VLAN წესები | vSwitch ყრის კადრებს, ან დიზაინს სჭირდება promiscuous რეჟიმი, რომელიც არავის დაუმტკიცებია |
მარშრუტიზაცია ტოვებს broadcast დომენს თავის ადგილას და ბუნებრივ ადგილს გაძლევთ შეზღუდოთ, რომელი სერვისები გადაკვეთს კარიბჭეს. ხიდი ზღვარს ამოძრავებს: კლიენტები ხდებიან გაფართოებული Ethernet დომენის მონაწილეები და მისამართების განაწილება, იზოლაცია და ნებისმიერი მე-2 დონის პოლიტიკა ახლა მათზე ვრცელდება. ჩაწერეთ არჩეული სტრიქონი ცვლილებების ჟურნალში. წინადადება, როგორიცაა «მარშრუტიზებული TUN, კლიენტების აუზი 10.90.0.0/24, დაბრუნების მარშრუტი ბირთვზე», ხელს უშლის შემდეგ ინჟინერს კვლავ იმსჯელოს დიზაინზე პორტის ჯგუფის პარამეტრებიდან.
ვის უნდა შეეძლოს ვისი კადრების ნახვა
პორტის ჯგუფს შეხებამდე ერთი კითხვა დაუსვით პლატფორმის მფლობელს: მოითხოვს დიზაინი, რომ ამ VM-მა მიიღოს სხვა მონაწილეებისთვის მიმართული კადრები? თუ პასუხი არაა, ამ განყოფილებაში არაფერი ვრცელდება, რადგან მარშრუტიზებულ TUN-ს ეს ხილვადობა არასდროს სჭირდება. თუ პასუხი კია, მაშინ Broadcom-ის სახელმძღვანელო promiscuous რეჟიმის შესახებ არის მთავარი საკითხავი: ის ხსნის, რამდენად მეტს ხედავს VM vSwitch-იდან და გვირჩევს ამ პოლიტიკის ერთ პორტის ჯგუფზე შეზღუდვას.
მოეპყარით ამას მოთხოვნის შემოწმებად და არა ნებართვად. ჩართეთ პარამეტრი ერთი გამოყოფილი მიერთებისთვის, როცა ხიდის საჭიროება ჩაწერილია, და დატოვეთ გამორთული ყველგან სხვაგან. სხვა ხიდის მაგალითიდან კოპირებული ფართო VLAN trunk არის ის ნაწილი, რომლის წაშლა არავის ახსოვს, და ერთი VLAN-ის დიზაინი ერთ VLAN-ად უნდა დარჩეს.
ჩაწერეთ, რომელი პორტის ჯგუფი შეიცვალა და რატომ, იმავე ადგილას, სადაც დიზაინის სტრიქონი დაწერეთ. სწორედ ეს წყვილი ხდის შესაძლებელს შემდეგ აუდიტს.
შეინახეთ სტუმრის ობიექტები ცხადად
Linux-ის შიგნით ხიდის წევრობა და მისამართის საკუთრება ცალკე ობიექტებია და მათი არევა იწვევს დამაბნეველ ნახევრად მომუშავე მდგომარეობას. მისამართები მიაკუთვნეთ ხიდის ინტერფეისს ან მარშრუტიზებულ გვირაბს, და არა ერთი და იმავე გზის ორივე მხარეს, და წევრი პორტები IP კონფიგურაციისგან თავისუფლად შეინახეთ.
მოერიდეთ ერთი ქვექსელის დამოუკიდებლად განთავსებას მარშრუტიზებულ TUN-ზე და უკავშირო Ethernet ინტერფეისზე. ასეთი კონფიგურაცია ქმნის ორ გზას ერთსა და იმავე პრეფიქსამდე, ასიმეტრიულ პასუხებს და მხარდაჭერის თემას flapping-ის შესახებ, რომელიც არცერთ გზას არ იხსენიებს. თუ სტუმარი ასევე მასპინძლობს კონტეინერებს ან ლოკალურ ჰიპერვიზორს, შეამოწმეთ, რომ ისინი უკვე არ ხიდავენ იმავე uplink-ში. ერთ NIC-ზე ორი ხიდი დიზაინია და არა შემთხვევა, რომლის აღმოჩენაც ცვლილების ფანჯარაში გინდათ.
დაადასტურეთ პაკეტის გზით და არა ping-ით
შეამოწმეთ ფაქტობრივი გზა და არა მხოლოდ ხელმისაწვდომობა. კლიენტიდან დაადასტურეთ, რომელი წყაროს მისამართი აღწევს შორეულ სერვისამდე, შემდეგ რომ პასუხი იმავე გზით ბრუნდება. სტუმარზე შეამოწმეთ კონკრეტული ნაკადის გადაცემის მრიცხველები, ხოლო პორტის ჯგუფზე დაადასტურეთ, რომ არჩეული დიზაინის მოთხოვნაზე მეტი ხილვადობა არ ჩართულა.
ბოლოს გამოსცადეთ მარცხის მიმართულება. გააჩერეთ გვირაბი ან გათიშეთ კლიენტი და შეამოწმეთ, რომ ტრაფიკი ჩუმად არ ვარდება მარშრუტიზებულ გზაზე, რომელიც გამოუყენებლად გეგონათ, რადგან სწორედ ეს დაცემაა ის, რითაც ხიდური დიზაინი ჩუმად უნებლიე მარშრუტიზატორი ხდება.