Ինչու է IPv6 հարևանների հայտնաբերումը ձախողվում ուղղորդված VPN-ի միջով

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

Շրջանակը նախորդում է կարգավորմանը

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

Կապին հատուկ հասցեն, օրինակ fe80:: գրառումը, նույնպես գոտիով սահմանափակ է, և նույն տեքստը կարող է մատնանշել այլ հոսթ այլ կապի վրա։ Դրանցից մեկը թունելի մյուս կողմից փորձարկելը ոչինչ չի ապացուցում, բացի այն, որ հասցեն երկիմաստ է։

Թակարդը կապի վրա լինելու ենթադրությունն է

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

Մեկ ծառայության համար /128-ը ամենաքիչ զարմանալի լուծումն է, և այն ամբողջությամբ վերացնում է երկիմաստությունը։ Հարևանների հայտնաբերման սպեցիֆիկացիան նկարագրում է հաղորդագրությունների հավաքածուն և կապի վրա-է դրոշը, որն այդ որոշումն է կայացնում։

Կամրջումը դիտավորյալ փոխում է կանոնները

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

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

Փորձարկեք այն հասցեով, որն օգտագործում է հավելվածը

Հաստատեք երթուղին ip -6 route get-ով, ստուգեք հարևանի գրառումը ip -6 neigh-ով, ապա հաստատեք ծառայությունը ուղղորդված ուղով։ DNS-ը և վերադարձի ուղին առանձին ստուգումներ են, և առողջ հարևանային գրառումը չի ապացուցում դրանցից ոչ մեկը։

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

Գրեք, թե որ ձևավորումն ունեք

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

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