Պատասխանը դուրս է գալիս LAN-ով, ոչ թունելով․ ինչու և ինչպես

Դարպասով հրապարակված ծառայությունը աշխատում է ինտերնետի մեծ մասից և ձախողվում է մեկ գրասենյակից։ Ինչ-որ մեկը ստուգում է թունելը, տեսնում է հարցման ժամանումը և եզրակացնում, որ պատասխանը պետք է վերադառնա նույն ճանապարհով։ Linux-ը այդպես չի աշխատում, և թունելի որևէ ստուգում չի փոխի պատասխանը։ Պատասխանը երթուղվում է ըստ նպատակակետի, և այդ միակ ձախողվող զանգահարողը գտնվում է ենթացանցում, որին հոսթն արդեն հասնում է ուղղակիորեն։

Ինչն է իրականում որոշում ելքային փաթեթը

Միջուկը երթուղի է փնտրում փաթեթի նպատակակետի համար՝ դիտարկելով քաղաքականության կանոնները ըստ առաջնահերթության, ապա այն աղյուսակը, որն ընտրում է համապատասխան կանոնը։ Այն միջերեսը, որով փաթեթը ժամանել է, որևէ դեր չի խաղում, եթե կանոն կամ նշում չի գրվել դա կարևոր դարձնելու համար։ Սա այս հոսթի երթուղավորման փաստ է, ոչ թե թունելի խափանում։

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

Ինչու է հաղթում տեղական ենթացանցը

Տեղական ցանցում հասցե ունեցող հոսթը հիմնական աղյուսակում ունի միացված երթուղի այդ նախածանցի համար, իսկ միացված երթուղին ուղղակի համընկնում է։ Երբ զանգահարողը գալիս է նույն ենթացանցից, որոնումը գտնում է տեղական կապը նախքան թունելը ընդհանրապես դիտարկելը։

Հենց անհամաչափությունն է ախտորոշումը շփոթեցնող դարձնում։ Ավելի լայն ինտերնետից զանգահարողներն աշխատում են, որովհետև չեն համապատասխանում ոչ մի տեղական երթուղու, մինչդեռ գրասենյակի նախածանցը կիսող միակ զանգահարողը ձախողվում է, և հենց այդ զանգահարողով է ինչ-որ մեկը փորձարկում։

Հավասարակիցների ընդգրկումը նույնը չէ, ինչ տեղադրված երթուղիները

Թունելի կողմում հավասարակիցի թույլատրված միջակայքերը նկարագրում են, թե ինչ կարելի է ուղարկել թունել, և թե որ աղբյուրներն են ընդունվում դրանից։ Դրանք ոչինչ չեն ասում այն մասին, թե ուր տեղական երթուղային աղյուսակը կուղարկի փաթեթը։

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

Ընտրեք աղյուսակը ըստ աղբյուրի հասցեի

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

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

Վերջին տողը բացակայող երթուղին դարձնում է տեսանելիորեն ձախողվող՝ տեղական կապին հետ ընկնելու փոխարեն։ Աղբյուրը պետք է իսկապես վերագրված լինի հոսթին, և սովորական տեղական ու հիմնական որոնումները պետք է մնան իրենց նախկին դիրքերում։ Կանոնը աղյուսակ է ընտրում ըստ աղբյուրի․ այն չի համեմատում նախածանցների երկարությունները աղյուսակների միջև։

Հաստատեք ուղին, ապա ծառայությունը

Հարցրեք միջուկին, թե ինչ կաներ՝ որպես աղբյուր ընտրիչ օգտագործելով ծառայության հասցեն, փոխանակ որսից եզրակացնելու։ Այստեղ սխալ պատասխանը խնայում է ամբողջ փաթեթային հետքը։

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

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

Ինչը սա չի շտկում

Թողեք փոխանցումը, հրապատի կանոնները և ICMPv6-ի վարքը դարպասում այնպես, ինչպես եղել են, որովհետև աղբյուրի երթուղին դրանցից ոչ մեկին չի փոխարինում։ Բացակայող Packet Too Big հաղորդագրությունը դեռ կոտրում է մեծ պատասխանները՝ անկախ նրանից, թե որ աղյուսակը հաղթեց որոնմանը։ Ուղղեք դա նախքան երթուղային կանոններ ավելացնելը, այլապես ախտանիշը կմնա նաև փոփոխությունից հետո։

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

Վերջապես, գրեք կանոնների համարները և աղյուսակը հոսթի կոնֆիգուրացիայի կառավարման մեջ։ Ձեռքով ավելացված քաղաքականության կանոնը անհետանում է հաջորդ վերակառուցման ժամանակ, և գրասենյակի զանգահարողը վերադառնում է նույն բողոքով։