IPv6 քաղաքական երթուղավորում, երբ երկու uplink-ները կիսում են fe80::1-ը

Դուք ունեք երկու uplink, և ip -6 route show երկուսի վրա էլ տպում է նույն հաջորդ ցատկը՝ default via fe80::1 dev uplink0 և default via fe80::1 dev uplink1։ Սա կրկնակի հասցեի կոնֆլիկտ չէ, և մերկ հաջորդ ցատկը fe80::1 քաղաքականության աղյուսակ պատճենելը չի ասում միջուկին, թե որ հղումն եք նկատի ունեցել։ Իրական հարցը ախտանիշից ավելի նեղ է՝ արդյոք երկրորդ աղյուսակին պետք է մեկ հղում, թե երկուսը, և ինչն է այդ երթուղիները կենդանի պահում վերագործարկումից հետո։ Երեք պայման, հերթով ստուգված, լուծում են դրա մեծ մասը։

Նույն fe80::1-ը երկու տարբեր հարևաններ են

Հղումային-լոկալ հասցեները սահմանափակված են մեկ հղումով, ուստի fe80::1-ը երկու անգամ տպված մեկ հասցե չէ. դրանք երկու հարևաններ են, որոնք պատահաբար կիսում են վերջածանց։ Գոտու ինդեքսն այն ձևն է, որով հոսթը ասում է, թե որն է նկատի ունենում, ուստի fe80::1%uplink0-ը և fe80::1%uplink1-ը միջուկի համար տարբեր նպատակակետեր են, և այդ վերջածանցը երբեք չի հասնում հեռավոր երթուղիչին։ RFC 4007-ը նկարագրում է դրա հետևում գտնվող գոտու մոդելը, և դրա համար է, որ քաղաքականության աղյուսակը պետք է ամեն հղումային-լոկալ հաջորդ ցատկի հետ կրի սարք։

VPN կազմաձևման գեներատորը, որը թվային գոտու ID-ն պատճենում է մի հոսթից ձևանմուշ, տեղական համատեքստը վերաբերվում է որպես հասցեի մաս, և այն ֆայլը, որ գրում է, սխալ է յուրաքանչյուր այն մեքենայում, որի ինտերֆեյսի անունները կամ ինդեքսները տարբերվում են։ Քաղաքականության աղյուսակը նույնպես երկու հղում չի միավորում մեկի մեջ. երթուղավորված VPN-ը փաթեթներ է փոխանցում ցանցերի միջև, բայց չի տեղափոխում հեռավոր Ethernet հարևանի հղումային-լոկալ ինքնությունը թունելով, ուստի հղումային-լոկալ տրաֆիկը մնում է իր հղումում։

Հեռացրեք սարքը, և երթուղին դառնում է անգրելի։ ip -6 route add default via fe80::1 table 200-ը չի կարող լուծել դարպասը, և iproute2-ը մերժում է այն Error: Nexthop has invalid gateway.-ով. դրանով իսկ dev uplink0-ը ավելացնելը հաջողեցնում է հրամանը, քանի որ սարքն է, որ հաջորդ ցատկը ամրացնում է այդ երկու հարևաններից մեկին։ Այն, ինչ սարքը չի կարող ասել, այն է՝ արդյոք uplink0-ը ճիշտ հղումն է այս աղյուսակի համար, և մեկ այլ հոսթից պատճենված երթուղին բերում է այդ հոսթի ինտերֆեյսի անունները, և հենց այստեղից են գալիս իրական սխալները։

Պայման առաջին՝ աղյուսակում մեկ հղում, թե երկու

Սկսեք նրանից, թե ինչի համար է երկրորդ uplink-ը։ Եթե երկու հղումներն էլ կրում են նույն տրաֆիկը, և մեկը պահեստային է, փոխարինող աղյուսակը պետք է պարունակի երկու դարպասներն էլ տարբեր մետրիկաներով՝ նույն նպատակակետերը, մեկ նախընտրելի ուղի, մեկ ակնհայտ երկրորդ ընտրություն։ Եթե uplink-ները կան, որովհետև տարբեր տրաֆիկ պետք է դուրս գա տարբեր մատակարարների միջով, կամ որովհետև սա բաժանված թունել է, որտեղ որոշ տրաֆիկ շրջանցում է VPN-ը, իսկ մնացածը մնում է ներսում, ապա երկու հղումները բոլորովին չեն պատկանում մեկ աղյուսակի։ Դրանք պատկանում են երկու աղյուսակների, որոնք ընտրում է կանոնը, և կանոնն ընտրում է աղյուսակը, ոչ թե թունելը՝ շրջանցող տրաֆիկը նշվում է երթուղավորումից առաջ, և հենց նշանն է այն ուղարկում երկրորդ աղյուսակ։

Այդ երկրորդ դեպքում կանոնը որոշում է, թե երբ դիմեն աղյուսակին, իսկ երթուղին որոշում է, թե ուր է գնում փաթեթն այդ պահին՝

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

