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

નામ ઉકેલાય છે, અને બીજું કંઈ નક્કી નથી

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

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

dig +short vpn.example.net A
dig +short vpn.example.net AAAA
dig +short vpn.example.net A @1.1.1.1

ટ્રાન્સપોર્ટ અને ઓળખ અલગ પ્રશ્નો છે

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

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

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -dates

દેશના શબ્દો સ્થાનની ઓડિટ નથી

ડિરેક્ટરીમાં jp અથવા de લેબલ એ નોંધણી છે, અને IP ભૌગોલિક સ્થાન ડેટાબેઝ પૂરતા વારંવાર અસહમત હોય છે કે તેમાંથી કોઈને પણ સંપૂર્ણ સત્ય તરીકે ગણવા યોગ્ય નથી. શેર કરેલી હોસ્ટિંગ, anycast અને સાદી ખોટી રૂપરેખા બધા અવલોકિત સ્થાનને લેબલથી દૂર ખસેડે છે.

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

ઓફર કરેલી સેવા તપાસો, પછી ઓપરેટર

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

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

curl -sSI https://vpn.example.net/ | head -n 5
whois 203.0.113.25 | grep -i -E 'orgname|netname'

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

સંબંધિત લેખો