Պահպանեք տեղական SSH-ը, երբ հոսթը օգտագործում է ելքային VPN

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

Ստորև բերված քայլերը ենթադրում են, որ ադմինիստրատորը նույն LAN-ում է։Հեռակա կառավարումը այլ խնդիր է՝ այլ պատասխանով։

Կապեք SSH-ը այն հասցեին, որն օգտագործում են ադմինիստրատորները

Սկսեք լսողից։ss -ltnp | grep :22 ցույց է տալիս, թե ինչին է կապված sshd-ն, և 0.0.0.0-ի վրա լսողը ընդունում է միացումներ բոլոր ինտերֆեյսներից, ներառյալ թունելը։ LAN հասցեին կապելը ավելի նեղ է և դիտավորությունը դարձնում է տեսանելի:ListenAddress 192.168.10.20 ֆայլում sshd_config, որին հաջորդում է կոնֆիգուրացիայի փորձարկում և վերաբեռնում։ Այդ հասցեում տառասխալն ավելի տեսանելի է, քան նիշը, որովհետև sshd-ն հրաժարվում է սկսել, երբ հասցեն գոյություն չունի։

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

Պահեք LAN երթուղին թունելից դուրս

192.168.10.0/24 հասցեով հոսթն ունի այդ նախածանցի միացված երթուղի, և ավելի կոնկրետ երթուղին հաղթում է VPN-ի լռելյայնին նույն աղյուսակում։ Այդ պատճառով տեղական SSH-ը հաճախ ինքնուրույն շարունակում է աշխատել, երբ թունելը բարձրանում է։ Ստուգեք դա՝ ենթադրելու փոխարեն:ip route get 192.168.10.50 նշում է ինտերֆեյսը և աղբյուրի հասցեն, որոնք կօգտագործեր միջուկը, և պատասխանը պետք է լինի LAN սարքը, ոչ թե թունելը։ Կրկնեք ստուգումը նաև ադմինիստրատորի մեքենայից, որովհետև նրա սեփական աղյուսակն է որոշում՝ փաթեթները կհասնեն արդյոք։ Նույն լարի վրա գտնվող երկու հոսթ կարող են չհամաձայնել, թե որ ուղղությունն է հասանելի։

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

Երթուղավորված կառավարման VLAN-ները մյուս դեպքն են։ Եթե ադմինիստրատորը նստած է 192.168.50.0/24-ում տեղական երթուղիչի հետևում, սերվերին անհրաժեշտ է հստակ երթուղի այդ նախածանցի համար 192.168.10.1-ի միջով, և այդ երթուղին պետք է դիմանա վերամիացմանը։ Բացառությունը պահեք կառավարման նախածանցին հատուկ. մասնավոր տիրույթների լայն բացառությունը չեղարկում է թունելի նպատակը։

Դարձրեք firewall-ի բացառությունը նույնքան նեղ, որքան կանոնը

Եթե հոսթը firewall է աշխատեցնում, թույլատրեք SSH միայն կառավարման աղբյուրից և միայն LAN ինտերֆեյսում։ Կանոնը, որը թույլ է տալիս 22 պորտը ամենուրից, ավելի լայն է, քան պահանջը, և ավելի դժվար է արդարացնել վերանայման ժամանակ։ nftables հոսթում կանոնը պատկանում է մուտքային շղթային՝ ինտերֆեյսի և աղբյուրի համընկնմամբ. iptables հոսթում համարժեքը -i և -s համընկնումների զույգն է։ Մեկնաբանեք կանոնը այն ադմինիստրատոր խմբով, որին այն ծառայում է, որպեսզի հաջորդ աուդիտը ստիպված չլինի գուշակել, թե ինչու է 22 պորտը բաց։

Ստուգեք նաև VPN հաճախորդի սեփական զտիչը։ Որոշ հաճախորդներ տեղադրում են կանոններ, որոնք նախագծմամբ գցում են տեղական երթևեկությունը, և հաճախորդի մակարդակում գցելու վրա ճիշտ firewall կանոնը ոչինչ չի փոխում։ Կարդացեք հաճախորդի կոնֆիգուրացիան նախքան հոսթի firewall-ը խմբագրելը, որովհետև շարքով երկու զտիչ առաջացնում են խափանում, որը նման չէ ոչ մեկին։

Փորձարկեք երկու վիճակներն էլ

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

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

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

Գրեք վերականգնման ուղին runbook-ում

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

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