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

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

Հետևեք մեկ հարցումանքի NAT ադապտերի միջով

Որպես հսկիչ ընտրեք մեկ ներքին լրիվ որակավորված անուն և մեկ հանրային անուն։ Թունելը վերևում, հաստատեք հոստում, որ ներքին անունը լուծվում է, և որ դրա հետևի հավելվածը բացվում է։ Այնուհետև գործարկեք նույն երկու հարցումները հյուրի ներսում և համեմատեք պատասխանները, ոչ թե գործիքները։

Նախքան առաջ գնալը հաստատեք, որ ադապտերն իսկապես սովորական NAT է։ Կամրջված ադապտերը, անվանված NAT ցանցը և հյուրի ներսում երկրորդ VPN հաճախորդը յուրաքանչյուրն ունի իր կարգավորումը և իր բացատրությունը։ Այս պահին գուշակելը վատնում է հետաքննության մնացած մասը։

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

Առաջին հրամանը ցույց է տալիս ադապտերի ռեժիմը և դրան կցված ցանկացած NAT ցանց։ Ubuntu հյուրի ներսում երկրորդը թվարկում է կապակցված DNS կարգավորումները, իսկ երրորդը հաճախ բացահայտում է միայն տեղական stub հասցե, ինչը նշանակում է, որ իրական upstream-ը այլ տեղ է։

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

Պրոքսի ռեժիմը և հոստի լուծիչի ռեժիմը տարբեր մեխանիզմներ են

Պրոքսի ռեժիմում NAT շարժիչը հյուրի հարցումները փոխանցում է DNS սերվերներին, որոնք արդեն գիտի։ Հոստի լուծիչի ռեժիմում այն ընդհատում է հարցումը և խնդրում հոստի օպերացիոն համակարգին լուծել անունը նրանով, ինչ հոստը հենց հիմա օգտագործում է։ Միայն երկրորդն է հետևում VPN հաճախորդին, որը թունելի բարձրանալիս վերագրում է հոստի լուծումը։ Այդ պատճառով երկու կարգավորումները նույն մեքենայի վրա տարբեր պատասխաններ են տալիս։

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

Ռեժիմներից ոչ մեկը ոչ մի բանի հասանելիություն չի տալիս։ Լիազորումը ապրում է VPN քաղաքականության և ծառայության մեջ, և աշխատող հարցումը միայն նշանակում է, որ անունը վերածվել է հասցեի։

Փոխեք ադապտերը, ապա ստուգեք, թե ինչ է ստանում հյուրը

Նախ գրառեք VM-ի ցանցի և DNS կարգավորումները, ապա անջատեք մեքենան, որպեսզի խմբագրեք մշտական կոնֆիգուրացիան։ work-ubuntu անունով VM-ի համար, որի առաջին ադապտերը կրում է NAT, ադապտերային ընտրանքը սահմանվում է հոստից, երբ VM-ն անջատված է։ Այնուհետև նորից գործարկեք այն և ուսումնասիրեք արդյունքը՝ ելքի կարգավիճակին վստահելու փոխարեն։

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

Վերջին թվանշանը ընտրում է ադապտերի համարը, ուստի սա ունիվերսալ արժեք չէ. 2 ադապտերի կարգավորումը այդ դիրքում 2 կկրեր։ Օգտագործեք տեղադրված VirtualBox տարբերակին պատկանող VBoxManage բինարը, քանի որ ուղու վրա ավելի հինը կարող է գրառել կարգավորումներ, որոնք աշխատող տարբերակն անտեսում է։

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

Փորձարկեք VPN-ի ողջ կյանքի ցիկլով, ոչ միայն մեկ անգամ

Կրկնեք երկու հարցումներն էլ հյուրում, ապա բացեք իրական հավելվածը և թողեք այն վավերացնի TLS հոստի անունը։ Միայն IP-ով միացման փորձարկումը լավ մեկուսացնում է DNS-ը, բայց դա սերտիֆիկատի ստուգում չէ և չպետք է այդպես հաղորդվի։ Գրառեք անունը, հասցեն և հավելվածի արդյունքը միասին։

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

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