Փորձարկեք VPN երթուղավորումը անվանատարածքներում՝ առանց հոսթի երթուղիներին դիպչելու
Երեք մոդելավորված դերեր, երեք մեկուսացված համատեքստեր և մեկ veth յուրաքանչյուր կապի համար։ Համեմատեք անվանատարածքային լաբորատորիան հոսթի երթուղիների լաբորատորիայի հետ նախքան հոսթին դիպչելը։
Երկու լաբորատորիաներ կարող են մոդելավորել նույն VPN տոպոլոգիան և ձախողվել բոլորովին տարբեր ձևերով. մեկը ապրում է ցանցային անվանատարածքներում, մյուսը՝ հոսթի սեփական երթուղիներում։ Անվանատարածքային տարբերակը պահում է յուրաքանչյուր ինտերֆեյս, երթուղի և սոքետ այնպիսի համատեքստում, որը կարող եք ջնջել, մինչդեռ հոսթի տարբերակը ավելի արագ է սկսվում և իր հետևում վիճակ է թողնում։ Այդ մնացած վիճակն է պատճառը, որ երկրորդ լաբորատորիան մեկ ամիս անց դժվար է կրկնել։ Նախ համեմատեք մաքրումը, որովհետև այն որոշում է՝ կարող եք փորձը երկու անգամ անցկացնել, թե ոչ։
Նույն լաբորատորիան կառուցելու երկու եղանակ, և երբ է հաղթում յուրաքանչյուրը
Հոսթի երթուղիների լաբորատորիայում դուք թունելային ինտերֆեյս և երթուղիներ եք ավելացնում այն մեքենային, որի վրա աշխատում եք, ուստի փորձը ճակատագիրը կիսում է ձեր shell-ի, ձեր փաթեթների կառավարչի և ցանկացած այլ կապի հետ։ Անվանատարածքային լաբորատորիայում յուրաքանչյուր դեր ստանում է ինտերֆեյսների, հասցեների, երթուղիների և սոքետների իր սեփական կույտը, և անվանատարածքը ջնջելը հեռացնում է այդ ամենը։ Մոդելներից ոչ մեկն ավելի ճիշտ չէ, որովհետև նրանք տարբեր հարցերի են պատասխանում։ Ընտրեք անվանատարածքներ, երբ թեման երթուղավորումն ու փոխանցումն է, և հոսթի լաբորատորիա, երբ թեման այն է, թե ինչպես է ինտեգրվում մեկ աշխատասեղանի հաճախորդ։
| Aspect | Namespace lab | Host-route lab |
|---|---|---|
| Isolation | Full stack per role | Shares the host stack |
| Cleanup | Delete named namespaces | Manual route and rule removal |
| Realism | Strong for routing | Needed for GUI clients |
Երկուսը խառնելը սովորական սխալ է. անվանատարածքային լաբորատորիան, որը փորձարկվել է միայն հոսթի հաճախորդի դեմ ոչինչ չի ապացուցում երկու դասավորություններից ոչ մեկի մասին։ Որոշեք, թե ինչ հարց եք տալիս, նախքան առաջին կապը ստեղծելը։
Մեկ համատեքստ յուրաքանչյուր դերի համար՝ դիտավորյալ միացված
Ստեղծեք մեկ անվանատարածք յուրաքանչյուր դերի համար և տեղափոխեք յուրաքանչյուր veth զույգի յուրաքանչյուր ծայրը այն համատեքստը, որը տիրապետում է դրան։ Առաջին չորս հրամանները բավական են ձևը տեսնելու համար:
ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns clientՏվեք լաբորատորիային միջակայքեր, որոնք ոչնչի հետ չեն համընկնում հոսթի վրա, և մինչ սկսելը գրեք, թե որ անվանատարածքն է տիրապետում որ հասցեին։ Աշխատող լաբորատորիային պետք է երկու առանձին ուղի՝ արտաքին մեկը, որպեսզի VPN վերջնակետը հասնի իր զույգին, և վերադարձի ուղի պաշտպանվող ռեսուրսի համար։ Մոդելավորեք դրանք որպես երկու որոշում, որովհետև լաբորատորիան, որը կառուցում է միայն ելքային կեսը, անցնում է ձեռքսեղմման թեստը և ձախողվում հավելվածի թեստում։
Փոխանցման դերն այն տեղն է, որտեղ լաբորատորիաները դառնում են հետաքրքիր
Մեկ դերը պետք է փոխանցի, ինչը նշանակում է միացնել փոխանցումը այդ անվանատարածքի ներսում և ավելացնել այն կանոնը, որն անհրաժեշտ է դիզայնին։ Փոխանցման վիճակը յուրաքանչյուր անվանատարածքի համար է, ուստի հոսթի կարգավորումը անհամապատասխան է լաբորատորիայի համար, և լաբորատորիայի կարգավորումը չի արտահոսում դուրս, ինչպես նկարագրում է ցանցային անվանատարածքների փաստաթղթերը։ WireGuard-ը փաստում է, որ ինտերֆեյսը և նրա արտաքին սոքետը կարող են ապրել տարբեր անվանատարածքներում, ինչը օգտակար հնարք է և ձեզ շփոթեցնելու հիանալի միջոց։ Մի ենթադրեք, որ ինտերֆեյսը տեղափոխելը տեղափոխում է կապի յուրաքանչյուր մասը նույն կերպ։
Ստուգեք փոխանցման հաշվիչը փորձնական փաթեթից հետո, որովհետև երբեք չհամընկած կանոնը և փաթեթը գցած կանոնը երթուղիների աղյուսակում նույն տեսքն ունեն։ Միայն հաշվիչներն են տարբերում դրանք։
Գրանցեք բազային գիծ, ապա կոտրեք մեկ երթուղի
Սկսեք գրանցելով, թե ինչ կա, համատեքստը գրելով յուրաքանչյուր տողի կողքին։ Կարդացեք անվանատարածքները, ապա այն երթուղին, որը փորձնական նպատակակետը կանցնի դրանցից մեկի ներսում, ապա հաշվիչները այն կապի վրա, որը տանում է այն:
ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-gԵրրորդ հրամանն այն է, որ մարդիկ բաց թողնում են, և հենց այնտեղ է ապացույցը. գցվածների և սխալների հաշվիչները ձեզ ասում են՝ փաթեթը հասե՞լ է փոխանցման դերին ընդհանրապես։ Գրանցեք նույն երեք տեսքերը փոփոխությունից հետո, և թող diff-ը լինի ապացույցը, ոչ թե ձեր հիշողությունը։ Այնուհետև կոտրեք ճիշտ մեկ բան՝ կա՛մ երթուղին ջնջելով, կա՛մ փոխանցման ուղու վրա մերժման կանոն ավելացնելով, և հաստատեք ձեր կանխատեսած ախտանիշը՝ ավարտված ձեռքսեղմում առանց պատասխանի, կամ անվան լուծման ձախողում ժամկետի սպառման փոխարեն։ Այն լաբորատորիան, որը ցուցադրում է միայն հաջողություն, շատ քիչ բան է սովորեցնում։
Մաքրումն է այն, ինչ հաջորդ անցկացումը դարձնում է կրկնելի
Մաքրումը պահեք ձեր նշած ռեսուրսների սահմաններում, որովհետև ամբողջական firewall-ի վերակայումը կամ հոսթի երթուղու հեռացումը կրկնելիություն չէ, այլ երկրորդ միջադեպ։ Պահեք տոպոլոգիան, ճշգրիտ հրամանները և այն դիտարկումները, որոնք սպասում էիք, որպեսզի հաջորդ անցկացումը վերարտադրի նույն խափանումը՝ փոխարենը գուշակելու, թե որ համատեքստում էր նախորդ վիճակը։ Առանց այդ գրառման լաբորատորիան պատմություն է, ոչ ընթացակարգ։
Օգտագործեք տեղում ստեղծված հավատարմագրեր լաբորատորիայի համար, և արտադրական հաշիվները հեռու պահեք ընդհանուր օրինակներից։ Ապա ջնջեք յուրաքանչյուր անվանատարածք և հաստատեք, որ հոսթի տեսքը անփոփոխ է, ինչը այս մոդելն ընտրելու ամբողջ պատճառն է։ Լաբորատորիան, որը չեք կարող մաքուր հեռացնել, հոսթի փոփոխություն է լրացուցիչ քայլերով։