DNS AWS Client VPN-ում. օգտագործեք VPC-ի resolver-ը, ոչ ենթացանցը

Endpoint-ը գտնվում է 10.0.8.0/24-ում, ուստի resolver-ը պետք է լինի 10.0.8.2։ Սա ամենահաճախ լսվող տրամաբանությունն է և սխալ է երկու անգամ։ Route 53 Resolver-ը պատասխանում է VPC-ի հիմնական IPv4 միջակայքում գումարած երկու, ինչը 10.0.0.0/16 VPC-ի համար 10.0.0.2 է՝ անկախ նրանից, թե endpoint-ը որ ենթացանցն է օգտագործում։ Երկրորդ սխալն ավելի լուռ է. ճիշտ հասցեն endpoint-ում դնելը չի նշանակում, որ client-ի օպերացիոն համակարգը երբևէ ինչ-որ բան կհարցնի դրանից։ Երկու սխալներն էլ տալիս են նույն ախտանիշը. անունների լուծումը աշխատում է որոշ client-ների մոտ և ձախողվում մյուսների մոտ։

Առասպելը սկսվում է ենթացանցի կապակցումից

Կապակցումը վերաբերում է նրան, թե որտեղ են ապրում client-ային միացումների առաձգական ցանցային ինտերֆեյսները, ոչ թե նրան, թե որ resolver հասցեն գոյություն ունի։ Endpoint-ի ենթացանցերը client-ներին տալիս են հասցե VPC-ի ներսում, և դրանցից յուրաքանչյուրը չի կրում իր սեփական resolver-ը։

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

Հաշվեք հասցեն VPC-ի հիմնական միջակայքից

Վերցրեք VPC-ի հիմնական IPv4 CIDR-ը և ցանցային հասցեին ավելացրեք երկու։ 10.0.0.0/16-ը տալիս է 10.0.0.2, 172.31.0.0/16-ը՝ 172.31.0.2, իսկ երկրորդական միջակայքով VPC-ն resolver-ը պահում է հիմնականի վրա։ Այդ VPC-ի ներսում 10.0.8.0/24 ենթացանցը այն չի տեղափոխում։ Գրեք հասցեն VPC ID-ի կողքին՝ նախքան endpoint-ին դիպչելը, որովհետև թիվը VPC-ի հատկությունն է, ոչ թե միացման։

VPC-ն պատասխանում է նաև link-local 169.254.169.253 հասցեով։ Այդ հասցեն հասանելի է VPC-ի ներսից, բայց թունելի մյուս ծայրում գտնվող նոթբուքի համար այն ընդհանուր երթուղավորվող նպատակակետ չէ։

Այսպիսով կան երկու վավեր resolver հասցեներ, և դրանցից ոչ մեկը ենթացանց գումարած երկու չէ։

Ինչ է անում endpoint-ի կարգավորումը և ինչ ոչ

Client VPN endpoint-ն ունի DNS սերվերի դաշտեր, և որտեղ console-ը առաջարկում է VPC resolver տարբերակ, այն լրացնում է նույն գաղափարը։ Դրանց սահմանումը փոխում է այն, ինչ ծառայությունը հանձնում է client-ներին միացման հաստատման ընթացքում։ Այն չի փոխում այն, ինչ չկառավարվող OpenVPN client-ը անում է այդ արժեքի հետ, որովհետև client-ը դեռ պետք է այն կիրառի օպերացիոն համակարգի վրա։ Հենց այս ճեղքից է գալիս «աշխատում է իմ Mac-ում, բայց ոչ Linux մեքենայում»։

Linux-ում resolver-ի ինտեգրումը պատկանում է միացումների կառավարիչին, ոչ թե օգտվողին։ /etc/resolv.conf-ը ձեռքով խմբագրելը ապացուցում է, որ հասցեն աշխատում է մեկ սեսիայի համար, ապա անհետանում վերամիացման ժամանակ. դրա համար է, որ շատ ուղղված դեպքեր վերադառնում են հաջորդ առավոտ։

Միանալուց հետո ստուգեք ակտիվ resolver-ը client-ում, ոչ թե endpoint-ի կարգավորման էջը։

Split tunneling-ը կարող է խափանել ճիշտ resolver-ը

Split tunneling-ի դեպքում օգտագործվում են միայն թունել մղված երթուղիները։ Եթե resolver-ի հասցեն որևէ երթուղով ծածկված չէ, հարցումը դուրս է գալիս տեղական ինտերֆեյսով և պատասխանում է ձեր տնային երթուղիչը։ Endpoint-ի հասցեն դեռ ճիշտ է, և որոնումը դեռ ձախողվում է։ Ավելացրեք resolver-ի երթուղին, ապա նորից փորձարկեք։

Համընկնող տեղական միջակայքերը տալիս են նույն արդյունքն ավելի տհաճ ձևով. հարցումը պատասխան է ստանում, միայն թե սխալ սերվերից։

Մի բացեք security group-ներ Amazon DNS հասցեի համար

Երբ որոնումները ժամանակը սպառում են, բնազդն ասում է ավելացնել կանոն, որը թույլ է տալիս UDP 53 դեպի resolver-ի հասցեն։ AWS-ը փաստագրում է, որ security group-ները և ցանցային ACL-ները չեն զտում Amazon DNS երթևեկությունն այնպես, ինչպես զտում են երթևեկությունը դեպի սեփական DNS ինստանս։ Այդ կանոնները բացելը ոչինչ չի փոխում VPC resolver-ի համար և առանց պատճառի լայնացնում է սահմանը։ Ձեր իսկ վարած resolver-ը այլ դեպք է և իսկապես ունի իր կանոնների կարիքը։

Եթե ձեր ձևավորման մեջ երկուսն էլ կան, նախքան որևէ կանոն խմբագրելը ստուգեք, թե client-ը իրականում որին է ուղղված։

Ստուգեք ուղին, ապա չափեք այլ բան

Լուծեք հանրային անուն, լուծեք VPC-ի հետ կապված մասնավոր հոսթինգ գոտում գրանցված մասնավոր անուն և դրանց միջև կարդացեք client-ի ակտիվ resolver-ը։ Այդ հաջորդականությունը տարանջատում է «resolver-ի հասցեն սխալ է»-ը «գոտին կապված չէ»-ից և «client-ը անտեսել է կարգավորումը»-ից։ Յուրաքանչյուրն ունի տարբեր լուծում, և ոչ մեկը թողունակության խնդիր չէ։

Հաջող որոնումը ոչինչ չի ասում կայուն փոխանցման արագության մասին, ուստի հաշվետվության ժամանակ այս երկու զրույցները առանձին պահեք։