Երկու VPN մեկ Linux մեքենայի վրա. փորձարկեք յուրաքանչյուրը առանձին՝ առանց արդյունքները խառնելու
Երկու կանաչ պատկերակ դեռ համեմատություն չեն։ Տեղադրեք յուրաքանչյուր թունելը իր անվանատարածքում, նախապես գրառեք սպասումը և ապացուցեք ուղին, մինչև արդյունքին վստահելը։
Երկու կանաչ միացման պատկերակ համեմատության տեսք ունեն և սովորաբար պատահականություն են։ Եթե փորձարկման հարցումը կարող էր օգտագործել երկու թունելներից որևէ մեկը, արդյունքը լավագույն դեպքում նկարագրում է դրանցից մեկը, իսկ վատագույն դեպքում՝ ոչ մեկը։ Յուրաքանչյուր դիտարկման տվեք ցանցային համատեքստ, նպատակային հասցե և փորձարկումից առաջ գրված սպասում։ Ինքնուրույն կառավարվող Linux մեքենայի վրա անվանված ցանցային անվանատարածքները այդ բաժանումը գնելու ամենաէժան միջոցն են։
Երկու կանաչ լույս համեմատություն չեն
Անվանատարածքը բաժանում է երթուղավորման աղյուսակները, միջերեսները և ցանցային կույտի վիճակը, ուստի մեկի ներսում սկսված հարցումը չի կարող լռելյայն վերցնել մյուսի թունելը։ Այն, ինչ չի բաժանում, պրոցեսորն է, ֆիզիկական վերին կապուղին կամ հոսթում աշխատող անունների լուծիչ ծառայությունը։ Հենց այդ վերջին ճեղքում են այս փորձարկումների մեծ մասը ձախողվում առանց որևէ մեկի նկատելու։ Հարցումը, որը դուրս է գալիս անվանատարածքից և հարցնում հոսթի լուծիչին, վերադարձնում է պատասխան, որը ոչ մի կապ չունի փորձարկվող թունելի հետ։
Այս ընթացակարգը ենթադրում է երկու արդեն պատրաստված և հաստատված փորձարկման անվանատարածք՝ աշխատող արտաքին կապով և աջակցվող հաճախորդներով։ Այն ոչինչ չի ստեղծում, ոչինչ չի գրանցում և ոչ մի կարգավորում չի փոխարինում։ Առանձին վիրտուալ մեքենաները մնում են ազնիվ ընտրություն, երբ հաճախորդին պետք է ամբողջական աշխատասեղանի նստաշրջան կամ նա հրաժարվում է աշխատել դրանից դուրս։
Ամրագրեք սպասումը մինչ առաջին գործարկումը
Յուրաքանչյուր համատեքստի համար որոշեք, թե ինչպիսի տեսք ունի հաջողությունը՝ լուծիչը, ծառայության անունը, սպասվող հասցեն և պահանջվող վարքը, երբ թունելը ընկնում է։ Պահեք այդ պլանավորված արժեքները իրենց սյունակում, որովհետև պլանը և դիտարկումը խառնող գրառումը ժամանակի դրոշմով հորինվածք է։ Ստորև բերված ստուգաթերթը այն ձևն է, որն անհրաժեշտ է գրառմանը, և յուրաքանչյուր տող պետք է լրացվելի լինի առաջին միացումից առաջ։
| Tunnel | Owner | Client interface inside the namespace | Proof command | Required on disconnect |
|---|---|---|---|---|
| vpn-a | the identity that owns profile A, recorded by name | its own tun device, never the host's | ip -n vpn-a -4 route get 10.55.10.20 | traffic stops; no host-side fallback |
| vpn-b | a separate owner, even when both run on one box | its own tun device in its own namespace | ip -n vpn-b -4 route get 10.55.20.20 | verified separately, never inferred from A |
Լուծիչի լարերը այդ գրառումում իրենց տողն են արժանի, որովհետև հենց այս դաշտն է ամենայն հավանականությամբ ստելու։ Անվանատարածքին կապված ֆայլերը, ինչպիսին է /etc/netns/vpn-a/resolv.conf հայտնվում են իրենց սովորական ուղիներում, երբ հրամանը գործարկվում է անվանատարածքի ներսում, ինչպես նկարագրում է iproute2-ի անվանատարածքների տեղեկատուն, սակայն անունների ծառայության փոխարկման կարգավորումը և դրա գործարկած ցանկացած տեղական լուծիչ դեռ կարող են հարցումը հետ քաշել դեպի հոսթ։
Մեկ թունել միաժամանակ, մյուսն անջատված
Միացրեք A-ն իր գոյություն ունեցող սեփականատիրոջ միջոցով, մինչ B-ն մնում է անջատված, ապա վարչական համատեքստից ստուգեք քաղաքականությունը, երթուղիները և ընտրված ուղին։ Ստորև բերված հրամաններից երեքը կարդում են վիճակ. միայն վերջինն է կապվում անունների ծառայության հետ, և դրանցից ոչ մեկը չի ուղարկում հավելվածի հարցում։
sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internalԵրթուղու որոնումը պատասխանում է նպատակակետի մասին հիպոթետիկ հարցի, ուստի այն չի կարող ցույց տալ, որ ծառայությունը ընդունում է երթևեկություն։ Պահեք ապացույցի այս երկու տեսակները առանձին սյունակներում, որովհետև մերժված միացման կողքին առողջ երթուղին իրական և սովորական արդյունք է։ Ապա ուղարկեք մեկ անվտանգ լիազորված հարցում իրական հավելվածով, որը գործարկվում է A-ի համատեքստում որպես նրա սովորական անարտոնյալ օգտատեր՝ անփոփոխ վկայագրի ստուգմամբ և հավելվածի նույնականացմամբ, և գրանցեք արդյունքը ծառայության տեսած սկզբնաղբյուրի հասցեի հետ միասին։ Անջատեք A-ն իր սեփականատիրոջ միջոցով և կրկնեք ամբողջ հիմնական գիծը B-ի համար՝ նշելով կատարած ցանկացած կարգավորման փոփոխություն, այլապես երկու հիմնական գծերն այլևս համեմատելի չեն լինի։
Երկուսն էլ վերևում, ապա մեկը՝ մեկ
Կայուն վիճակը հեշտ մասն է։ Երկու թունելները միացված վիճակում կրկնեք յուրաքանչյուր համատեքստի որոնումը և հավելվածի հարցումը, ապա կտրեք մեկ թունելը և ստուգեք մյուսը։ Վերամիացեք հակառակ հաջորդականությամբ, երբ միացման կարգն ինքն է հարցը։
sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20Գրավումը լուծում է վեճեր, որոնք հավելվածի արդյունքը չի կարող լուծել. այն ցույց է տալիս՝ հարցումը դուրս եկավ ձեր սպասած միջերեսով, թե բոլորովին այլ բանով։ Յուրաքանչյուր անցման համար գրանցեք սեփականատիրոջ գործողությունը, ժամանակի դրոշմը, երթուղու արդյունքը, անվան արդյունքը և հավելվածի արդյունքը։ Ապա ստուգեք անվտանգ փակման պահանջը տուժած անվանատարածքի ներսում, որովհետև մեկուսացումը անջատիչ չէ։ Անվանատարածքը երկու թունել առանձին է պահում. այն չի խանգարում դրանցից ոչ մեկին երթևեկություն կրել, երբ նրա պրոֆիլն ասում է, որ երթևեկությունը պետք է կանգնի։
Ինչ կարող է և ինչ չի կարող պնդել այս գրառումը
Հաջողությունն ապացուցում է այդ դիտարկումները այս դասավորության համար, այս հոսթում, այդ պահին։ Այն ոչինչ չի ասում մեկ աշխատասեղանի երթուղավորման աղյուսակը կիսող երկու հաճախորդի մասին, ոչ էլ թողունակության մասին, երբ երկու թունելներն էլ բեռ են կրում։ Դրանք առանձին հարցեր են առանձին փորձարկումներով, և համեմատությունը նույնքան լավն է, որքան յուրաքանչյուր տողին կցված համատեքստը։
Ձախողումները գրառման մեջ պահեք հաջողությունների կողքին՝ նշելով, թե որ թունելն էր այդ պահին միացված։ Մաքուր էջը, որը թաքցնում է չափման պահի վիճակը, ավելի վատն է, քան տգեղը, որը ցույց է տալիս այն։ Գրառումը հետագայում կրկին օգտագործելի է դարձնում համատեքստը, ոչ թե միավորը։
Մեկ մեքենայի վրա երկու թունել կարելի է ազնվորեն համեմատել, բայց միայն այնքան համատեքստերում, որքան իրականում վերահսկել եք։ Դրանից ավելին կանաչ պատկերակով ցանկություն է։