Ներքին TLS, SSH փոխանցում կամ VPN մեկ ամպային ծառայության համար

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

Սկսեք ծառայությունից, ոչ թե ցանցից

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

Վերցրեք փոքր ներքին API, որն արդեն HTTPS է մատուցում 8443 պորտում՝ api.internal.example-ի համար վկայականով։ Հոսթի վրա ss -ltnp-ը ցույց է տալիս, թե ինչին է կապված, իսկ openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example-ը ցույց է տալիս՝ վկայականը վավեր է արդյոք այն անվան համար, որը հաճախորդն իրականում կօգտագործի։ Եթե երկուսն էլ առողջ են, ծառայությունը կարող է պաշտպանել իր հոսքը, և մնում է միայն հասանելիությունը։ Սա շատ ավելի փոքր խնդիր է, քան ցանց կառուցելը։

Քայլ 1. արդյոք ծառայությունը պաշտպանում է իրեն։

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

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

Քայլ 2. արդյոք մեկ TCP պորտը ողջ պահանջն է։

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

Ձևը ssh -N -L 8443:127.0.0.1:8443 [email protected] է, և կարևոր մանրամասը թիրախային հասցեն է. 127.0.0.1-ը լուծվում է հեռավոր կողմում, ուստի ծառայությանը միացումը բացվում է բաստիոնից, ոչ թե ձեր նոութբուքից։ Կապեք տեղական լսողը նեղ ձևով որպես -L 127.0.0.1:8443:..., որպեսզի պատահաբար ծառայությունը չհրապարակեք ձեր սեփական տեղական ցանցում։ Սերվերի կողմում սահմանափակեք, թե ինչ կարող է հաշիվը փոխանցել՝ փոխարենը չվստահելով հաճախորդի լավ վարքին։ PermitOpen-ը, AllowTcpForwarding local-ը և լռելյայն GatewayPorts no-ը երեք կարգավորումներն են, որոնք ընդհանուր ռելեը դարձնում են որոշակի ալիք։

Պայմանագիրը նեղ է երկու ուղղությամբ։ SSH-ը պաշտպանում է իր ալիքը, և բաստիոնից մեկ այլ հավելվածի հետագա թռիչքը պահանջում է իր պաշտպանությունը։ Ծառայությունը, որը լսում է միայն բաստիոնի loopback-ում, ունի բոլորովին այլ ազդեցություն, քան մեկ այլ ցանցով հասանելիը, և փոխանցումը դա չի փոխում։ Պահեք հավելվածի նույնականացումը և TLS ստուգումները տեղում՝ թունելը դրանց փոխարինող չհամարելով։

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

Քայլ 3. արդյոք երթուղավորումն է իրական պահանջը։

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

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

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

Ինչ ունեք դրանից հետո

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

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