VPN կոնտեյների ցանցի համօգտագործումը՝ ինչ է պատահում DNS-ի հետ

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

Քայլ 1. փորձարկեք հավելվածից, ոչ թե հոսթից

Գործարկեք որոնումը խնդրահարույց կոնտեյների ներսում, ոչ թե հոսթի վրա և ոչ բրաուզերում։ docker exec app-container getent hosts db.internal պատասխանում է միակ կարևոր հարցին՝ ինչ է վերադարձնում այս գործընթացի լուծիչը։

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

Քայլ 2. կարդացեք կատարման միջավայրի աջակցվող մոդելը

Docker-ի ցանցային փաստաթղթերը գրանցում են DNS դրոշների սահմանափակումներ այն կոնտեյներների համար, որոնք կիսում են մեկ այլ կոնտեյների ցանցային ռեժիմը։ Compose-ում network_mode: service:vpn հավելվածը կապում է VPN կոնտեյների անվանատարածքին, իսկ յուրաքանչյուր ծառայության համար dns կարգավորումները իրենց չեն պահում այնպես, ինչպես սովորական ծառայության դեպքում։ Ստացված լուծումը հենց այն է, ինչ ունի համօգտագործվող անվանատարածքը։

Օգտատիրոջ կողմից սահմանված կամուրջ ցանցերը նույնպես Docker-ի ներկառուցված DNS-ն օգտագործում են այլ կերպ, քան լռելյայն կամուրջը։ Այդ պատճառով աշխատող կամուրջի օրինակից պատճենված dns դրույթը կարող է ընդհանրապես ոչինչ չանել համօգտագործվող փաթեթում։ Ստուգեք դասավորությունը նախքան դրույթը պատճենելը։

Loopback հասցեն միշտ վերաբերում է համապատասխան ցանցային համատեքստին։ Համօգտագործվող անվանատարածքի ներսում 127.0.0.1 հոսթի լուծիչը չէ։

Քայլ 3. հետևեք հարցմանը մինչև դրա ստացողը

Կարդացեք հավելվածի լուծիչի կարգավորումը, ապա հավելվածի հետ եկող ցանկացած հավելվածային գաղտնագրված DNS, քանի որ սեփական լուծիչ վարող հավելվածը անտեսում է ձեր խմբագրած ֆայլը։ Այնուհետև ստուգեք՝ ընտրված լուծիչը հասանելի է արդյոք VPN-ի երթուղիների և հրդեհային պատի քաղաքականության ներքո։ Թունելի մյուս կողմում գտնվող լուծիչի հասցեն անօգուտ է, եթե անվանատարածքը դրան երթուղի չունի։ Հաստատեք ստացողին նախքան որևէ ֆայլ խմբագրելը։

Բրաուզերի IP-ստուգման էջը չի կարող ասել, թե ուր գնացին անունների հարցումները։ Այն ասում է, թե ուր գնաց մեկ HTTP կապ։

Քայլ 4. ուղղեք խափանման երկու դասերը տարբեր կերպ

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

Եթե երկու դասերն էլ խափանվում են, սկսեք լուծիչի հասանելիությունից։ Եթե միայն մեկն է խափանվում, սկսեք հայտնաբերման մեխանիզմից։ Երկուսն ունեն տարբեր սեփականատերեր, դրա համար էլ մեկ վերանորոգումը երբեք չի ծածկում երկուսին։

Քայլ 5. կրկին փորձարկեք վերստեղծումից հետո

Փոխեք կարգավորումը կատարման միջավայրի աջակցվող մեխանիզմով, ապա վերստեղծեք կոնտեյներները՝ աշխատողի ներսում ֆայլեր խմբագրելու փոխարեն։ Փորձարկեք նոր մասնավոր անուն, նոր հանրային անուն և որոնումից հետո եկող հավելվածի հարցումը։ /etc/resolv.conf կոնտեյների ներսում խմբագրումը անհետանում է վերստեղծման ժամանակ և ձեզ կհամոզի, որ վերանորոգումն աշխատել է, երբ այն չի աշխատել։

Գրանցեք լուծիչի սեփականատիրոջը և սպասվող անվանատարածքը համօգտագործվող ցանցի սահմանման կողքին։ Հաջորդ մարդուն երկուսն էլ պետք կգան։