હોસ્ટ VPN સાથે જોડાયા પછી VirtualBox ગેસ્ટનું DNS તૂટી જાય છે

VPN જોડાય તે ક્ષણે જ Windows હોસ્ટ પર એક આંતરિક એપ્લિકેશન રિઝોલ્વ થાય છે, જ્યારે VirtualBox NAT પાછળનું Ubuntu ગેસ્ટ હજી પણ તેને શોધી શકતું નથી. ગેસ્ટનું પોતાનું રિઝોલ્વર છે અને NAT એડેપ્ટર DNSને એક કરતાં વધુ રીતે સંભાળી શકે છે. ગેસ્ટના રિઝોલ્વરને જાહેર સર્વરથી બદલવાથી સામાન્ય વેબસાઇટ્સ કામ કરે છે અને ખાનગી નામો નિષ્ફળ જાય છે, જે સમસ્યાનું નિરાકરણ કરવાને બદલે તેને અન્યત્ર ખસેડે છે. ચાર ચકાસણી ક્રમમાં કરો અને જે પ્રથમ ન ટકે ત્યાં થોભો.

તમે કયો એડેપ્ટર મોડ ડિબગ કરી રહ્યા છો તે નિશ્ચિત કરો

ફક્ત સાદા NAT મોડમાંનું એડેપ્ટર જ આ લેખમાં વર્ણવ્યા પ્રમાણે વર્તે છે. બ્રિજ્ડ એડેપ્ટર પોતાની ઓળખ સાથે ભૌતિક નેટવર્ક પર બેસે છે, NAT નેટવર્ક પોતાની DHCP અને DNS સેટિંગ્સ સાથેનું નામવાળું વર્ચ્યુઅલ સ્વિચ છે, અને ગેસ્ટની અંદરનું VPN ક્લાયન્ટ સંપૂર્ણપણે બીજું રિઝોલ્વર ઉમેરે છે. વાંચન આગળ વધારતાં પહેલાં મોડ નિશ્ચિત કરો, કારણ કે આ દરેક કિસ્સામાં સમારકામ અલગ છે.

એક VM વિવિધ મોડમાં બે એડેપ્ટર ધરાવી શકે છે, અને અસરગ્રસ્ત હંમેશા પ્રથમ હોતું નથી.

હોસ્ટ નામનું રિઝોલ્યુશન કરે છે કે નહીં તે પણ નિશ્ચિત કરો. ટનલ ચાલુ રાખીને હોસ્ટ પર એ જ એપ્લિકેશન ખોલો, અને ગેસ્ટ જે સંપૂર્ણ નામ વાપરશે તે જ વાપરો. જો હોસ્ટ પણ નિષ્ફળ જાય, તો દોષ ગેસ્ટનો નથી અને કોઈ પણ વર્ચ્યુઅલ નેટવર્કિંગ ફેરફાર તેને સુધારશે નહીં.

ગેસ્ટના રિઝોલ્વર દ્વારા એક નામને અનુસરો

એક આંતરિક નામ અને એક જાહેર નિયંત્રણ નામ પસંદ કરો, પછી બંનેને બંને જગ્યાએ ચકાસો. જે જાહેર નામ રિઝોલ્વ થાય છે જ્યારે ખાનગી નામ થતું નથી, તે ખામીને સામાન્ય નામ રિઝોલ્યુશનમાં નહીં પણ ખાનગી પથ પર સ્થાન આપે છે. ફક્ત ખાનગી નામ ચકાસવાથી તમે તૂટેલા રિઝોલ્વર અને તૂટેલા રૂટ વચ્ચે ભેદ કરી શકતા નથી.

ગેસ્ટની અંદર જુઓ કે રિઝોલ્વર ખરેખર શું વાપરવા માટે ગોઠવાયેલું છે. systemd-resolved ચલાવતા Ubuntu ગેસ્ટમાં, પ્રતિ-લિંક સ્થિતિ આવેલા સર્વરો દર્શાવે છે, અને resolv.conf ફાઇલમાં ફક્ત સ્ટબ સરનામું હોઈ શકે છે, જે યોગ્ય છે, શંકાસ્પદ નહીં. હાથે સંપાદિત ફાઇલ અથવા અલગ એન્ક્રિપ્ટેડ-DNS ક્લાયન્ટ લુકઅપ સંપૂર્ણપણે બીજે મોકલી શકે છે. બદલતાં પહેલાં જે મળે તે લખી લો.

resolvectl status
resolvectl query app.internal.example

