Ինչու VPN փոփոխությունից հետո երթուղիչի կառավարման էջը դադարում է պատասխանել

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

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

Թունելը երբեք կառավարման ուղի չի եղել

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

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

Առաջին շերտ՝ կա՞ ուղի դեպի երթուղիչի սեփական հասցեն։

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

Թունելի կողմն ունի հարցի իր տարբերակը։ WireGuard-ը AllowedIPs-ը դիտարկում է որպես գաղտնագրման բանալու երթուղային աղյուսակ՝ յուրաքանչյուր ծայրում այն հայտարարում է, թե զուգընկերը որ աղբյուրի հասցեներ կարող է օգտագործել և որ նպատակակետերն են ուղարկվում այդ զուգընկերոջը։ Եթե հաճախորդի գրառումը չի ներառում երթուղիչի թունելի հասցեն, հաճախորդը դեպի այն ուղի չունի։ Եթե սերվերի գրառումը այդ հաճախորդի համար չի ծածկում հաճախորդի թունելի հասցեն, սերվերը դեն է նետում փաթեթը նախքան որևէ firewall-ի կանոն դիտարկելը։

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

Երկրորդ շերտ՝ մուտքային քաղաքականությունը, ոչ փոխանցման քաղաքականությունը

Firewall-ները կանոնները գնահատում են այն միջերեսում, որտեղ ժամանում է փաթեթը։ pfSense-ում և OPNsense-ում միջերեսի ներդիրը և կանոնների հերթականությունը որոշում են՝ թույլատրվա՞ծ է երթևեկությունը firewall-ի սեփական ծառայություններին, այն կանոնը, որը LAN հաճախորդներին դուրս է թողնում ինտերնետ, չի թույլատրում թունելի զուգընկերոջը բացել վեբ ինտերֆեյսը։ firewall4-ով OpenWrt-ում յուրաքանչյուր գոտի կրում է մուտքային քաղաքականություն՝ option input 'ACCEPT' կամ 'REJECT', և REJECT մուտքով գոտում գտնվող թունելի միջերեսը կմերժի կառավարման միացումները՝ միաժամանակ շարունակելով փոխանցել երթևեկությունը, եթե փոխանցումը թույլատրված է։

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

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Երրորդ շերտ՝ ինչ-որ բան լսու՞մ է այդ հասցեում։

Ծառայությունը կարող է աշխատել և այնուամենայնիվ անհասանելի լինել, որովհետև կապվել է մեկ հասցեի։ OpenWrt-ի uhttpd-ն ունի հստակ լսող գրառումներ /etc/config/uhttpd-ում, օրինակ՝ list listen_http '0.0.0.0:80', մինչդեռ միայն LAN հասցեին կապվող կառուցվածքը ոչինչ չի ընդունում թունելի հասցեում, և լսող միջերեսի կարգավորում ցուցադրող ապրանքները նույնպես այդպես են վարվում։ Վերևի լսող հրամաններն ուղղակիորեն պատասխանում են սրան։

Ապա անջատեք մերժումը լռությունից։ nc -vz 10.6.0.1 443-ի մերժված միացում վերադարձնելը նշանակում է, որ փաթեթը հասել է երթուղիչին և ինչ-որ բան մերժել է այն՝ կա՛մ փակ պորտ, կա՛մ հստակ մերժման կանոն։ Ժամկետի ավարտին սպասելը նշանակում է, որ փաթեթը դեն է նետվել կամ երբեք չի երթուղղորդվել։ Այս տարբերությունը ասում է, թե որ շերտը ստուգել հաջորդիվ, և դա արժե հինգ վայրկյան։

VPN միջերեսը սահման է, ոչ վերականգնման ուղի

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

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

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

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

Պատրաստեք վերադարձի ուղին նախքան քաղաքականությանը դիպչելը

Առաջին փոփոխությունից առաջ գրառեք չորս բան՝ ինչպես կհասնեք սարքին, եթե թունելը մեռնի, օրինակ՝ սերիական կոնսոլ, մատակարարի կոնսոլ կամ LAN-ում գտնվող մեքենա՝ ուր է արտահանվում ընթացիկ կարգաբերումը, որ մեկ կանոնը կամ ուղին եք փոփոխելու, և ինչպես ճշգրտորեն կվերադարձնեք հենց այդ տարրը։ OpenWrt-ում sysupgrade -b /tmp/backup.tar.gz-ը գրավում է կարգաբերումը, և խմբագրումները մնում են սպասման մեջ մինչև uci commit, ինչը ձեզ էժան չեղարկում է տալիս, եթե ժամանակին նկատեք։ pfSense-ը պահում է կարգաբերման պատմություն, և AutoConfigBackup-ը օգնում է միայն եթե այն արդեն միացված էր։ Եթե երթուղիչը աշխատում է fail-closed կանոնների հավաքածուով, հաստատեք, որ ձեր պլանավորած սպասարկման ուղին այն երթևեկության մեջ չէ, որը արգելափակում է այդ կանոնը, և հիշեք, որ վերագործարկումը կրկին կիրառում է մշտական կանոնները՝ դրանք ջնջելու փոխարեն։

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

Արագ ստուգում մեկնելուց առաջ՝

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