LEAK GUIDE

لیک کی جانچ · تکنیکی نوٹس

لیک ٹیسٹ میں ویب ایگزٹ، WebRTC، DNS، IPv6 اور ماحول کی ہم آہنگی کو ایک ساتھ دیکھا جاتا ہے۔ یہ نوٹس اصل لیک کو معمول کی قواعد پر مبنی روٹنگ یا پراکسی موڈ کی وجہ سے پیدا ہونے والے مغالطے سے الگ کرنے میں مدد دیتے ہیں۔

لیک ٹیسٹ پر واپس جائیں

Technical Notes

WebRTC، UDP اور DNS لیک کی وضاحت

WebRTC لیک کیا ہے

WebRTC براؤزر میں موجود ریئل ٹائم کمیونیکیشن کی صلاحیت ہے، جو ویڈیو کانفرنسنگ، وائس کالز، P2P فائل ٹرانسفر اور اسی طرح کے کاموں میں استعمال ہوتی ہے۔ پیئر ٹو پیئر کنکشن قائم کرنے کے لیے براؤزر STUN سرور کے ذریعے معلوم کرتا ہے کہ پبلک نیٹ ورک پر اس کا ایڈریس کیا نظر آتا ہے۔ یہ جانچ عموماً UDP پر ہوتی ہے، اور عام HTTP / SOCKS پراکسیز لازمی طور پر UDP کو نہیں سنبھالتیں۔

اگر STUN درخواست پراکسی کو بائی پاس کر کے براہ راست مقامی نیٹ ورک سے باہر جائے تو کوئی ویب اسکرپٹ آپ کا اصل پبلک IP حاصل کر سکتا ہے۔ اس عمل کے لیے عموماً کیمرے یا مائیکروفون کی اجازت درکار نہیں ہوتی اور نہ ہی کوئی اضافی تصدیقی پیغام آتا ہے، اسی لیے اسے عام طور پر یہ جانچنے کے لیے استعمال کیا جاتا ہے کہ پراکسی واقعی ریئل ٹائم کمیونیکیشن ٹریفک کو کور کرتی ہے یا نہیں۔

یہ ٹول اسے کیسے پکڑتا ہے

یہ صفحہ متعدد STUN سرورز پر WebRTC پروب بھیجتا ہے، واپس آنے والے پبلک ایڈریسز جمع کرتا ہے اور ان کا موازنہ HTTP ایگزٹ IP سے کرتا ہے۔ اگر واپس آنے والا ایڈریس موجودہ ایگزٹ سے میل کھاتا ہے تو UDP راستہ غالباً پراکسی سنبھال رہی ہے؛ اگر یہ آپ کے مقامی آپریٹر کا ایڈریس ہو تو اس کی چھان بین ضروری ہے۔

تصدیق کریں کہ UDP پراکسی ایگزٹ سے گزرتا ہے یا نہیں
معلوم کریں کہ IPv4 / IPv6 الگ الگ لیک ہو رہے ہیں یا نہیں
دیکھیں کہ کیا مختلف STUN اہداف پر روٹنگ کے مختلف قواعد لاگو ہوتے ہیں

STUN اور UDP کا کردار

UDP کنکشن کے بغیر کام کرنے والا ٹرانسپورٹ پروٹوکول ہے جو عموماً آواز، ویڈیو، گیمز اور ریئل ٹائم کمیونیکیشن میں استعمال ہوتا ہے۔ STUN کا کام سادہ ہے: آپ سرور کو ایک UDP پیکٹ بھیجتے ہیں، اور سرور آپ کو بتاتا ہے کہ اسے کون سا سورس IP نظر آیا۔ WebRTC کنکشن طے کرنے کے لیے اسی نتیجے پر انحصار کرتا ہے، اس لیے STUN کو نظر آنے والا ایڈریس لیک کا فیصلہ کرنے کا کلیدی ثبوت ہے۔

نتائج کو کیسے سمجھیں

کوئی لیک نہیں ملاWebRTC سے واپس آنے والا پبلک IP آپ کے موجودہ پراکسی ایگزٹ سے میل کھاتا ہے (IPv6 کے لیے ایک ہی /64)۔ اگر کوئی پبلک IP واپس ہی نہ آئے تو اس کا مطلب صرف یہ ہے کہ اس ٹیسٹ کو جواب نہیں ملا؛ یہ محفوظ ہونے کا ثبوت نہیں۔

مشتبہ لیکWebRTC نے ایک مختلف پبلک IP واپس کیا، اور اس کا مقام، آپریٹر یا ASN آپ کے اصل مقامی نیٹ ورک کی طرف اشارہ کرتا ہے۔

معمول کی قواعد پر مبنی روٹنگمتعدد STUN سرورز نے مختلف پراکسی ایگزٹ واپس کیے، لیکن یہ ایگزٹ آپ کی ترتیب دی گئی لائنوں یا روٹنگ کے قواعد کی توقع کے مطابق ہیں۔

لیک ملنے کے بعد کیا کریں

اپنے پراکسی کلائنٹ کو TUN موڈ پر منتقل کریں تاکہ WebRTC کا UDP بھی پراکسی ایگزٹ سے گزرے۔
Chrome / Edge: کاروباری (enterprise) پالیسی <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code> سیٹ کریں؛ Firefox: <code>about:config</code> میں <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code> آن کریں۔ WebRTC کو مکمل طور پر نہ ہٹائیں، کیونکہ WebRTC کے بغیر براؤزر بذات خود قابل شناخت ہوتا ہے۔
Brave: WebRTC IP ہینڈلنگ پالیسی کو “Disable non-proxied UDP” پر سیٹ کریں۔
جب کانفرنسنگ یا وائس کالز کی ضرورت ہو تو پہلے اپنے پراکسی کلائنٹ میں UDP / STUN کے روٹنگ کے قواعد درست کریں۔

