બે VPN, એક રિઝોલ્વર: જે છેલ્લે લખે તે જીતે

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

દંતકથા: સૌથી નવો VPN જ DNS ધરાવે છે

એવો કોઈ સામાન્ય નિયમ નથી કે સૌથી તાજું કનેક્શન જીતે છે. શું થાય છે તે પ્લેટફોર્મની પદ્ધતિ અને દરેક ક્લાયન્ટ તેને કેવી રીતે લખે છે તેના પર આધાર રાખે છે. રિઝોલ્વર ફાઇલ બદલતો ક્લાયન્ટ એક પરિણામ આપે છે; દરેક લિંક માટે ડોમેન ઉમેરતો ક્લાયન્ટ બીજું પરિણામ આપે છે; કંઈ ન કરતો ક્લાયન્ટ અગાઉની સ્થિતિ અકબંધ રાખે છે.

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

નામ સ્થાનોને રિઝોલ્વર સાથે મેપ કરો

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

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

Windows માં, નામ રિઝોલ્યુશન નીતિ કોષ્ટક સફિક્સને ચોક્કસ સર્વરો તરફ નિર્દેશિત કરી શકે છે, અને VPN ક્લાયન્ટ ત્યાં નિયમો ઇન્સ્ટોલ કરી શકે છે. એડેપ્ટર સૂચિને બદલે નીતિ તપાસો, કારણ કે નામ એડેપ્ટર સૂચિ રિઝોલ્વ કરતી નથી.

બૂટસ્ટ્રેપ પાથ રાખો

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

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

ઓવરલેપિંગ સરનામાં DNS સમસ્યા નથી

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

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

વાસ્તવિક એપ્લિકેશનોથી તેને સાબિત કરો

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

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