VirtualBox-ի հյուրի DNS-ը կոտրվում է, երբ հոսթը միանում է VPN-ին

Ներքին հավելվածը լուծվում է Windows հոսթի վրա այն պահին, երբ VPN-ը միանում է, իսկ VirtualBox NAT-ի հետևում գտնվող Ubuntu հյուրը դեռ չի գտնում այն։ Հյուրն ունի իր սեփական լուծիչը, և NAT ադապտերը կարող է DNS-ը մշակել մեկից ավելի եղանակով։ Հյուրի լուծիչը հանրային սերվերով փոխարինելը սովորական կայքերը դարձնում է աշխատող, իսկ մասնավոր անունները՝ ձախողվող, ինչը խնդիրը տեղափոխում է այլուր՝ փոխարենը լուծելու։ Կատարեք չորս ստուգումները հերթականությամբ և կանգ առեք առաջինի վրա, որը չի պահպանվում։

Հաստատեք, թե ադապտերի որ ռեժիմն եք վրիպազերծում

Միայն սովորական NAT ռեժիմում գտնվող ադապտերն է վարվում այնպես, ինչպես նկարագրում է այս հոդվածը։ Կամուրջ ադապտերը նստում է ֆիզիկական ցանցում իր ինքնությամբ, NAT ցանցը անվանված վիրտուալ անջատիչ է՝ իր DHCP և DNS կարգավորումներով, իսկ հյուրի ներսում գտնվող VPN հաճախորդը ավելացնում է ամբողջովին երկրորդ լուծիչ։ Հաստատեք ռեժիմը նախքան շարունակելը, որովհետև վերանորոգումը տարբերվում է այդ դեպքերից յուրաքանչյուրում։

Մեկ վիրտուալ մեքենան կարող է կրել երկու ադապտեր տարբեր ռեժիմներով, և տուժածը միշտ առաջինը չէ։

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

Հետևեք մեկ անվան հյուրի լուծիչի միջով

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

Հյուրի ներսում նայեք, թե ինչի համար է լուծիչը իրականում կարգավորված։ systemd-resolved-ով աշխատող Ubuntu հյուրի վրա հղումով կարգավիճակը ցույց է տալիս ժամանած սերվերները, և resolv.conf ֆայլը կարող է պարունակել միայն stub հասցե, ինչը ճիշտ է, ոչ կասկածելի։ Ձեռքով խմբագրված ֆայլը կամ առանձին գաղտնագրված DNS հաճախորդը կարող են հարցումներն ուղարկել բոլորովին այլուր։ Գրի առեք գտածը նախքան փոխելը։

resolvectl status
resolvectl query app.internal.example

Այստեղ առանձնացրեք լուծումը հասանելիությունից։ Հասցեն, որը ժամանում է, մինչ ծառայությունը մնում է անհասանելի, երթուղային կամ քաղաքականության հարց է, ոչ DNS հարց։

Փորձեք հոսթի լուծիչի ռեժիմը այդ ադապտերի վրա

VirtualBox-ի NAT DNS ընտրանքները նկարագրում են տարբեր մեխանիզմներ, և տարբերությունը կարևոր է դառնում, երբ հոսթի սեփական լուծիչը փոխվում է թունելի հետ։ DNS պրոքսին փոխանցում է հյուրի հարցումները իրեն տրված սերվերներին։ Հոսթի լուծիչի ռեժիմը ընդհատում է հարցումները և կանչում հոսթի DNS API-ն, և դա այն ռեժիմն է, որը հետևում է VPN հաճախորդի կողմից վերակարգավորված Windows լուծիչին։

Միացրեք սխալ մեխանիզմը, և հրամանը դեռ կհաջողվի, մինչ վարքը չի փոխվի, ինչը կեսօր կորցնելու շփոթեցնող եղանակ է։

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Գրի առեք վիրտուալ մեքենայի ընթացիկ կարգավորումները, անջատեք այն և նշանակետ դարձրեք ավելի վաղ հաստատած ադապտերը։ Ընտրանքի վերջին թվանշանը ադապտերի համար է, ոչ հաստատուն, ուստի այն մեքենայի վրա կիրառելը, որի տուժած ադապտերը երկրորդն է, լուռ անարդյունք գործողություն է։ Գործարկեք հյուրը և ստուգեք լուծիչի այն կարգավորումը, որը նա իրականում ստացել է, որովհետև հյուրում ձեռքով արված կարգավորումը գերազանցում է այն ամենին, ինչ առաջարկում է NAT շերտը։ Հիշեք, որ հոսթի լուծիչի ռեժիմը նաև ենթադրում է, որ հոսթի սեփական DNS ուղին այն է, ինչ ուզում էիք կիսել։

Կրկնեք նույն թեստերը VPN-ի վերամիացման ընթացքում

Կրկնեք երկու հարցումներն էլ հյուրում, ապա բացեք իրական հավելվածը և թողեք նա ինքը վավերացնի սերտիֆիկատը։ Միայն հասցեի վրա հիմնված թեստը օգտակար է անունների լուծումը մեկուսացնելու համար և համարժեք չէ աշխատող TLS նստաշրջանին, ուստի մի կանգ առեք ping-ի վրա։ Այնուհետև հաստատված պատուհանում անջատեք և նորից միացրեք հոսթի թունելը և կրկնեք ևս մեկ անգամ։ Վարքը, որը պահպանվում է միայն գործարկումից հետո առաջին միացման ժամանակ, հաշվետվության ենթակա կյանքի ցիկլի խնդիր է, ոչ թե DNS առեղծված, որ պետք է հետապնդել այլ լուծիչով։

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

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