OpenVPN-ով LAN հասանելիությունը կոտրվա՞ծ է. Ստուգեք գոտիները, երթուղիները և վերադարձի ուղին

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

Որ զտիչն է տեսնում դեպի LAN ուղղվող փաթեթը

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

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

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

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

Ինչու է բաժանված թունելին պետք հրող նախածանցը

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

push "route 192.168.50.0 255.255.255.0"

Պրոֆիլները, որոնք պարունակում են route-nopull անտեսում են հրված երթուղիները, ուստի նույն նախածանցը պատկանում է հաճախորդի ֆայլին։ Ամեն դեպքում հաստատեք, որ գրառումը հասել է, այլ ոչ թե ենթադրեք դա, որովհետև լուռ փոխարինումը նույն տեսքն ունի, ինչ հրային պատի խնդիրը։

ip route show | grep 192.168.50

Կայք-կայք գործընկերը պահանջում է ավելին, քան հրումը։ Սերվերը պետք է սովորի, թե որ նախածանցներն են այդ գործընկերոջ հետևում, ինչն անում է նրա client-config-dir ֆայլի iroute տողը, և նրա սեփական աղյուսակին պետք է թունելի մեջ տանող համապատասխան երթուղի։

Պատասխանին պետք է հասցե, որին այն կարող է հասնել

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

tcpdump -ni tun0 host 192.168.50.20

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

Սանդուղք, որն ավարտվում է ճիշտ տեղում

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

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Անունները պատկանում են սանդուղքի վերջին, երբեք սկզբին։ Ընդհանուր պահոցը, որը պատասխանում է որպես 192.168.50.20, բայց ոչ որպես nas.local, մատնանշում է անվանումների լուծմանը կամ որոնման վերջածանցին, և հրային պատի փոփոխությունները չեն կարող փոխել դրանցից ոչ մեկը։

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