ખાનગી VPN નામ નિષ્ફળ જાય છે? DNS રિબાઇન્ડ સુરક્ષા શંકાસ્પદ છે

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

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

નીતિ વાંચતા પહેલાં જવાબ વાંચો

નામ તે રિઝોલ્વરને પૂછો જે VPN ખરેખર મોકલે છે, એને નહીં જે તમારો લેપટોપ ઘરે વાપરે છે. જવાબને તમે અપેક્ષા રાખો છો તે રેકોર્ડ સાથે સરખાવો, અને નોંધો કે જવાબ ખાલી છે, નકારાયેલો છે કે કોઈએ આયોજન ન કર્યું હોય તેવા જાહેર સરનામાંથી ભરેલો છે.

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

સંરક્ષણ ખરેખર શું રોકે છે

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

dnsmasq તે વર્તનનું બરાબર દસ્તાવેજીકરણ કરે છે, સાથે ડોમેન પ્રમાણે અપવાદો પણ. તેનું મેન્યુઅલ પૃષ્ઠ rebind-domain-ok ને એવા ડોમેનના નામ રાખવાની રીત તરીકે વર્ણવે છે જે કાયદેસર રીતે આવા સરનામાં પાછા આપી શકે. તેને એ સંકેત તરીકે વાંચો કે ઈરાદાપૂર્વકનો ઉપાય મર્યાદિત પરવાનગી છે, વૈશ્વિક સ્વિચ નહીં.

અપવાદને નામ જગ્યા સુધી મર્યાદિત કરો

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

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

પછી ઈરાદાપૂર્વકના નામોને આવરી લેતી સૌથી સાંકડી પરવાનગી ઉમેરો: એક ડોમેન, અથવા એક પ્રતિનિધિત્વ આપેલું પેટા-ડોમેન, તે રિઝોલ્વરના રૂપરેખાંકનમાં જેને VPN ક્લાયંટ પૂછે છે. તે રિઝોલ્વર પરના દરેક નામ માટે સુરક્ષા બંધ કરવાથી બધાનું સંરક્ષણ એકસાથે જતું રહે છે, જે નામોને તેની ક્યારેય જરૂર ન હતી તે પણ સામેલ છે.

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

સંસાધન અને સંરક્ષણ ફરી ચકાસો

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

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

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

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