TAP ხიდი ერთი VLAN-ისთვის: შეუერთეთ ქვეინტერფეისი

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

ერთი VLAN გაფართოება ნიშნავს ერთ layer-2 დომენს და ხიდი უნდა შეუერთდეს ამ დომენს და არა trunk-ს, რომელიც ყველას ატარებს.

ტეგი არ ჩნდება, რადგან trunk-ს გადახურეთ

აიღეთ Linux uplink eno1, რომელიც VLAN 120-ს მართვად სვიჩამდე მიჰყავს. დიზაინი, რომელიც ერთი VLAN-ისთვის მუშაობს, არის tap_vpn-ის გადახურვა br_vpn-ზე, სადაც br_vpn შეიცავს eno1.120-ს და არა eno1-ს. VLAN ქვეინტერფეისი ტეგს გასვლისას ადებს და შესვლისას ხსნის, ამიტომ ხიდი მხოლოდ უტეგო კადრებს ხედავს იმ ერთი VLAN-ისთვის. სამაგიეროდ ფიზიკური ინტერფეისი ჩადეთ ხიდში და იგივე კადრები trunk პორტიდან უტეგოდ გავა, რაც არ არის ის, რაც დაგეგმეთ.

trunk-ის გადახურვა VLAN ფილტრაციის გამორთვით არ არის მოკლე გზა იმავე შედეგამდე. ეს ხიდს აძლევს ყველა VLAN-ს ამ კაბელზე, მათ შორის მათაც, რომლებიც კლიენტებმა არ უნდა დაინახონ.

ორი ლეგიტიმური დიზაინი, ერთი ტეგის მფლობელი

VLAN-ის მცოდნე ხიდი მეორე სწორი განლაგებაა: trunk შედის ხიდის პორტში და პორტების წევრობა, PVID და ტეგიანი გასვლის პარამეტრები წყვეტს, რომელი VLAN-ები გაივლიან. იქ ტეგირებას ხიდი ფლობს და მის ქვეშ VLAN ქვეინტერფეისის დამატება ერთი საქმისთვის მეორე მფლობელს დააყენებდა. ორივე დიზაინი მუშაობს; ორივეს ნაწილები არა. გადაწყვიტეთ, რომელი ობიექტი ადებს ტეგს, სანამ რომელიმე წევრთა სიას შეასწორებთ.

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

მისამართი წევრობასთან ერთად გადაიტანეთ

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

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

კლიენტების მისამართებს იგივე ყურადღება სჭირდება. გადახურული VPN კლიენტებს გაფართოებულ ქვექსელში ათავსებს, ამიტომ აუზი არ უნდა გადაფარდეს სხვა იჯარებს ან სტატიკურ მინიჭებებს და DHCP-ით მომსახურებული განლაგება უნდა იყოს ის, რასაც LAN ნამდვილად ელის. მომუშავე layer-2 გზა არაფერს ამბობს დუბლირებულ მისამართებზე.

წევრობა შეამოწმეთ, სანამ მარშრუტებს დაადანაშაულებთ

წაიკითხეთ მიმდინარე და არა განზრახ მდგომარეობა: ip -d link show dev eno1.120 ბეჭდავს VLAN id-ს და მის მშობელს, ip link show master br_vpn ჩამოთვლის ხიდის წევრებს, ხოლო bridge vlan show იუწყება პორტების წევრობასა და გასვლის დამუშავებაზე. ქვეინტერფეისის დიზაინში დარწმუნდით, რომ TAP მოწყობილობა და VLAN მოწყობილობა წევრები არიან. VLAN-ის მცოდნე ხიდში შეამოწმეთ თავად პორტის პოლიტიკა, რადგან ხიდის არსებობა არ ამტკიცებს, თუ რას უშვებს.

შემდეგ შეამოწმეთ ერთი ნებადართული კლიენტი იმ VLAN-ის სერვისის წინააღმდეგ, გაიხსენეთ რომ ARP, firewall-ის პოლიტიკა და პასუხის გზა წევრობისგან ცალკე საკითხებია. თუ პაკეტებს იჭერთ, გაითვალისწინეთ, რომ აპარატურულ offload-ს შეუძლია შეცვალოს, სად ჩნდება VLAN ტეგები კვალში. მოცულობაც პატიოსნად შეინახეთ: მარშრუტიზებული TUN კლიენტი ვერც ერთი ხიდის ცვლილებით არ გახდება VLAN წევრი და კლიენტ-კლიენტ ტრაფიკი არ ცვლის ჰოსტის კავშირს VLAN-თან.