WireGuard 5G մասնաճյուղ. թող մասնաճյուղն ինքը զանգահարի հանգույցին
Երբ մասնաճյուղը զանգահարում է հանգույցին, հանգույցն երբեք պետք չէ հայտնաբերել փոփոխվող բջջային հասցե։ Կարգավորեք, ստուգեք, ապա տեսեք, թե ինչ չի լուծում սա։
Մասնաճյուղը հանգույցին ուղղելը այս ձևավորման հեշտ կեսն է, երբ մասնաճյուղը նստում է փոփոխվող բջջային հասցեի հետևում, իսկ հանգույցն ունի կայուն անուն։ Այդ դեպքում հանգույցը մասնաճյուղին սովորում է վավերացված տրաֆիկից, ոչ թե գրառումից, որը դուք պետք է արդի պահեք։ Պայմանագիրը պարզ է: մասնաճյուղը միշտ սկսում է։
Կարգավորեք այն դիտավորյալ, ապա ստուգեք այն մասը, որը մարդիկ ենթադրում են, որ աշխատում է։ Երկու քայլերն էլ տևում են րոպեներ, և այս ձևավորումները սովորաբար ձախողվում են երկրորդի վրա։
Որ կողմն է պահում կայուն վերջնակետը
Մասնաճյուղի կարգավորումը նշում է հանգույցի վերջնակետը և նրա հանրային բանալին։ Հանգույցի կարգավորումը նշում է մասնաճյուղի հանրային բանալին և նրա թույլատրված ներքին նախածանցերը, և կարող է ընդհանրապես վերջնակետ չունենալ, որովհետև ինքնությունը գալիս է բանալուց, ոչ թե վերջին փաթեթի աղբյուրի հասցեից։ Այդ ասիմետրիան ամբողջ մեխանիզմն է, և այն հանգույցի կողմից հեռացնում է հայտնաբերման խնդիրների մի ամբողջ դաս։
Երբ մասնաճյուղը վավերացված փաթեթ է ուղարկում, հանգույցը գրանցում է այն աղբյուրը, որտեղից այն եկել է, և օգտագործում է այդ քարտեզագրումը պատասխանների համար։ Բջջային կապի վերահամարակալումն այդ դեպքում ոչինչ չի արժենա բացի հաջորդ ձեռքսեղմումից, և յուրաքանչյուր բաղադրիչ, որն այլևս պետք չէ, այնպիսին է, որը չի կարող խափանվել անցման ընթացքում։ Այդ հատկությունը արժե փորձարկել պլանավորված փոփոխության ընթացքում, ոչ թե միջադեպի ընթացքում։ Արեք դա, երբ ինչ-որ մեկը կարող է միաժամանակ դիտել երկու ծայրերը։
Տվեք մասնաճյուղին կարգավորում, որը դիմանում է վերահամարակալմանը
Պահեք վերջնակետը և keepalive-ը մասնաճյուղում, և պահեք հանգույցի զուգընկերոջ գրառումը առանց կոշտ կոդավորված հասցեի։ keepalive-ը թարգմանված քարտեզագրումը բաց է պահում բավական երկար, որպեսզի հանգույցը պարապ ժամանակաշրջանից հետո ուղարկի չպահանջված տրաֆիկ։
[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25
Քսանհինգ վայրկյանը NAT քարտեզագրումը կենդանի պահելու հաճախ մեջբերված օրինակն է, ոչ թե պահանջ յուրաքանչյուր զուգընկերոջ համար։ Սահմանեք այն ձեր իրականում դիտարկած քարտեզագրման ժամկետի հիման վրա, և հիշեք, որ այն տրաֆիկ է առաջացնում տվյալների սահմանաչափով կապում, քանի դեռ ինտերֆեյսը միացված է։
Հանգույցում մասնաճյուղի զուգընկերոջ թույլատրված նախածանցերը պետք է ծածկեն այն ամենը, ինչ մասնաճյուղը կուղարկի։ Բացակայող նախածանցը վարվում է որպես երթուղավորման խափանում հեռու ծայրում և ոչ մի կողմում որևէ նախազգուշացում չի առաջացնում, դրա համար արժե ստուգել այն առաջին իրական փաթեթից առաջ։ Համեմատեք հանգույցի թույլատրված նախածանցերը մասնաճյուղի ինտերֆեյսի հասցեների հետ առաջին միացումից առաջ։
Ստուգեք քարտեզագրումը և վերափոխումը
Հաստատեք, որ ձեռքսեղմումն ավարտվում է, որ հանգույցը թվարկում է մասնաճյուղի ընթացիկ վերջնակետը, և որ մասնաճյուղի ներքին հասցեները հասանելի են թունելի միջով։ Սա ելակետային գիծն է, և այն պետք է գրանցվի նախքան որևէ մեկը կդիպչի բջջային կապին։ Երկու տող ելքը բավական է։ Պահեք դրանք տոմսում ժամանակի դրոշմով։
wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1
Ապա փորձարկեք այն խափանումը, որի համար գոյություն ունի ձևավորումը։ Անջատեք հիմնական WAN-ը և հաստատեք, որ մասնաճյուղի հիմքում ընկած երթուղին դեպի հանգույց այժմ դուրս է գալիս բջջային ինտերֆեյսով։ Թունելը չի կարող վերանորոգել կոտրված ֆիզիկական ուղին, ուստի դեռ մեռած վերին կապին ուղղված արտաքին երթուղին առաջացնում է ձեռքսեղմման ժամկետի սպառում, որը ճիշտ հանգույցի խնդրի տեսք ունի։
Եթե արտաքին ուղին բացահայտ կապակցված է կամ քաղաքականությամբ երթուղավորված, վերափոխումը պետք է ներառի այն։ Ճիշտ ընթերցվող ձևավորման և ընդհատումը վերապրող ձևավորման միջև այդ բացը սովորաբար միակ բացակայող բանն է։
Ինչ չի լուծում այս ձևավորումը
Այստեղ ոչինչ չի թույլատրում մուտքային միացում դեպի մասնաճյուղ։ Եթե գլխամասում ինչ-որ բան պետք է զանգահարի բջջային վայրին, թունելի ուղղությունը սխալ է այդ պահանջի համար, և դինամիկ DNS-ը միայն անուն է թարմացնում։ Մատակարարի թարգմանությունը, մուտքային քաղաքականությունը և հաճախորդի վերջնակետի թարմացումը բոլորը մնում են ճանապարհին, և փոփոխված գրառումը չի կարող բացել օպերատորի մակարդակի NAT։
Պահեք մասնաճյուղի նախածանցը առանձին ցանկացած այլ վայրից, և սահմանափակեք, թե ինչ կփոխանցի նրա դարպասը։ Հանգույցի կայուն վերջնակետը պարզեցնում է հայտնաբերումը և ոչինչ չի անում երթուղավորման ձևավորման, հասցեների պլանավորման կամ այն հարցի համար, թե որ հավելվածային երթուղիներն են վերապրում վերափոխումը։
Գրեք չորս բան runbook-ում: ով է սկսում, որ նախածանցերն են թույլատրված, որքան է տևում keepalive-ը, և ինչ է պատահում, երբ հիմնական կապը ընկնում է։ Այդ տողերն են, ինչ ապագա օպերատորն իսկապես պետք ունի գիշերվա ժամը երեքին։