અહીં રિઝોલ્યુશનને પહોંચથી અલગ કરો. સેવા અપહંચ રહેતી હોય ત્યારે આવતું સરનામું DNS નહીં પણ રૂટિંગ કે નીતિનો પ્રશ્ન છે.

તે એડેપ્ટર પર હોસ્ટ રિઝોલ્વર મોડ અજમાવો

VirtualBoxના NAT DNS વિકલ્પો વિવિધ પદ્ધતિઓ વર્ણવે છે, અને હોસ્ટનું પોતાનું રિઝોલ્વર ટનલ સાથે બદલાય ત્યારે આ તફાવત મહત્ત્વનો બને છે. DNS પ્રોક્સી ગેસ્ટની વિનંતીઓને તેને આપવામાં આવેલા સર્વરો પર મોકલે છે. હોસ્ટ રિઝોલ્વર મોડ વિનંતીઓને અટકાવે છે અને હોસ્ટની DNS APIને કૉલ કરે છે, અને VPN ક્લાયન્ટ દ્વારા ફરી ગોઠવાયેલ Windows રિઝોલ્વર જે મોડ અનુસરે છે તે આ જ છે.

ખોટી પદ્ધતિ સક્રિય કરો તો આદેશ તો સફળ થશે જ્યારે વર્તન બદલાશે નહીં, જે બપોર ગુમાવવાની મૂંઝવણભરી રીત છે.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

VMની વર્તમાન સેટિંગ્સ નોંધો, તેને બંધ કરો અને પહેલાં નિશ્ચિત કરેલા એડેપ્ટરને લક્ષ્ય બનાવો. વિકલ્પમાંનો છેલ્લો અંક સ્થિરાંક નહીં પણ એડેપ્ટર નંબર છે, તેથી જે VMમાં અસરગ્રસ્ત એડેપ્ટર બીજું છે તેના પર તેને લાગુ કરવું એ શાંત નિષ્ક્રિય ક્રિયા છે. ગેસ્ટ શરૂ કરો અને તેણે ખરેખર મેળવેલી રિઝોલ્વર ગોઠવણી તપાસો, કારણ કે ગેસ્ટમાં હાથે કરેલું સેટિંગ NAT સ્તર જે પણ આપે તેના પર વિજય મેળવે છે. યાદ રાખો કે હોસ્ટ રિઝોલ્વર મોડ એ પણ ધારે છે કે હોસ્ટનો પોતાનો DNS પથ એ જ છે જે તમે વહેંચવા માંગતા હતા.

VPN ફરી જોડાણ દરમિયાન એ જ પરીક્ષણો ફરી કરો

ગેસ્ટમાં બંને લુકઅપ ફરીથી કરો, પછી સાચી એપ્લિકેશન ખોલો અને તેને પ્રમાણપત્ર જાતે ચકાસવા દો. ફક્ત સરનામા આધારિત પરીક્ષણ નામ રિઝોલ્યુશનને અલગ કરવા ઉપયોગી છે અને કાર્યકારી TLS સત્ર જેવું નથી, તેથી ping પર થોભો નહીં. પછી મંજૂર વિંડોમાં હોસ્ટ ટનલ ડિસ્કનેક્ટ અને ફરી કનેક્ટ કરો અને ફરી એક વાર દોહરાવો. બૂટ પછીના પ્રથમ જોડાણ પર જ ટકતું વર્તન એ જાણ કરવાપાત્ર જીવનચક્ર સમસ્યા છે, બીજા રિઝોલ્વર સાથે પીછો કરવાપાત્ર DNS રહસ્ય નહીં.

જાહેર રિઝોલ્યુશન કામ કરે તે એ સાબિત કરતું નથી કે ખાનગી પ્રશ્નો તમારી નીતિ માંગે તે પથ પર જ રહ્યા.

જ્યારે હોસ્ટ રિઝોલ્વર મોડ કંઈ બદલતું નથી, ત્યારે નોંધેલી ગોઠવણી પાછી મૂકો અને ચાર અવલોકન રાખો: હોસ્ટે શું પરત આપ્યું, ગેસ્ટે શું પરત આપ્યું, એડેપ્ટર મોડ અને રિઝોલ્વરની સ્થિતિ. અપહંચ આંતરિક સર્વર, હાઇપરવાઇઝર ટ્રાફિક બાકાત રાખતું ફિલ્ટર અને ગેસ્ટ તરફનું ઓવરરાઇડ દરેકને અલગ સુધારો જોઈએ. એડેપ્ટરને બ્રિજમાં ફેરવવું નેટવર્ક ડિઝાઇન બદલે છે અને તે DNS રીસેટ નથી.