વપરાયેલું VPN એક્ઝિટ સરનામું કેવી રીતે રેકોર્ડ અને ચકાસવું
ક્લાયન્ટ એપ્સ સ્થળનું નામ બતાવે છે, જે સરનામેથી તમારો ટ્રાફિક બહાર નીકળ્યો તે નહીં. કનેક્ટ થતી વખતે એક્ઝિટ IP કેપ્ચર કરો અને તેની સીધી આધારરેખા સાથે સરખામણી કરો.
કોઈ ડેસ્કટોપ VPN ક્લાયન્ટને પૂછો કે તમે કયા સર્વર વાપર્યા, અને પ્રામાણિક જવાબ સામાન્ય રીતે સ્થળનું નામ હોય છે. તે નામ તમારો પસંદ કરેલો પ્રવેશબિંદુ છે, અને જે સરનામેથી તમારો ટ્રાફિક બહાર નીકળ્યો તે સાવ બીજી મશીન હોઈ શકે. એપમાં બીજો નંબર રાખવા માટે કંઈ બનાવ્યું નથી, તેથી રેકોર્ડ વપરાશની ક્ષણે જ બનાવવો પડે. બે રસ્તા છે, અને તેમાંથી ફક્ત એક જ સપોર્ટ કેસ સામે ટકે છે.
બે રેકોર્ડ, અને તેમાંથી ફક્ત એક અસ્તિત્વમાં છે
ક્લાયન્ટનું પોતાનું દૃશ્ય શ્રેષ્ઠ સ્થિતિમાં સમયછાપ સાથે પસંદ કરેલા સ્થળોની યાદી છે. આ ડિઝાઇનનો નિર્ણય છે, ચૂક નહીં: સરનામાં કામગીરીની બારીકાઈ છે, તે સોંપણીઓ વચ્ચે બદલાય છે, અને મેપિંગ જાહેર કરવાથી સપોર્ટ અને દુરુપયોગની કાર્યવાહી બંને મુશ્કેલ બને છે. પ્રદાતાઓ પોતાના નેટવર્ક સામે ક્લાઉડ ઇન્સ્ટન્સ એટલા માટે મૂકે છે કે અંતિમબિંદુ કોઈને કહ્યા વિના જગ્યા બદલી શકે. એપ તમને તમારી પસંદગી બતાવે છે, ટ્રાફિકે લીધેલો રસ્તો નહીં.
તમે જાતે બનાવી શકો તેવો રેકોર્ડ એ દરેક લાઇનમાં એક જાહેર સરનામું અને એક UTC સમયછાપ ધરાવતી સ્થાનિક ફાઇલ છે. તે નાની, બેડોળ અને ઘણી વધુ ઉપયોગી છે, કારણ કે તે બરાબર એ જ વર્ણવે છે જે બહારનો નિરીક્ષક પણ જોઈ શકે.
વિકલ્પ અ: એક્ઝિટ સરનામું જાતે કેપ્ચર કરો
ઇકો સેવા જે સ્રોત સરનામેથી વિનંતી આવી તે પરત આપે છે, જે વ્યાખ્યા મુજબ એક્ઝિટ સરનામું છે. ટનલ કનેક્ટેડ જણાવે પછી કેપ્ચર ચલાવો, કારણ કે જે ક્લાયન્ટ રૂટ અને DNS સ્થિર થાય તે પહેલાં કનેક્ટેડ કહે છે તે ટનલ પહેલાંનું સરનામું નોંધશે અને પહેલી લાઇનથી જ લોગને દૂષિત કરશે.
#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"
બે બારીકાઈઓ તે ટુકડાને શોભા નહીં, કામનો બનાવે છે. સમયછાપ અને સરનામું એક જ લાઇનમાં છે, તેથી પછીના વિશ્લેષણને રેકોર્ડ જોડવાની જરૂર પડતી નથી, અને umask 077 ફાઇલને બન્યાની ક્ષણથી ખાનગી રાખે છે. તેને દરેક કનેક્શન પર એક વાર ચલાવો, દરેક બૂટ પર એક વાર નહીં, અને દરેક ઉપકરણ માટે એક ફાઇલ રાખો.
લોગ નોંધે છે કે તમે ટનલ ક્યારે વાપરી અને કયા નેટવર્કથી દેખાયા, જે ગણતરી કરતાં બ્રાઉઝિંગ ઇતિહાસની નજીક છે. એવો સમયગાળો પસંદ કરો જેનો તમે બચાવ કરી શકો, ફાઇલને શેર કરેલા સિંક ફોલ્ડરની બહાર રાખો અને તેને જાણી જોઈને સાફ કરો.
વિકલ્પ બ: પ્રદાતા પાસેથી ઇતિહાસ માંગો
કેટલાક પ્રદાતા કનેક્શન લોગ રાખે છે અને સપોર્ટના પ્રશ્નનો જવાબ સમયછાપ અને સર્વર નામ સાથે આપે છે. તે રેકોર્ડ તેમની ઇન્ફ્રાસ્ટ્રક્ચરનું વર્ણન કરે છે, તમારા ટ્રાફિકનું નહીં, અને તેમની જાળવણી વિન્ડો અને જોવાની તૈયારી જેટલું કિંમતી છે તેટલું જ કિંમતી છે. તે સત્રનું પણ વર્ણન કરે છે, વિનંતીનું નહીં. વિન્ડો સામાન્ય રીતે ટૂંકી હોય છે, અને ટનલના પ્રદાતાની બાજુથી માપવામાં આવે છે.
જે પ્રદાતા લોગ ન રાખવાની જાહેરાત કરે છે તે માંગણી પર આ આપી શકતા નથી, અને ક્લાયન્ટની બાજુની તાજેતરની સ્થળોની યાદી અલગ વસ્તુ છે. લોગ વગરના પ્રદાતા પાસે એક્ઝિટ સરનામું માંગવું સામાન્ય રીતે એ સમજૂતી પર પૂરું થાય છે કે આ ડેટા કેમ નથી.
સપોર્ટ કેસમાં દરેક રેકોર્ડ શું સાબિત કરી શકે
બંને રેકોર્ડ અલગ પ્રશ્નોના જવાબ આપે છે, અને કોષ્ટકમાં જ સરખામણી શૈક્ષણિક રહેવાનું બંધ કરે છે.
| Question | Your local log | Provider record |
|---|---|---|
| Which address did the traffic leave from? | Yes, for the moment it was captured | Usually not disclosed |
| Was the tunnel in use at 14:20? | Yes, if the capture ran | Yes, within the retention window |
| Why did a location get slower? | Yes, by comparing addresses over time | Sometimes, as an infrastructure note |
| Who sent this specific request? | No | No |
ફક્ત પહેલો સ્તંભ તમારા નિયંત્રણમાં છે. પ્રદાતાનો રેકોર્ડ પુષ્ટિ કરી શકે કે કોઈ ખાતું અમુક સમયે જોડાયેલું હતું, પણ કઈ વિનંતીઓએ ટનલ વાપરી તે પુષ્ટિ કરી શકતો નથી, અને પ્રદાતા કામગીરીની બારીકાઈ ગણે છે તેવું સરનામું નહીં જણાવે. કોઈ પણ રેકોર્ડ વ્યક્તિની ઓળખ કરતો નથી, કારણ કે વહેંચાયેલું એક્ઝિટ સરનામું એક જ મિનિટમાં ઘણા ગ્રાહકો ઊંચકી શકે છે.
કોઈ એક પર ભરોસો કરતાં પહેલાં બંનેની આધારરેખા સાથે સરખામણી કરો
એકલું સરનામું કંઈ સાબિત કરતું નથી. કનેક્ટ થવાના પહેલાં સીધું સરનામું, અને પછી ટનલવાળું સરનામું કેપ્ચર કરો, અને તેમની સરખામણી કરો. સરખા મૂલ્યોનો અર્થ એ કે ટનલ તે વિનંતી ઊંચકતું નથી, ભલે વિભાજિત ટનલ હોય, પ્રભાવી પ્રોક્સી હોય કે સીધા માર્ગે પાછો ફરેલો ક્લાયન્ટ હોય.
curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1
DNS અને IPv6 માટે સરખામણી ફરી કરો, કારણ કે સરનામાનો પડછાયો એક HTTP વિનંતીનો માર્ગ સાબિત કરે છે અને કયા રિઝોલ્વરે જવાબ આપ્યો તે વિશે કંઈ કહેતો નથી. એકમાં લીક થતું ઉપકરણ બીજામાં સાવ તંદુરસ્ત દેખાઈ શકે છે.