LAN երթուղիչ և VPN հաճախորդ՝ երկու սարք, երկու երթուղային աղյուսակ

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

Գծեք երկու ցատկերը նախքան երթուղուն դիպչելը

Վերցրեք օրինակելի դասավորություն. LAN հոսթեր 192.168.50.0/24-ում, սովորական երթուղիչը՝ 192.168.50.1-ում, առանձնացված հաճախորդ՝ 192.168.50.15-ում, և հեռավոր LAN 10.60.0.0/24-ում, որը հասանելի է միայն այն թունելով, որն ունի այդ հաճախորդը։ Երկու մասնավոր տիրույթներից ոչ մեկը չի համընկնում մյուսի հետ, և թունելն ունի իր սեփական հասցեային պլանը։

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

Քայլ 1. ուղղեք երթուղիչը դեպի հաճախորդ, ոչ թե դեպի թունել

LAN երթուղիչի վրա ավելացրեք նպատակակետ երթուղի, որի հաջորդ ցատկը հաճախորդի LAN հասցեն է.

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Այդ գրառումն ասում է՝ «հասցրու այն մեքենային, որը կարող է թունել կառուցել»։ Այն ոչինչ չի ասում այն մասին, թե ինչպես է կառուցվում թունելը, և չի փոխարինում հաճախորդի սեփական երթուղուն։ Կառավարվող երթուղիչում համարժեքը ապրում է սարքի ստատիկ երթուղիների էջում. Linux երթուղիչում այն պատկանում է LAN-ին տիրող ինտերֆեյսի կարգավորմանը, ոչ թե shell-ին, որը դուք կփակեք։

Ստուգեք երկրորդ հրամանի պատասխանը։ Եթե այն հաճախորդին նշում է որպես gateway, իսկ LAN ինտերֆեյսը՝ որպես device, ապա առաջին ցատկը ճիշտ է, և մնացած աշխատանքը մյուս մեքենայի վրա է։

Քայլ 2. տվեք հաճախորդին իր սեփական երթուղին թունելի կողմում

Հաճախորդն այժմ ստանում է փաթեթ 10.60.0.0/24-ի համար և նայում է իր աղյուսակին։ Եթե նրա թունելի կարգավորումը տեղադրել է երթուղի այդ նախածանցի համար, փաթեթը շարունակում է գաղտնագրված։ Եթե ոչ, փաթեթը համապատասխանում է սովորական լռելյայնին և վերադառնում է 192.168.50.1, որը նորից ուղարկում է այն հաճախորդին։

Նայեք նախքան որևէ բան ավելացնելը.

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

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

Օղակը, երբ լինում է, գործնականում անվերջ չէ. TTL-ը նվազում է յուրաքանչյուր անցումում, և փաթեթը մահանում է ժամանակի գերազանցման հաղորդագրությամբ։ Դրա համար կրկնվող traceroute-ը կարող է ցիկլի ակնարկ տալ, մինչդեռ հաճախորդը, որը պարզապես չի փոխանցում, նույն փաթեթը լուռ գցում է։

Քայլ 3. թույլատրեք փոխանցումը և ընտրեք վերադարձի ուղին

Ստանալը և փոխանցելը տարբեր թույլտվություններ են։ net.ipv4.ip_forward=1-ը հաճախորդի վրա թույլատրում է տրանզիտ միջուկի մակարդակում, և firewall-ի կանոնը դեռ պետք է թույլատրի այն LAN ինտերֆեյսի և թունելի միջև։ Կանոնը, որը թույլատրում է հասանելիություն հաճախորդի սեփական կառավարման էջին, չի թույլատրի տրանզիտ դեպի հեռավոր LAN, և այդ տարբերությունը հեշտ է բաց թողնել, երբ նույն հոսթը տեղում պատասխանում է ping-երին։

Հեռավոր կողմն ունի հայելային խնդիրը։ Նա պետք է իմանա, որ 192.168.50.0/24-ը հասանելի է այս նույնականացված հաճախորդի միջոցով։ OpenVPN օգտագործելիս դա սովորաբար նշանակում է սերվերի կարգավորման կողմից մղվող յուրաքանչյուր հաճախորդի երթուղի, կամ սերվերի վրա հաճախորդին հատուկ ֆայլ, որը հայտարարում է հաճախորդի հետևում գտնվող LAN-ը։ Առանց դրա հեռավոր LAN-ը կամ գցում է պատասխանը, կամ ուղարկում այն իր լռելյայն դարպասին, այսինքն՝ ինտերնետ։

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

Քայլ 4. երկու որոշումներն էլ դարձրեք մշտական, ապա փորձարկեք իրական ուղին

Յուրաքանչյուր երթուղի ունի տեր, և տերը այն կարգավորումն է, որը վերստեղծվում է բեռնման կամ վերամիացման ժամանակ։ Երթուղիչում դա կարող է լինել ստատիկ երթուղու գրառում. հաճախորդում այն կարող է լինել VPN պրոֆիլը, NetworkManager-ը կամ systemd-networkd-ը։ Ստուգեք թունելը նորից միացնելով և հաճախորդը վերագործարկելով, ապա նորից կարդացեք աղյուսակը՝ փոփոխությանը վստահելու փոխարեն։

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

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