LAN հասցե ունեցող VPN հաճախորդը LAN-ում չէ

Հաճախորդը միանում է, ստանում է 10.50.0.200 և չի կարողանում հասնել 10.50.0.20-ի սերվերին, թեև երկու համարներն էլ նույն /24-ում են։ Այս կազմաձևի հետևում այն համոզմունքն է, որ LAN նախածանցից վերցված հասցեն հաճախորդին դարձնում է LAN-ի մաս։ Այդպես չէ։ Հաճախորդը կետ-կետ կապուղու վրա է, սերվերը նպատակակետը համարում է տեղական, և բացակայող մասը հարևանի պատասխանն է, որը ոչ ոք չի ուղարկում։

Առասպելը. նույն նախածանցը նշանակում է նույն սեգմենտ

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

Երբ սերվերը ուղարկում է 10.50.0.200-ին, այն համեմատում է նպատակակետը իր դիմակի հետ, որոշում է, որ հասցեն on-link է, և տեղական սեգմենտից հարցնում է այն սարքային հասցեն, որը պատկանում է դրան։ Այդ հարցումը դուրս է գալիս Ethernet ինտերֆեյսով, և VPN հաճախորդը այնտեղ չէ, որ լսի։

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

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

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

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

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

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

Ինչպես է proxy ARP-ն ապահովում հաջորդ թռիչքը

proxy ARP-ը ստիպում է դարպասին պատասխանել կապուղու մակարդակի հարցմանը մի նպատակակետի փոխարեն, որին այն կարող է հասնել մեկ այլ ինտերֆեյսով։ LAN հոսթը ստանում է սարքային հասցե, ուղարկում է շրջանակը դարպասին, և դարպասը փոխանցում է փաթեթը VPN նստաշրջան։ Հոսթի տեսանկյունից հաճախորդը պարզապես երևում է դարպասի հետևում։ Հաճախորդի կազմաձևում ոչինչ չի փոխվում։

MikroTik-ի RouterOS ARP փաստաթղթերը նկարագրում են այդ օգտագործումը հավաքող հաճախորդների համար, որոնք փոխառում են միացված LAN-ի հասցեային տարածությունը։ Մեխանիզմը հարևանների լուծման վերանորոգում է, և այն աշխատում է, որովհետև դարպասը իսկապես գտնվում է երկու ուղիներում։

Սա նույնը չէ, ինչ հաճախորդին LAN-ի մեջ կամրջելը։ Դարպասը դեռ պետք է փաթեթը փոխանցի ճիշտ ակտիվ նստաշրջան, և նրա երթուղումը և հրապաշարի քաղաքականությունը դեռ պետք է թույլատրեն ծառայությունը։ proxy ARP-ը փոխում է, թե ով է պատասխանում հարևանի հարցմանը, ոչ թե ով իրավունք ունի խոսելու։

Ուշադիր կարդացեք հարթակի ռեժիմների անունները։ RouterOS-ը տարբերում է proxy-arp-ը local-proxy-arp-ից, և երկրորդը զբաղվում է նույն ինտերֆեյսով ներս մտնող և դուրս եկող երթևեկությամբ։ Դրանք փոխարինելի ուղղագրություններ չեն, և երկուսն էլ առանց տարբերակման միացնելը կարճ ճանապարհ չէ։

Ինչ չի տալիս ձեզ proxy ARP-ը

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

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

Եվ այն չի վերացնում LAN-ի սեփականատիրոջ հետ համաձայնեցման անհրաժեշտությունը։ proxy ARP գրառումը, որը զարմացնում է հասցեային պլանի սեփականատիրոջը, աջակցության միջադեպ է, որը սպասում է հանգիստ շաբաթվա։

Համեմատություն առանձին երթուղվող լողավազանի հետ

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

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

Ընտրեք մոդելների միջև դիտավորյալ, ոչ պատահաբար։ proxy ARP-ը վերանորոգում է մեկ կոնկրետ հարաբերություն. երթուղվող լողավազանը խուսափում է այդ վերանորոգման անհրաժեշտությունից։ Գրեք, թե որն եք ընտրել և ինչու, և հաջորդ մարդը ստիպված չի լինի նորից հայտնաբերել այն ձախողված հարևանի գրառումից։