Առաջին գործարկում. WireGuard սարքերի պարկի գրանցում

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

Ինչ է կրում պատկերը, և ինչ՝ ոչ

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

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

Քայլ 1: բանալին գեներացնել տեղում

Կատարեք գեներացումը պաշտպանված թղթապանակում այն բանից հետո, երբ հիմնական ցանցային կապը հաստատվել է և աշխատում է։ Ենթահեղեղը պահում է umask փոփոխությունը տեղական այս գործողության համար, և set -C հրաժարվում է վերագրել գոյություն ունեցող ֆայլը:

(
    umask 077
    set -C
    wg genkey > /etc/wireguard/device.key &&
        wg pubkey < /etc/wireguard/device.key > /etc/wireguard/device.pub
)

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

Պահեք սպասող բանալին կրկնվող փորձերի ընթացքում։ Ինքնությունը վերագեներացնելը յուրաքանչյուր ժամանակավոր ցանցային խափանումից հետո այն ուղին է, որով պարկը մնում է որբ peer-երով, որոնց ոչ ոք չի կարող կապել սարքի հետ։

Քայլ 2: թույլատրել սարքի գրառումը

Ենթադրենք, գույքագրումը այս տախտակը կոչում է device-042 և նրան հատկացնում է 10.90.0.42/32։ Գրանցման ծառայությունը պետք է ստուգի, որ այս հայտատուն իրավունք ունի այդ գրառմանը։ Ձևաթղթում մուտքագրված սերիական համարը ապացույց չէ, որովհետև սերիական համարները տպված են տուփի արտաքին կողմում։

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

Գրանցված գրառումը կապում է սարքը, նրա հանրային բանալին, հատկացված հասցեն և թույլատրված կառավարման դերը։ WireGuard-ն ինքը չի սահմանում գրանցման API, ուստի այդ ծառայությունը մի բան է, որը դուք գիտակցաբար կառուցում և շահագործում եք։

Քայլ 3: գրել երկու համապատասխան կոնֆիգուրացիա

Սարքին անհրաժեշտ է պրոֆիլ, որը կառավարման նախածանցերը ուղղորդում է թունել, իսկ դարպասին անհրաժեշտ է peer գրառում, որը թույլատրում է միայն այս սարքի սեփական աղբյուրի հասցեն, իսկ երբ դարպասը 10.90.0.1-ում է, իսկ կառավարման ցանցը՝ 10.60.0.0/16, սարքի կողմը այսպիսի տեսք ունի.

[Interface]
PrivateKey = <device-042 private key>
Address = 10.90.0.42/32

[Peer]
PublicKey = <trusted gateway public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.90.0.1/32, 10.60.0.0/16
PersistentKeepalive = 25

Փակագծերում եղած արժեքները տեղապահներ են, ոչ բանալիներ։ keepalive-ը կարևոր է, երբ տախտակը գտնվում է NAT-ի հետևում և պետք է մնա հասանելի, այն ամենուր պարտադիր չէ, և սովորությունից դրդված ավելացնելը ռադիոն արթուն է պահում առանց պատճառի։

Դարպասում peer գրառումը դիտավորությամբ նեղ է:

[Peer]
PublicKey = <device-042 public key>
AllowedIPs = 10.90.0.42/32

Մի պատճենեք սարքի նպատակակետերի ցանկը դարպասի peer գրառման մեջ։ Սարքում այդ ցանկն ասում է, թե ինչ ուղղորդել թունել՝ դարպասում այն ասում է, թե որ աղբյուրի հասցեներն այս peer-ը կարող է օգտագործել, և դրանք տարբեր պնդումներ են։

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

Քայլ 4: ամրագրել գրանցումը որպես կյանքի ցիկլի վիճակ

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

Պահեք վերականգնման ուղի ընդհատված նախապատրաստման համար, ներառյալ այն դեպքը, երբ դարպասը ընդունել է բանալին, և սարքը երբեք չի գրել իր պրոֆիլը։

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