MULTI: սխալ աղբյուրի հասցե հաճախորդից. ում հասցեն էր դա։
Ներքին աղբյուրը չի համապատասխանում այն հաճախորդին, որը փոխանցել է այն։ Համապատասխանեցրեք այն թունելի հատկացմանը, հաճախորդի հետևի LAN-ին կամ կրկնվող ինքնությանը։
Սերվերի մատյանը տպում է MULTI: bad source address from client, գցում փաթեթը, և սեսիան մնում է միացված։ Այդ համադրությունը շփոթեցնում է նրանց, ովքեր հաղորդագրությունը կարդում են որպես նույնականացման ձախողում։ Այդպես չէ. հաճախորդը նույնականացել է, և ժամանած փաթեթը կրում էր ներքին աղբյուրի հասցե, որը սերվերը չկարողացավ կապել այդ հաճախորդի օրինակի հետ։ Ստուգումը կատարվում է մատակարարումից առաջ, դրա համար թունելը առողջ է երևում, մինչդեռ դրա միջով ոչ մի օգտակար բան չի անցնում։
Ինչ է սերվերը համեմատում մատակարարումից առաջ
Հաճախորդից եկող յուրաքանչյուր փաթեթի համար օգտվողի տարածության սերվերը նայում է թունելի ներսի աղբյուրի հասցեին և հարցնում իր ներքին երթուղավորման վիճակին, թե որ հաճախորդին է պատկանում այդ հասցեն։ Եթե սեփականատերը այլ օրինակ է, կամ սեփականատեր ընդհանրապես չկա, փաթեթը հեռացվում է և ահազանգը թողարկվում է։
Թունելի ինտերֆեյսով սովորական մատակարարում երբեք տեղի չի ունենում։
Այդ հերթականությունը բացատրում է մի մանրամասն, որը զարմացնում է մարդկանց. հոսթի հրակայուն պատի հաշվիչները չեն շարժվում, որովհետև փաթեթը երբեք չի հասել հրակայուն պատին։ Հոսթի վրա հակադարձ ուղու զտման կարգավորումը այստեղ ոչինչ չի փոխում, քանի որ մերժումը տեղի է ունեցել դեմոնի սեփական կապակցման ստուգման մեջ։ Կարդացեք հաղորդագրությունը որպես հայտարարություն սեփականության մասին, ապա պարզեք, թե երեք իրավիճակներից որն է այն առաջացրել։
Չհամապատասխանող ներքին հասցեի երեք աղբյուր
Հաճախորդը կարող է ուղարկել այնպիսի հասցեից, որը նրան չի հատկացվել, այնպիսի ցանցից, որը ոչ ոք չի հայտարարել իրենը, կամ այնպիսի ինքնության կրկնօրինակից, որն արդեն սեփականատեր ունի։ Երեքն էլ առաջացնում են նույն մատյանի տողը։ Նրանք տարբերվում են նրանով, թե ինչ պետք է փոխեք։ Սկսեք հասցեից և ընթացիկ հատկացումների ցանկից, և թող այդ երկու փաստերն ընտրեն դեպքը։
Նրանց տարբերելու համար պետք է երկու փաստ. մատյանի մերժված հասցեն և այն հատկացումները, որոնք սերվերը համարում է ընթացիկ։ Երկրորդը հասանելի է աշխատող օրինակի կարգավիճակի կամ կառավարման տեսքից, և դա միակ հեղինակությունն է, որի հետ արժե խորհրդակցել, քանի որ կարգավորման ֆայլը գրանցում է մտադրություններ, այլ ոչ ընթացիկ վիճակը։
Գրանցեք երկուսն էլ նախքան ինչ-որ բան փոխելը, ապա դասակարգեք։ Ավելի ուշ արված էկրանի պատկերը այն վիճակի գրառումը չէ, որն առաջացրել է ահազանգը։ Պահպանեք նաև ժամանակի դրոշմը, քանի որ հատկացումները տեղաշարժվում են սեսիաների միջև։
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
Հաճախորդի հետևի LAN-ը և iroute-ը
Երբ կայքի հաճախորդը երթուղավորում է իր սեփական մասնավոր ցանցը, այդ ցանցը պետք է հայտարարվի որպես հաճախորդին պատկանող։ iroute գրառումով հաճախորդին հատուկ ֆայլը դա անում է, և գրառումը նշում է այն նախածանցը, որը հաճախորդին թույլատրվում է տանել։
Նույն նախածանցը դեպի թունել ուղղող միջուկի երթուղին առանձին պահանջ է, և դրա ավելացումը ոչինչ չի փոխում դեմոնի ներքին սեփականության մեջ։
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Հաստատեք, որ արդյունավետ ինքնությունը համապատասխանում է ֆայլի անվանը, քանի որ անհամապատասխանությունը նշանակում է, որ ֆայլը երբեք չի բեռնվում, և ախտանիշը նույնական է բացակայող գրառմանը։ Մի ավելացրեք լայն iroute ահազանգը լռեցնելու համար, որովհետև դա անսպասելի աղբյուրը դարձնում է լիազորված՝ չպատասխանելով, թե ինչու հաճախորդն ուղարկեց այն։ OpenVPN 2.6-ի ձեռնարկը փաստաթղթավորում է iroute-ը, duplicate-cn-ը և ինքնության քարտեզագրումը որպես առանձին վերահսկիչներ։
Նույն ինքնությունը երկու մեքենայի վրա
Երկրորդ նոթբուքին պատճենված պրոֆիլը կրում է նույն վկայագիրը և նույն ընդհանուր անունը։ Կախված սերվերի կարգավորումներից՝ ավելի նոր միացումը կարող է փոխարինել հինին, և կապակցման ստուգումը հաղթում է այն օրինակը, որն ունի սեփականությունը։
Դա անսարքությունը դարձնում է ընդհատվող և այն հայտնվում է միայն այն ժամանակ, երբ երկու սարքերն էլ արթուն են։
Կրկնվող ընդհանուր անունների թույլտվությունը թույլ է տալիս երկուսին միանալ, բայց չի տալիս նրանց անկախ ստատիկ հասցեներ կամ անկախ սեփականություն։ Եթե երկու սարք պետք է գոյակցեն, գրանցեք նրանց առանձին, որպեսզի յուրաքանչյուրն ունենա իր ինքնությունը և իր հատկացումը։ Կրկնօրինակի կարգավորումը որպես այս ահազանգի վերանորոգում դիտարկելը թողնում է առեղծվածը տեղում և ավելացնում երկրորդը։
Ապացուցեք, որ կապակցումը փոխվել է
Կիրառեք ուղղումը կարգավորման սեփականատիրոջ միջոցով, ապա նորից միացրեք տուժած հաճախորդին, որպեսզի նոր քաղաքականությունը բեռնվի։
Կրկնեք նույն հոսքը և հաստատեք երեք բան. փաթեթի ներքին աղբյուրը, հաճախորդի այն օրինակը, որի հետ սերվերը կապում է այն, և նպատակակետի վարքագիծը դրանից հետո։
Եթե ահազանգը դադարում է, բայց հավելվածը դեռ ձախողվում է, խնդիրը տեղափոխվել է, այլ ոչ անհետացել։ Փոխանցումը, հրակայուն պատի կանոնները և վերադարձի ուղին առանձին փուլեր են, և կապակցման ստուգումն անցնելը միայն նշանակում է, որ փաթեթին թույլատրվել է լքել թունելը։