Օբյեկտներից ոչ մեկը չի փոխարինում մյուսին, և միայն լռելյայն պարունակող աղյուսակը դեռ կարող է չկարողանալ լուծել իր դարպասը։ Եթե ավելացումը մերժվում է, կամ երթուղին կա, բայց անօգտագործելի է, տվյալ ինտերֆեյսի միացված նախածանցը դրեք նույն աղյուսակում, կամ նշեք ցատկը որպես onlink, երբ այդ նախածանցը երթուղավորվում է այլ տեղ։ Վերևի բլոկում 2001:db8:100::/48-ը ներկայացնում է uplink1-ի այդ միացված նախածանցը, ոչ թե կամայական նպատակակետ։ fwmark կանոնը սպառում է միայն այն նշանը, որը պետք է դնի մեկ ուրիշը՝ փոխանցման ուղու nftables կամ iptables կանոնից կամ սոքեթի SO_MARK-ից, ուստի առանց նշանի աղբյուրի պատճենված բլոկը ոչ մի բանի չի համապատասխանում։

Պայման երկրորդ՝ մետրիկաները չեն հայտնաբերում մեռած մատակարարին

Մետրիկան նախապատվություն է գոյություն ունեցող երթուղիների միջև, ոչ թե առողջության ստուգում։ Երբ կրիչն ընկնում է, միջուկը հեռացնում է այդ սարքի երթուղիները, և երկրորդ լռելյայնը ստանձնում է։ Երբ մալուխը մնում է վերևում, իսկ դրա հետևի մատակարարը մեռնում է, աղյուսակում ոչինչ չի փոխվում՝ նախընտրելի երթուղին տեղադրված է, հարևանը հասանելի է շերտ 2-ում, և փաթեթները մեկնում են սև անցքի մեջ։ Եթե այդ տարբերությունը կարևոր է ձեր տեղադրման համար, ապա վերափոխումը պետք է գա մի բանից, որը ստուգում է ուղին և հեռացնում երթուղին՝ լինի դա երթուղավորման դեմոն, թե փոքր սկրիպտ, որը ջնջում և նորից տեղադրում է գրառումը։

Ստուգեք ընտրությունը աղյուսակը կառուցելուց հետո, և ստուգեք այնպես, ինչպես միջուկը կտեսնի այն։ ip -6 route get 2001:db8:100::1-ը տպում է այն երթուղին, որը կօգտագործվի՝ ներառյալ սարքը և ընտրված աղբյուրի հասցեն, և այն հարգում է քաղաքականության կանոնները։ Սխալ uplink-ին պատկանող աղբյուրի հասցեն սովորական նշան է, որ կանոնը համապատասխանել է ավելի վաղ, քան սպասում էիք։

Պայման երրորդ՝ որոշեք, թե ով է տիրում կայունությանը

Երթուղին, որն ավելացվել է ip -6 route add-ով, գոյատևում է մինչև վերագործարկում կամ մինչև ինչ-որ բան այն դատարկի։ Երթուղիչի հայտարարություններից սովորած լռելյայնը կրում է կյանքի տևողություն և կարող է հետ կանչվել երթուղիչի կողմից, մինչդեռ ձեռքով ավելացված լռելյայնը երբեք ինքն իրեն չի ժամկետանցվում։ Երկուսը մեկ աղյուսակում խառնելը հենց այն է, թե ինչպես է հնացած մշտական երթուղին հայտնվում թարմ հայտարարվածից վեր, այն uplink-ից շատ ավելի ուշ, որը նա նկարագրում էր, դադարել է գոյություն ունենալուց։

Յուրաքանչյուր աղյուսակի համար ընտրեք մեկ տեր։ Եթե ցանցի կառավարիչը կամ երթուղավորման դեմոնն արդեն կառավարում է ինտերֆեյսը, նկարագրեք քաղաքականության երթուղին այնտեղ և թողեք միջուկին։ Եթե դուք այն սկրիպտ եք անում, սկրիպտը դարձրեք իդեմպոտենտ և միաժամանակ գրեք քանդումը, որովհետև այն ձեզ պետք կգա առաջին վատ փոփոխության ժամանակ՝

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

Այն երթուղիչում, որը փոխանցում է այլ հոսթերի համար, նախքան աղյուսակին մեղադրելը ստուգեք net.ipv6.conf.all.forwarding-ը։ Փոխանցումը անջատված լինելու դեպքում այլ ցանցին ուղղված փաթեթները դեն են նետվում՝ անկախ նրանից, թե որքան ճիշտ է աղյուսակ 201-ը։

Գրանցեք դիզայնը, որպեսզի հաջորդը կարողանա աուդիտ անել այն

Միայն fe80::1-ը պահող գույքագրումը դեն է նետում կարևոր դաշտերը։ Միասին գրանցեք նպատակակետը, հաջորդ ցատկը, սարքը, աղյուսակը և մետրիկան, ինչպես նաև՝ որտեղից է եկել յուրաքանչյուր երթուղին՝ հայտարարված, կառավարչի կողմից ստեղծված թե ստատիկ։ Երբ ավելի ուշ ինչ-որ մեկը հարցնի՝ արդյոք երկրորդ uplink-ը իրականում տրաֆիկ է տանում, այդ գրառումը պատասխանում է առանց գուշակության։

Նախքան աղյուսակը ավարտված հայտարարելը, հաստատեք հարևանին ip -6 neigh show dev uplink0-ով, նորից կարդացեք ip -6 rule show-ը՝ հերթականության պատահարների համար, և փորձարկեք կանոնին համապատասխանող տրաֆիկով, այլ ոչ լռելյայն երթուղին վերցնող ping-ով։ Այնուհետև դիտավորյալ իջեցրեք մեկ uplink և հետևեք, թե որ երթուղուն է միջուկը վերադառնում. պատասխանը պետք է համապատասխանի ձեր գրածին։