Docker: VPN նստաշրջանի ընթացքում նախապես սահմանված հասցեային լողավազաններ չեն մնում

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

Հաստատեք, թե ինչն է ձախողվել, նախքան որևէ բան փոխելը

Կատարեք ստորև բերված քայլերը այն հոսթից, որը գործարկում է դեմոնը։ Հեռավոր համատեքստի հետ խոսող shell-ը նկարագրում է այլ մեքենա, և միայն այդ սխալը կարող է մեկ ժամ վատնել։

Միևնույն ժամանակ գրանցեք Engine-ի տարբերակը տոմսում։ Այս ուղեցույցի մնացած մասի յուրաքանչյուր էվրիստիկա կապված է տարբերակի հետ, և առանց տարբերակի պնդումը լուր է։

Հաշվեք այն տրամադրումները, որոնք արդեն ունեք

Թվարկեք ցանցերը, ապա ստուգեք կարևորները՝ docker network ls, ապա docker network inspect NETWORK_NAME։ Կարդացեք դրանց IPAM ենթացանցերը և յուրաքանչյուրին միացված կոնտեյներները։ Մի քանի Compose նախագծեր սպառում են ավելի շատ բլոկներ, քան հուշում է նրանց կոնտեյներների քանակը, որովհետև յուրաքանչյուր նախագիծ հակված է ստեղծել իր սեփական լռելյայն ցանցը։ Կանգնեցված կոնտեյները չի ազատում իր ցանցի տրամադրումը։

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

Գրեք թիվը։ Հենց դա է հենակետը, որը ձեզ ասում է՝ օգնե՞ց հաջորդ փոփոխությունը։

Համեմատեք դեմոնի պատկերացումը երթուղիների մասին

VPN-ը կարող է ազդել թեկնածուների ընտրության վրա, բայց թե ինչպես՝ որոշում է կոնկրետ իրականացումը։ Linux-ում Moby 28.2.2-ում InferReservedNetworks-ը հավաքում է անվանասերվերների հասցեներ և որոշ on-link IPv4 երթուղիներ, և այն պարզապես չի վերապահում յուրաքանչյուր աղյուսակի յուրաքանչյուր երթուղին։ Հավաքված կապի երթուղիները նաև բացառում են չճշտված նպատակակետ հասցեն, ուստի միայն մեկ 0.0.0.0/1 երթուղին չի վերապահում բոլոր հասցեները։ Մեկ այլ լայն on-link նախածանց, օրինակ 128.0.0.0/1-ը, կարող է հատել ծանոթ 172 և 192 թեկնածու տիրույթները։

Համեմատեք ip -4 route show table all-ը VPN-ի միանալուց առաջ և հետո՝ դեմոնի հոսթի վրա։ Տարբերությունը ապացույցն է, իսկ տարբերակը՝ պնդման սահմանը։

Մի ընդհանրացրեք մեկ թողարկման էվրիստիկան բոլոր թողարկումներին։ Այդպես է ֆորումի պատասխանը դառնում քաղաքականության փոփոխություն։

Ընտրեք ամենափոքր աշխատող ուղղումը

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

default-address-pools-ի փոփոխությունը ապագա տրամադրումների մասին ավելի լայն քաղաքականություն է։ Ընտրեք չհակասող բազա և համապատասխան տրամադրված չափ, միավորեք այն գոյություն ունեցող դեմոնի կարգավորումների հետ, և պլանավորեք փաստաթղթավորված վերագործարկման ազդեցությունը։ Գոյություն ունեցող ցանցերը լուռ չեն վերահամարակալվում։

Մի անջատեք ընկերության երթուղիների ուղարկումը, որպեսզի տրամադրումը հաջողվի։ Բացահայտ հասցեային պլանը սովորաբար լուծում է տեղական խնդիրը՝ չթուլացնելով պարտադիր քաղաքականությունը։

Ընդունեք տրամադրումը և երթուղավորումը առանձին

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

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

Ուղեցույցը լրիվ է, երբ մեկ ուրիշը կարող է կրկնել այդ երկու ստուգումները և ստանալ նույն պատասխանը։