તમારું VPN DNS એન્ક્રિપ્ટ કરે છે કે ફક્ત આગલું હોપ?

VPN સર્વર પર એન્ક્રિપ્ટેડ DNS સક્ષમ કરવાનું ઘણી વાર લીક બંધ કરવું કહેવાય છે, અને એ વર્ણન છુપાવે છે કે કયું કનેક્શન બદલાયું. ક્લાયન્ટથી રિઝોલ્વર સુધીનું હોપ અને રિઝોલ્વરથી અપસ્ટ્રીમ સુધીનું હોપ અલગ માલિકો સાથેના અલગ કનેક્શન છે. એકને એન્ક્રિપ્ટ કરવાથી બીજું બરાબર જેવું હતું તેવું જ રહે છે.

કન્ફિગરેશન ફાઇલને અડકતાં પહેલાં દરેક તબક્કે ક્વેરી કોણ મેળવે છે તે લખો.

બે ગોઠવણીઓ સેટિંગ્સ પાના પર એકસરખી દેખાય છે

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

ફરક માપી શકાય તેવો છે, તાત્ત્વિક નહીં. ક્લાયન્ટ પર અથવા સર્વર પર TLS સેશન શોધો, અને તમને ખબર પડશે કે તમારી પાસે ખરેખર કઈ ગોઠવણી છે.

બદલતાં પહેલાં રિઝોલ્વર શૃંખલાનો નકશો બનાવો

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

પછી પૂછો કે ક્લાયન્ટને કયું ઘટક વાપરવા માટે ગોઠવવામાં આવ્યું છે. VPN પ્રોફાઇલ દ્વારા મોકલાતું DNS સરનામું કહે છે ક્વેરીઓ ક્યાં જાય છે, કઈ પ્રક્રિયા જવાબ આપે છે તે નહીં.

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

કયું હોપ એન્ક્રિપ્ટેડ છે તે ચકાસો

ક્લાયન્ટથી શરૂ કરો અને ખાતરી કરો કે તેની પાસે પોર્ટ 853 પર TLS સેશન છે કે નહીં. પોર્ટ 53 દ્વારા યોગ્ય રીતે રિઝોલ્વ થતી ક્વેરી એન્ક્રિપ્શન વિશે કંઈ સાબિત કરતી નથી.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

પછી VPN હોસ્ટ પર જાઓ અને ફોરવર્ડરે ખોલેલું બહાર જતું એન્ક્રિપ્ટેડ કનેક્શન શોધો. સોકેટ કોષ્ટક કહે છે કે અપસ્ટ્રીમ TLS સેશન છે કે નહીં, અને કઈ પ્રક્રિયા તેની માલિક છે:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

જો ક્લાયન્ટ TLS સેશન દર્શાવે અને સર્વર કંઈ નહીં, તો તમે પ્રથમ ગોઠવણીમાં છો અને સર્વર IP સ્તરે ફોરવર્ડ કરેલી ક્વેરી વાંચી શકતું નથી. જો સર્વર TLS સેશન દર્શાવે અને ક્લાયન્ટ ટનલની અંદર પોર્ટ 53 પર સામાન્ય ટ્રાફિક દર્શાવે, તો તમે બીજી ગોઠવણીમાં છો: આગલું હોપ સુરક્ષિત છે, પણ ફોરવર્ડર હજી ઉપકરણ માંગે છે તે દરેક નામ વાંચે છે. એ બીજું પરિણામ નિષ્ફળતા નથી, પણ તેને એન્ડ-ટુ-એન્ડ એન્ક્રિપ્શન કહેવું ખોટું છે.

માલિક અને નિષ્ફળતાનું વર્તન નોંધો

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

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

દરેક હોપ માટે એક વાક્ય લખીને સમાપ્ત કરો: કયા ઘટકે ક્વેરી મેળવી, એ હોપ એન્ક્રિપ્ટેડ હતું કે નહીં, અને કોણ નામ વાંચી શકે છે. જ્યારે VPN હોસ્ટ માટેનું વાક્ય હજી કહે છે કે તે ક્વેરી વાંચી શકે છે, ત્યારે દસ્તાવેજીકરણે એમ કહેવું જોઈએ, કારણ કે વિરુદ્ધ દાવો કરતી આકૃતિ પર એ વ્યક્તિ વિશ્વાસ કરશે જેણે કદી આ આદેશો ચલાવ્યા નથી.