Երթուղիչի VPN-ն աշխատում է, բայց LAN-ի հաճախորդները ինտերնետ չունեն

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

Կարդացեք ձախողումը LAN-ի հոսթից

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

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

Տեղական և փոխանցված երթևեկությունը տարբեր են

Լինուքսը և երթուղիչների միկրոծրագրերի մեծ մասը տուփի կողմից ստեղծված փաթեթներին վերաբերվում են այլ կերպ, քան դրա միջով անցնող փաթեթներին։ output շղթան տեսնում է առաջին տեսակը, forward շղթան՝ երկրորդը, և երթուղիչի սեփական երթևեկության համար կարգավորված քաղաքականությունը կարող է փոխանցումը թողնել անձեռնմխելի։

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Ստուգեք՝ արդյոք փոխանցումն ընդհանրապես միացած է, ապա կարդացեք forward շղթան, ոչ թե output շղթան։ Թույլատրված կոդավորված արտաքին միացման կանոնը չէ այն կանոնը, որը թույլատրում է վերծանված փաթեթների փոխանցումը, և երկուսը շփոթելը հենց այս ախտանիշն է առաջացնում։ Թունելի միացած լինելը ապացուցում է միայն առաջինը։

Վերադարձի ուղին նույնպես պետք է գոյություն ունենա

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

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

Հաճախորդի DNS-ը նույն վերանայման մաս է։ Երթուղիչի լուծիչը կարող է պատասխանել, մինչդեռ այլ սերվերի ուղղված հաճախորդը ընդհանրապես ոչինչ չի ստանում։

Ստուգեք մեկ թույլատրված և մեկ մերժված հոսք

Ուղղումից հետո փորձարկեք նոր միացում հաճախորդից, ոչ թե երթուղիչի գոյություն ունեցող նստաշրջանը։ Ապա համոզվեք, որ այն հատվածը, որը չպետք է օգտագործի թունելը, դեռ չի օգտագործում այն։

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

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