Ռոուտեր VPN հաճախորդի ռեժիմում՝ ինչու են անհետանում LAN սարքերը
LAN սարքերն անհետանում են այն բանից հետո, երբ ռոուտերը մտնում է VPN հաճախորդի ռեժիմ. նախ փորձարկեք փոխանցման ուղու ստուգման գործառույթը, ապա LAN տիրույթը, որը firmware-ը փոխել է ձեր տակ։
Այն համոզմունքը, թե հաճախորդի ռեժիմն ինքն է սպանում LAN հասանելիությունը, մարդկանց տանում է սխալ կարգավորումների ընտրացանկ, և իրական պատճառները սովորաբար երկուսն են։ Թունելը չի հեռացնում LAN կամուրջը և չի խանգարում լարային ու անլար հաճախորդներին հասնել միմյանց։ Տեղական հասանելիությունը կոտրում է կա՛մ ռոուտերի փոխանցման ուղու ստուգման գործառույթը, կա՛մ LAN հասցեների տիրույթը, որը տեղաշարժվել է, երբ firmware-ը դա արեց։ Երկուսն էլ առաջացնում են նույն բողոքը, և ոչ մեկը չի ուղղվում VPN պրոֆիլը վերատեղադրելով։
Առասպելը, և ինչ է իրականում փոխում հաճախորդի ռեժիմը
Հաճախորդի ռեժիմը ավելացնում է թունելի ինտերֆեյս և դրա միջով անցնող լռելյայն երթուղի, ապա փոխանցում է LAN երթևեկությունը այդ թունել։ Լարային պորտերի և անլար ռադիոյի միջև կամուրջը մնում է անձեռնմխելի, ինչպես նաև տեղական անջատումը։ Փոխվում է քաղաքականությունը. որ երթևեկությունն է փոխանցվում, որտեղ է թարգմանվում և որ լուծիչն են ստանում հաճախորդները։
Այս տարբերությունը կարևոր է, որովհետև կոտրված LAN-ը սովորաբար նշանակում է, որ այդ երեք քաղաքականություններից մեկը փոխվել է, ոչ թե ռոուտերը դադարել է անջատիչ լինելուց։ Ռոուտերը, որը դեռ պատասխանում է իր սեփական կառավարման էջին, ապացույց է, որ LAN ինտերֆեյսը կենդանի է։ Ռոուտերը, որն ընդհանրապես ոչնչի չի պատասխանում, այլ խնդիր ունի, օրինակ՝ փոխված LAN հասցե կամ սխալ ենթացանցում գտնվող հաճախորդ։
Այսպիսով, օգտակար առաջին քայլը պարզելն է, թե որ շերտն է կոտրվել, ոչ թե փոխել այն շերտը, որին կասկածում եք։
Փորձարկեք երեք նպատակ կարգավորմանը դիպչելուց առաջ
Լարային հաճախորդից առանձին փորձարկեք երեք նպատակ և գրեք յուրաքանչյուր արդյունքը. ռոուտերի սեփական LAN հասցեն, նույն անջատիչի մեկ այլ սարք՝ IP-ով, և մի բան, որին կարելի է հասնել միայն թունելով։ Արեք դրանք այդ հերթականությամբ, որովհետև յուրաքանչյուր արդյունք բացառում է այլ շերտ։ Առաջին փուլում օգտագործեք հասցեներ, ոչ անուններ, քանի որ անվան ձախողումը DNS-ը խառնում է կապի հարցին։
Պատասխանների օրինաչափությունը ախտորոշումն է։ Ռոուտերը, որը պատասխանում է, մինչ տեղական սարքերը՝ ոչ, ցույց է տալիս տեղական անջատման կամ զտման գործառույթի, ոչ թե երթուղավորման վրա։ Տեղական սարքերը, որոնք պատասխանում են, մինչ թունելի կողմը՝ ոչ, ցույց են տալիս թունելի երթուղու կամ հեռավոր firewall-ի վրա։ Եթե ամեն ինչ պատասխանում է հասցեով, իսկ անունները ձախողվում են, դա լուծիչի հարց է, և ոչ մի երթուղու խմբագրում այն չի ուղղի։
| What answers | What it points at |
|---|---|
| Router only | LAN-side filtering or a broken bridge |
| Router and local hosts, not remote | Tunnel route, NAT or remote firewall |
| Addresses yes, names no | DNS handed to clients by the router |
| Nothing at all | Client subnet or router LAN address changed |
Պահեք աղյուսակը թեստի արդյունքների կողքին։ Այն անորոշ բողոքը դարձնում է մեկ գործող տող։
Անվտանգության շերտը փոխանցման ուղու ներսում
Սպառողական ռոուտերները գնալով գալիս են ստուգման գործառույթով, որը հետևում է փոխանցվող երթևեկությանը, և այն աշխատում է նույն ուղում, որով փաթեթները LAN-ից գնում են թունել։ Երբ այդ ստուգումը չի կարողանում դասակարգել թունելի երթևեկությունը, փոխանցումը կարող է կանգնել, մինչ ինքը թունելը մնում է աշխատունակ և ռոուտերը հաղորդում է առողջ կապի մասին։ VPN մատյանում ոչինչ դա չի ցույց տալիս, որովհետև VPN-ը իրոք միացել է։
Ախտորոշումը վերահսկվող փորձ է, ոչ մշտական փոփոխություն։ Գրեք ընթացիկ կարգավորումը, անջատեք գործառույթը մեկ թեստի տևողությամբ, նորից բարձրացրեք թունելը և հասցեով փորձարկեք մեկ տեղական հոսթ։ Վերադարձող փոխանցումը ձեզ անհրաժեշտ ապացույցն է, և այդ ժամանակ փոխզիջումը դառնում է որոշում, ոչ թե ենթադրություն։ Եթե ոչինչ չփոխվի, անմիջապես նորից միացրեք այն և անցեք հասցեավորման պատճառին։
Վճարովի անվտանգության գործառույթը անջատված թողնելը, որպեսզի թունելը շարունակի աշխատել, փոխզիջում է, որը պետք է կատարել գիտակցաբար և գրել։ Արժե նաև հարցնել՝ արդյոք թունելը պետք է լինի այլ սարքում, որովհետև ամեն ինչ ստուգող ռոուտերը և ամեն ինչ փոխանցող ռոուտերը երկու տարբեր աշխատանք են։
Երկրորդ պատճառը. LAN տիրույթը տեղաշարժվել է
Firmware-ի թարմացումները պարբերաբար վերականգնում են LAN հասցեն արտադրողի լռելյայն արժեքին, և որոշ ռոուտերներ ունեն բացահայտ ռեժիմի անջատիչ, որը որոշում է՝ LAN-ը պահպանում է մասնավոր տիրույթ, թե ժառանգում է վերևի սարքից։ Հաճախորդը, որը սպասում է 192.168.8.x, կարող է հայտնվել 10.64.0.x-ի վրա, և այդ ժամանակ հոսթի հետ SSH նստաշրջանը ժամկետանց է դառնում, թեև թունելը լիովին առողջ է։
ipconfig /all
ip addr show
ip route get 192.168.8.20Կարդացեք նախածանցը և դարպասը վարձակալությունից նախքան ռոուտերի էջը բացելը։ Առաջին երկու հրամանները ցույց են տալիս, թե հաճախորդն իրականում ինչ է ստացել, իսկ երրորդը՝ թե տեղական հասցեի համար հաճախորդը որ ինտերֆեյսը կօգտագործի, և այդպես է մնացորդային երթուղին կամ հնացած ենթացանցը բացահայտում իրեն։ Այնուհետև համեմատեք դա LAN էջի և ռոուտերի ռեժիմի հետ։
Եթե տիրույթը չի կարող վերադառնալ, թարմացրեք յուրաքանչյուր օբյեկտ, որը նշում է այն. DHCP վերապահումներ, ցանկացած ստատիկ երթուղի դեպի հին ենթացանց և յուրաքանչյուր firewall կանոն, որը կրում է նախորդ նախածանցը։ Թունելի հեռավոր ենթացանցի հետ բախվող տիրույթը ավելի վատ տարբերակն է, որովհետև տեղական սարքերը մնում են հասանելի, մինչ հեռավոր նպատակները լուռ սխալ երթուղվում են դեպի LAN։
Կրկին միացեք և կրկին փորձարկեք փաթեթների հերթականությամբ
Փոփոխություններից որևէ մեկից հետո կրկին միացրեք թունելը և կրկնեք թեստերը փաթեթների հերթականությամբ. ռոուտեր, տեղական հոսթ, հեռավոր հոսթ, ապա անուններ, ապա հավելված։ Հավելվածն առաջինը փորձարկելը թաքցնում է, թե որ շերտն է դեռ կոտրված, և քեշավորված անվան դեմ զննարկիչի կրկնվող փորձը կարող է թվալ երթուղավորման ձախողում։
Գրեք firmware-ի տարբերակը, LAN նախածանցը և ստուգման գործառույթի վիճակը VPN պրոֆիլի կողքին։ Երեքն էլ կարգավորումներ են, որոնք հաջորդ թարմացումը կարող է վերագրել, և երկու տող նշումը խնայում է հենց նոր անցկացրած ժամը։