Ինչու է LAN-ի հոսթը ARP ուղարկում OpenVPN հաճախորդի հասցեին

LAN-ի հոսթի և VPN հաճախորդի միջև հասանելիության խնդիրները հաճախ վերադառնում են հենց հասցեների պլանին։ Տվեք այդ հոսթին ինտերֆեյս 10.0.100.0/22-ի վրա և այն 10.0.100.0-ից մինչև 10.0.103.255 բոլոր հասցեները կհամարի ուղղակիորեն միացված, ներառյալ 10.0.101.0/24-ում լուռ տեղադրված հաճախորդների լողավազանը։ Պատասխանը երբեք չի գնում երթուղիչ, որովհետև հոսթի տեսանկյունից ոչ մի երթուղիչ չի մասնակցում։ Փաթեթը հասցեագրված է հարևանին և պահանջվում է լարով։

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

Այն /22-ը, որը կուլ է տալիս /24-ը

Կարդացեք նախածանցը որպես միջակայք, ոչ որպես տող։ /22 նախածանցը պարունակում է 1024 հասցե, և 10.0.100.0/22-ը տարածվում է 10.0.100.0-ից մինչև 10.0.103.255, ուստի 10.0.101.0/24-ի լողավազանը ամբողջությամբ գտնվում է դրա ներսում։ Սխալը վերապրում է վերանայումը, որովհետև լողավազանի առաջին օկտետները տարբերվում են LAN-ի առաջին օկտետներից, և միայն երրորդ օկտետն է բացահայտում ներդնվածությունը։ Գրեք երկու միջակայքերն էլ թվերով, նախքան դրանք առանձին հայտարարելը։

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

Ուղիղ կապը նշանակում է ARP, ոչ երթուղավորում

Երբ /22 ինտերֆեյսով հոսթը ուղարկում է 10.0.101.25-ին, միջուկը համեմատում է նպատակակետը ինտերֆեյսի նախածանցի հետ և գտնում համընկնում։ Փաթեթը դառնում է հարևանի որոնում՝ երթուղավորված փաթեթի փոխարեն, իսկ Ethernet-ում հարևանի որոնումը այդ հասցեի ARP հարցումն է։ Եթե հասցեն պատկանում է երթուղավորված դարպասի հետևում գտնվող VPN հաճախորդին, LAN-ում ոչ մի հոսթ այն չի տիրապետում, ուստի հարցումը մնում է անպատասխան, և փաթեթները դեն են նետվում։ Թունելը մեղավոր չէ, և հաճախորդը երբեք չի տեսնում երթևեկությունը։

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

TUN, TAP և ինչ է կրում յուրաքանչյուրը

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

Գրանցեք, թե որտեղ է հայտնվել ARP հարցումը և որ համակարգն է ուղարկել այն, նախքան եզրակացություններ անելը։ Ուղարկողը ձեզ ասում է, թե ինչ է մտածում նպատակակետի մասին, ոչ թե ինչ է անում թունելը։

Նախագծեք լողավազան, որը չի կարող համընկնել

Ընտրեք լողավազան յուրաքանչյուր միացված նախածանցից և յուրաքանչյուր հայտարարված տեղամասի նախածանցից դուրս, ապա ավելացրեք երթուղիները, որոնք այն հասանելի են դարձնում երկու ուղղությամբ։ 10.8.0.0/24-ի նման միջակայքը պլանի չօգտագործված մասում հեշտ է մտածել, և LAN-ը, որին պետք է հասնել դրան, ստանում է ստատիկ երթուղի՝ ուղղված VPN սերվերին։ Փոխեք միասին բաշխումը, հայտարարված երթուղիները, թույլատրված աղբյուրի հասցեները և հրապատի կանոնները, որովհետև դրանք նկարագրում են մեկ նախագիծ, այլ ոչ թե չորս կարգավորում։

Սերվերի Source NAT-ը կարող է թաքցնել լողավազանը LAN-ից երթուղավորելի հասցեի հետևում, և դա օրինական միգրացիոն գործիք է։ Այն նաև վերագրում է աղբյուրը, ուստի LAN-ը կորցնում է կապերը առանձին հաճախորդներին վերագրելու և հաճախորդով պայմանավորված կանոններ կիրառելու ունակությունը։

Ընդունման համար օգտագործեք իրական հաճախորդի փաստացի տրված հասցեն և իրական հավելվածի հարցում LAN-ի հոսթից, ապա հաստատեք, որ պատասխանը հետևում է պլանավորված դարպասին, այլ ոչ թե լարին։