იზოლირებული TAP ხიდი ორ დაფას შორის OpenVPN-ის მეშვეობით

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

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

რას გადაადგილებს სინამდვილეში ხიდი

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

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

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

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

მისამართი მიეცით ხიდს და არა მის წევრ პორტებს

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

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

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

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

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

მართვის ადაპტერის მიერთება ოფისის LAN-ს განვითარების დაფიდან ერთი გადაცემის გადაწყვეტილების მანძილზე აყენებს, და დაფა, რომელიც მეორე დონეზე ცუდად იქცევა, ზუსტად ის ტიპის მოწყობილობაა, რომელიც ამ სეგმენტზე არ გინდათ. Wi-Fi ადაპტერი უარესია: უსადენო ინტერფეისის ხიდად ქცევა ინფრასტრუქტურულ რეჟიმში არ იქცევა როგორც Ethernet-ის ხიდად ქცევა, და მარცხი გაუგებარია და არა სუფთა.

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

საზღვარი, რომელსაც ხიდი არ ქმნის

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

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

კიდევ ორი ოჯახი იმსახურებს ცალსახა გადაწყვეტილებას. მისამართების გეგმა ხიდს მხოლოდ IPv4-ად არ აქცევს, ამიტომ IPv6-ს და სხვა EtherType-ებს საკუთარი გეგმა ან ფილტრი სჭირდება. და წარმატებული ping არაფერს ამბობს იმაზე, გაივლიან თუ არა გზას დაფის აღმოჩენის მაუწყებლობები, multicast ჯგუფები ან jumbo კადრები, რადგან ეს სხვადასხვა ნაგულისხმევის მქონე სხვადასხვა ტრაფიკის კლასებია.

და ბოლოს, ტრანსპორტი და კონფიდენციალურობა ორი სხვადასხვა შენაძენია. TAP ატარებს Ethernet-ს; OpenVPN სერვისი უზრუნველყოფს დაცვას მის გარშემო. VXLAN გადაფარვა ასევე ატარებს Ethernet-ს და თავისთავად კონფიდენციალურობას არ იძლევა, ამიტომ ერთის მეორით ჩანაცვლება ცვლის უსაფრთხოების თვისებებს მაშინაც, როცა ტოპოლოგიის დიაგრამა იდენტურად გამოიყურება.

მდგრადობა და ტესტები, რომლებიც მას ამტკიცებს

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

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

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