متعدد ایگزٹ IPs کا مطلب لازماً لیک نہیں

اگر آپ نے قواعد پر مبنی روٹنگ ترتیب دی ہے تو مختلف STUN سرورز مختلف نوڈز سے گزر سکتے ہیں — مثلاً Google کا STUN امریکی ایگزٹ سے اور Cloudflare کا STUN ہانگ کانگ کے ایگزٹ سے۔ یہ لازماً خطرناک نہیں؛ اہم یہ ہے کہ یہ آپ کے قواعد کے مطابق ہے یا نہیں۔ اصل میں جس بات پر نظر رکھنی ہے وہ یہ ہے کہ کہیں تمام WebRTC ایڈریسز آپ کے اصل جغرافیائی مقام یا مقامی ISP کی طرف اشارہ تو نہیں کرتے۔

DNS لیکس بھی اتنے ہی اہم ہیں

WebRTC لیک “آپ کا اصل IP” ظاہر کرتا ہے؛ DNS لیک یہ ظاہر کرتا ہے کہ “آپ نے کون سے ڈومینز تلاش کیے”۔ اگر DNS درخواستیں پراکسی سے نہیں گزرتیں تو آپ کا مقامی آپریٹر یا اپ اسٹریم ریزالور پھر بھی دیکھ سکتا ہے کہ آپ نے کون سی سائٹس کھولیں۔

اس صفحے کی DNS لیک جانچ ایک حقیقی پروب استعمال کرتی ہے: CleanIP.io یوٹاہ، امریکہ (ns1) اور لاس اینجلس، امریکہ (ns2) میں ایک ایک مستند NS چلاتا ہے جو dp.cleanip.io زون فراہم کرتے ہیں۔ ہر جانچ میں 8 الگ الگ <uuid>.dp.cleanip.io سب ڈومینز ریزالو کیے جاتے ہیں؛ یہ کوئریز آپ کے سسٹم کے stub ریزالور سے ISP / VPN / پبلک ریکرسیو ریزالور تک جاتی ہیں اور آخرکار ہمارے مستند NS تک پہنچتی ہیں، جو کوئری کرنے والے ریزالور کا IP اور (اگر موجود ہو) EDNS Client Subnet یعنی کلائنٹ کا سب نیٹ ریکارڈ کرتا ہے، پھر موازنے کے لیے آپ کو واپس بھیج دیتا ہے۔

دو سگنلز پر توجہ دیں: ① ECS سب نیٹ — اگر ریکرسیو ریزالور نے آپ کا کلائنٹ سب نیٹ آگے بھیج دیا ہو (Google 8.8.8.8 میں یہ عام ہے)، تو وہ سب نیٹ آپ کی کلائنٹ شناخت کا حتمی ثبوت ہے؛ ② ریزالور کا ملک — پبلک ریکرسیو ریزالورز (1.1.1.1 / 8.8.8.8) کے لیے سرحد پار اینی کاسٹ معمول کی بات ہے؛ اہم یہ ہے کہ جب آپ سمجھتے ہیں کہ VPN آن ہے تو کیا ریزالور کا مقام آپ کے HTTP ایگزٹ والے ملک سے میل کھاتا ہے۔

پراکسی موڈ اور TUN موڈ کے نتائج مختلف کیوں ہوتے ہیں

HTTP / SOCKS پراکسیز عموماً صرف TCP سنبھالتی ہیں، اس لیے STUN کے لیے درکار UDP شاید بھیجا ہی نہ جا سکے، اور صفحہ “کوئی لیک نہیں” دکھا سکتا ہے۔ اس کا مطلب یہ نہیں کہ UDP محفوظ طریقے سے پراکسی سے گزر رہا ہے — بلکہ صرف یہ کہ UDP کبھی STUN سرور تک پہنچا ہی نہیں۔ TUN موڈ ورچوئل نیٹ ورک اڈاپٹر پر TCP اور UDP دونوں کو سنبھالتا ہے، اس لیے یہ UDP کے اصل ایگزٹ راستے کی بہتر عکاسی کرتا ہے۔

موڈSTUN UDPنتیجے کا مطلب

HTTP / SOCKS پراکسیشاید بھیجا نہ جا سکے“کوئی لیک نہیں” کا مطلب صرف یہ ہو سکتا ہے کہ UDP بلاک تھا

TUN / ورچوئل اڈاپٹرواقعی بھیجا جا سکتا ہےUDP ایگزٹ اور روٹنگ کے قواعد کی تصدیق کے لیے زیادہ موزوں

ہمارا مشورہ ہے کہ اسی نیٹ ورک موڈ میں دوبارہ ٹیسٹ کریں جو آپ واقعی استعمال کرتے ہیں: اگر آپ عام طور پر TUN استعمال کرتے ہیں تو TUN کے ساتھ ٹیسٹ کریں؛ اگر آپ براؤزر پراکسی پر انحصار کرتے ہیں تو یہ بھی یقینی بنائیں کہ بلاک شدہ UDP کو غلطی سے محفوظ نہ سمجھ لیا جائے۔ WebRTC لیک کا فیصلہ کرتے وقت واپس آنے والے IP کے ASN، مقام اور اس بات پر توجہ دیں کہ کیا یہ آپ کی روٹنگ کی توقعات کے مطابق ہے۔