استعمال شدہ 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 درخواست کا راستہ ثابت کرتی ہے اور اس بارے میں کچھ نہیں کہ کون سا حل کنندہ جواب دے۔ ایک میں رسنے والا آلہ دوسرے میں بالکل صحت مند دکھ سکتا ہے۔