Pritunl નું ખાનગી DNS નિષ્ફળ છે? એક સાંકડો રિઝોલ્વર રૂટ ઉમેરો

ખાનગી નામો કોર્પોરેટ નેટવર્ક પર દરેક માટે રિઝોલ્વ થાય છે અને VPN પર દરેક માટે સમય સમાપ્ત થાય છે. રિઝોલ્વર ગેટવેને જવાબ આપે છે, ત્યાં સુધીનો રૂટ અસ્તિત્વમાં છે, અને છતાં ક્વેરીને ક્યારેય જવાબ મળતો નથી. જે ખૂટે છે તે બીજું જાહેર રિઝોલ્વર કે વધુ પહોળો રૂટ નથી: તે એવું સ્ત્રોત સરનામું છે જેને ખાનગી DNS સર્વર જવાબ આપવા તૈયાર છે.

ખાતરી કરો કે રિઝોલ્વર તમારા ક્લાયંટ પૂલને નકારી રહ્યું છે

નિષ્ફળતા સ્ત્રોત વિશે છે, પહોંચ વિશે નહીં, તે સાબિત કરીને શરૂ કરો. કનેક્ટેડ ક્લાયંટથી ખાનગી રિઝોલ્વરને સીધું પૂછો અને જુઓ કે વિનંતી સમય સમાપ્ત થાય છે કે નકાર તરીકે પાછી આવે છે. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 સમય સમાપ્ત થાય છે જ્યારે ગેટવેથી એ જ ક્વેરી સફળ થાય છે, તે રિઝોલ્વર પરની ઍક્સેસ નીતિ તરફ સંકેત કરે છે. SERVFAIL જવાબ સંપૂર્ણપણે બીજી જગ્યાએ, સામાન્ય રીતે ઝોન અથવા અપસ્ટ્રીમ ફોરવર્ડર તરફ સંકેત કરે છે.

પરીક્ષણ પહેલાં ક્લાયંટનું સરનામું નોંધો. ક્લાયંટ પર ip -4 addr show tun0, અથવા કન્સોલમાં દર્શાવેલ લીઝ, તમને કહે છે કે રિઝોલ્વર કયો પૂલ જુએ છે.

પછી ખાતરી કરો કે માર્ગ બિલકુલ અસ્તિત્વમાં છે. જે રૂટ રિઝોલ્વરનું સરનામું ટનલમાં મોકલે છે તે પૂર્વશરત છે, ઉકેલ નહીં; જો પેકેટ ક્યારેય ન પહોંચે, તો સ્ત્રોત નીતિ પર ક્યારેય વિચારણા થતી નથી. ક્લાયંટ પર ip route get 10.40.0.53 વડે તેને ચકાસો.

બધું ભાષાંતર કરવાને બદલે એક હોસ્ટ રૂટ ઉમેરો

Pritunl નું ખાનગી-DNS માર્ગદર્શન સાંકડો ઉપાય વર્ણવે છે: રિઝોલ્વર સરનામા માટે NAT સક્ષમ /32 રૂટ, તે સરનામું ક્લાયંટના DNS સર્વર તરીકે પસંદ કરીને. રૂટ ફક્ત DNS ટ્રાફિક માટે રિઝોલ્વર જે સ્ત્રોત જુએ છે તે બદલે છે. એપ્લિકેશન ટ્રાફિક તમે તેના માટે પસંદ કરેલ સ્ત્રોત-જાળવણી ડિઝાઇન રાખે છે.

અસ્તિત્વમાંના રૂટને ઓવરલેપ માટે સમીક્ષા કર્યા પછી, સર્વરના સમર્થિત રૂટ માલિક દ્વારા તેને ગોઠવો. ઉપરના ઉદાહરણમાં લક્ષ્ય NAT સક્ષમ 10.40.0.53/32 છે, અને ક્લાયંટ પૂલ 10.90.0.0/24 રહે છે. એક સેવા ઠીક કરવા માટે આખી ખાનગી શ્રેણીનું ભાષાંતર કરશો નહીં, કારણ કે ક્લાયંટના વાસ્તવિક સરનામા પર આધાર રાખતી દરેક ડાઉનસ્ટ્રીમ નીતિ તેના બદલે ગેટવે જોવા લાગશે. પરીક્ષણ લુકઅપ દરમિયાન તેના ક્વેરી લોગને જોઈને રિઝોલ્વર ખરેખર કયું સરનામું મેળવે છે તેની ખાતરી કરો. ફક્ત એક હોસ્ટ રૂટ ભાષાંતર કે પરવાનગી વિશે કંઈ સાબિત કરતું નથી.

રિઝોલ્વરે હજી પણ UDP અને TCP પર ભાષાંતરિત સ્ત્રોતને મંજૂરી આપવી પડશે, અને તેના જવાબો પાછા આવી શકવા જોઈએ. સ્ત્રોત બદલવાથી ખૂટતો ઝોન કે રેકોર્ડ બની શકતો નથી.

સર્વર કે ક્લાયંટ ક્વેરી મોકલે છે તે નક્કી કરો

Pritunl VPN Client DNS Mapping સાથે જોડાયેલી DNS-પ્રોક્સી ગોઠવણીનું પણ દસ્તાવેજીકરણ કરે છે, જ્યાં સર્વર ક્લાયંટ વતી અપસ્ટ્રીમ ક્વેરી ફોરવર્ડ કરે છે. તે મોડેલમાં અપસ્ટ્રીમ સ્ત્રોત સર્વરના પોતાના નેટવર્ક સંદર્ભનો છે, અને ક્લાયંટ-બાજુનો અપવાદ ખોટો ઉપાય છે.

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

જાહેર વેબ પૃષ્ઠ નહીં, ખાનગી લુકઅપ ચકાસો

ફેરફાર લાગુ કરીને ફરી કનેક્ટ થયા પછી, ક્લાયંટની અસરકારક રિઝોલ્વર ગોઠવણીનું નિરીક્ષણ કરો, પછી એવું નામ રિઝોલ્વ કરો જે તમે જાણો છો કે ફક્ત ખાનગી ઝોનમાં જ છે. સ્પષ્ટ સર્વર વિના dig intranet.example.net બતાવે છે કે ક્લાયંટ ખરેખર શું વાપરે છે. તે પછી તે લુકઅપે પરત કરેલા સરનામા પર વિનંતી મોકલો, કારણ કે રિઝોલ્યુશન અને સેવા ઍક્સેસ અલગ પગલાં છે. DNS-over-HTTPS દ્વારા જાહેર સાઇટ લોડ કરતું બ્રાઉઝર ઓપરેટિંગ સિસ્ટમના ખાનગી રિઝોલ્વર માર્ગ વિશે કંઈ સાબિત કરતું નથી. જાહેર ગૌણ રિઝોલ્વર પણ આંતરિક ઝોન માટે સત્તા નથી.

રિઝોલ્વર સરનામું, /32 રૂટ અને ક્લાયંટ DNS સેટિંગ સાથે મળીને સર્વર નોંધમાં લખો. તે ગોઠવણીનો અડધો ભાગ એકલો પુનઃસ્થાપિત કરવામાં આવે તો મૂળ નિષ્ફળતા ફરી થાય છે.

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