Մեկուսացված 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-ը անջատելը, քանի որ մեկ շրջանակ կորավ, կոնկրետ սխալը փոխում է ընդհանուրով։

Կամրջի և յուրաքանչյուր կառավարման կամ uplink ինտերֆեյսի միջև IP փոխանցումը պետք է մնա անջատված կամ բացահայտ արգելված, և դա կամրջի անդամակցությունից առանձին հսկողություն է: Սալիկը, որն ընտրում է համակարգչի լաբորատոր հասցեն որպես իր դարպաս, հենց սա է փորձարկում։ եթե կառավարման անցումը հաջողվում է, ձեր նկատի ունեցած սահմանը երբեք այնտեղ չի եղել։

Եվս երկու ընտանիք արժանի են բացահայտ որոշման։ Հասցեավորման պլանը կամուրջը միայն 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

Ապա փորձարկեք, թե սալիկներին իրականում ինչ է պետք երկու ուղղություններով, վերամիացրեք թունելը և վերագործարկեք մեկ համակարգիչ հաստատված վերականգնման պլանի համաձայն։ Դրանից հետո հաստատեք երեք բան: կառավարման հասանելիությունը դեռ աշխատում է ինքնուրույն, կրկնօրինակ լաբորատոր հասցե չի հայտնվում, և ոչ մի անսպասելի արտադրական ինտերֆեյս չի միացել կամրջին։ Այդ համակցությունը ապացույցն է, որ փորձը մնաց իր ստենդի սահմաններում։