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

Ինչ է փոխում թունելը և ինչ դեռ որոշում է SSH-ը

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

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

Ձախողման ձևերը նույնպես առանձին են, և դա է բաժանումը դարձնում օգտակար միջադեպի ընթացքում։

Երեք պայման, որոնք որոշում են հասանելիության մոդելը

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

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

Պատասխանեք այդ երեքին, և մոդելն ինքն իրեն կընտրի։ Բաց թողեք դրանք, և դուք կավարտեք՝ SSH-ը հրապարակավ բացահայտելով հաճախորդի տեղադրումից խուսափելու համար։

Հաստատեք մասնավոր ուղին՝ նախքան SSH-ին մեղադրելը

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

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

Այդ անհամապատասխանությունը VPN-ի վրա ամենատարածված ինքնաստեղծ SSH ձախողումն է։

Կարդացեք ձախողման փուլը, ոչ թե համակցված սխալը

Երեք փուլեր առաջացնում են երեք տարբեր հաղորդագրություններ, և դրանցից միայն մեկն է վերաբերում հավատարմագրերին։

StageWhat you seeWhat it points at
Before the connectionTimeout, no routeTunnel, route or gateway permission
Connection refusedImmediate resetNothing listening, or a host firewall rejecting
AuthenticationPermission denied after a promptUser, key or server policy

Օգտագործեք ճշգրիտ սխալը և սերվերի սեփական մատյանը՝ VPN-ի և SSH-ի հավատարմագրերը միասին վերակայելու փոխարեն։ Երկուսի վերակայումն այն է, թե ինչպես հինգ րոպեի ախտորոշումը դառնում է երկու օրվա ինքնության միջադեպ։

Մանրամասն ելքը ցույց է տալիս, թե որ փուլին եք հասել:

ssh -vv [email protected]

Պահպանեք հոսթի բանալիներն ու լիազորումը անձեռնմխելի

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

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

Սահմանափակեք ծառայության հասանելիությունը պահանջվող ինքնություններով և պահպանեք լիազորված վերականգնման ուղի ցանցային փոփոխությունների համար։

Առնչվող հոդվածներ