Արդյո՞ք WireGuard-ը պատրաստ է արտադրության համար։ Պատասխանը պրոտոկոլում չէ
Պատրաստությունը վերաբերում է UDP ուղուն, բանալիների սեփականությանը և փաթեթի սպասարկմանը, ոչ թե ձեռքսեղմմանը։ Չորս դարպաս է որոշում, թե արդյոք ձեր տեղակայումն իսկապես պատրաստ է։
Մարդիկ հարցնում են՝ արդյո՞ք WireGuard-ը պատրաստ է արտադրության համար, ինչը հնչում է որպես հարց գաղտնագրության մասին և իրականում հարց է ձեր միջավայրի մասին։ Պրոտոկոլը տարիներ շարունակ ստուգվում է, սակայն տեղակայումը դեռ պետք է պատասխանի՝ արդյո՞ք ձեր ցանցերը կրում են դրա տրանսպորտը, ով է գրանցում և դուրս բերում սարքերը, և ով է կարկատում փաթեթը երկու ծայրերում։ Այդ պատասխանները տարբերվում են մեկ դարակի երկու սերվերից մինչև հազար նոթբուք։ Պրոտոկոլը նույնն է երկու դեպքում, գործառնությունները՝ ոչ։
Հարցը հարցի հետևում
Մարդիկ սովորաբար ուզում են իմանալ՝ կարո՞ղ են նվիրվել այնպիսի նախագծի, որը վեց ամսից նրանց ամոթանքի չի ենթարկի։ Սա տեղակայման հարց է չորս մասով, և յուրաքանչյուր մաս կարող է ձախողվել մյուսներից անկախ։ Երեքի լավ պատասխանը չի փոխհատուցում չորրորդին։
Նախաթողարկային պատկերի մասին հին նախազգուշացումը փաստ է այդ պատկերի մասին, ոչ թե մշտական պիտակ յուրաքանչյուր հետագա փաթեթի վրա։ Նույն կերպ ոչ մի բլոգային գրառում չի կարող ձեր կոնկրետ միջուկի, հաճախորդի, ցանցի և անձնակազմի համակցությունը պատրաստ հայտարարել։ Աշխատանքը համակցությունը բացահայտ դարձնելն ու ստուգելն է։
Պատրաստությունը դիտարկեք որպես դարպասների հավաքածու, որոնք կա՛մ անցնում եք, կա՛մ գրանցում որպես բաց։ Դա վեճը դարձնում է պատասխանատուներով ստուգաթերթ։ Այն նաև բաց կետերը տեսանելի է դարձնում նրան, ով հաստատում է, փոխարենը թաղելու փորձնական զեկույցում։
Առաջին դարպաս. ուղին պետք է կրի UDP
WireGuard-ը իր երթևեկությունը կրում է UDP-ի վրայով և փաստաթղթավորում է, որ չի տրամադրում TCP ռեժիմ կամ երթևեկության քողարկում։ Նախագիծը, որը հենվում է սովորական վեբ երթևեկության տեսք ունենալու կամ TCP վարք ստանալու համար պորտը փոխելու վրա, հիմնված է ենթադրության վրա, որը ծրագրաշարը չի աջակցում։
Այսպիսով առաջին դարպասը հարցում է, ոչ թե մեկ մեքենայի փորձարկում։ Թվարկեք այն մուտքի միջավայրերը, որտեղ ձեր օգտատերերն իրականում աշխատում են, ապա ստուգեք հաստատված UDP ուղին յուրաքանչյուրում և որոշեք, թե ինչ է լինում, երբ այն հասանելի չէ։
Գրասենյակից աշխատող կապը ոչինչ չի ապացուցում հյուրանոցային ցանցի, համալսարանական հրակնոցի կամ UDP-ն այլ կերպ մշակող բջջային օպերատորի մասին։ Հենց այդ միջավայրերն են պատճառը, որ հեռահար մուտքի տեղակայումները ձախողվում են հաջող փորձարկումից հետո։ Փորձարկումը սխալ չէր, այն նեղ էր։ Այն լայնացնելը հենց դարպասն է։
Գրեք նաև պահուստային ուղին։ Եթե պատասխանն այն է, որ պահուստային ուղի չկա, դա որոշում է, որ արժե նախապես հայտարարել, քան գործուղման ընթացքում պարզել։
Երկրորդ դարպաս. ինչ-որ մեկը պետք է տիրապետի բանալիներին
WireGuard գործընկերները նույնականանում են բանալիներով՝ մեկ զույգ յուրաքանչյուր մասնակցի համար։ Դա հեշտ է նկարագրել և պահանջկոտ՝ շահագործման առումով, քանի որ պրոտոկոլում ոչինչ սարք չի գրանցում, չի հետևում, թե ով որ բանալին ունի, և չի հանում հասանելիությունը, երբ նոթբուքը կորչում է։ Պրոտոկոլը ենթադրում է, որ բանալիներն արդեն ճիշտ են, իսկ ճշտությունը ինչ-որ մեկի աշխատանքն է։
Անվանեք այն մարդուն, ով գրանցում է սարքը, այն գրառումը, որը հանրային բանալին կապում է մարդու և սարքի հետ, և հեռացման ընթացակարգը։ Եթե հեռացումը կախված է հիշողությունից, թե որտեղ են տեղադրվել կոնֆիգուրացիայի ֆայլի պատճենները, ընթացակարգը ավարտված չէ։
Փորձարկման ընթացքում ընտրեք մեկ սարք և դուրս բերեք այն սկզբից մինչև վերջ։ Այդ վարժությունը ավելի օգտակար տեղեկատվություն է տալիս, քան ևս մեկ կապի փորձարկում, որովհետև բացահայտում է ձեր գրառումների բացերը։
Երրորդ դարպաս. փաթեթը սպասարկող է պետք
WireGuard-ը կարող է գալ որպես միջուկի ներսում իրականացում, որպես բաշխման փաթեթ կամ որպես օգտատիրոջ տարածության հաճախորդ, և յուրաքանչյուրն ունի իր թարմացման ուղին։ Գործառնական հարցն այն է, թե որն եք գործարկում, որտեղից է այն եկել և ով է կիրառում անվտանգության տեղեկագիր։
Մենք օգտագործում ենք WireGuard-ը գույքագրում չէ։ Այն չի նշում կարկատման ենթակա փաթեթը, դարպասի տարբերակը կամ այն անձին, ով կարող է հետ շրջել վատ թարմացումը։
Չորրորդ դարպաս. ընդունեք աշխատանքային ծանրաբեռնվածությունը, ոչ թե ձեռքսեղմումը
Ընդունման չափանիշները պետք է նկարագրեն, թե ինչ են անում օգտատերերը։ Ներքին հավելվածին հասնելը, նրա մասնավոր անվան լուծումը, չարտոնված նպատակակետում մերժվելը և թունելի անջատ վիճակում սահմանված վարքին հետևելը բոլորը դիտարկելի են, և հաջող ձեռքսեղմումը դրանցից ոչ մեկը չէ։
Անցկացրեք այդ ստուգումները ցանցի փոփոխության, սարքի վերագործարկման և դարպասի սպասարկման պատուհանի միջով, որովհետև հենց այդ անցումներում են տեղակայումները կոտրվում։
Ապացույցները պահեք չափանիշների կողքին, ներառյալ այն տեղական վիճակը, որը դրանք ստեղծել է:
wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1
Հանգիստ ցանցում մեկ նոթբուքով կանաչ փորձարկումը սկզբնական դիտարկում է։ Դա հուսալիության մասին պնդում չէ, և դրան այդպես վերաբերվելը հենց այն ուղին է, որով աշխատող նախագիծը դառնում է վստահելի նախագիծ։