NAT طے کرتا ہے کہ آپ کا VPN سرور واقعی کون سا ماخذ پتہ دیکھتا ہے

آپ تصور کرتے ہیں کہ VPN سرور آپ کے لیپ ٹاپ کا پتہ پیکٹ سے پڑھ کر لاگ میں لکھتا ہے۔ وہ جو پڑھتا ہے وہی ہے جو آخری NAT ہاپ نے بیرونی ہیڈر میں ڈالا، اور ہاٹ اسپاٹ کے طور پر استعمال ہونے والے فون پر یہ اکثر وہ پتہ ہوتا ہے جو سیکڑوں دیگر صارفین کے ساتھ مشترک ہوتا ہے۔ آپ کی مشین کا اپنا 192.168.x.x اس ہیڈر میں کبھی انٹرنیٹ عبور نہیں کرتا، اور ٹنل کا پتہ سرور اس وقت دیتا ہے جب کنکشن پہلے ہی قائم ہو چکا ہوتا ہے۔ اس لیے جب سرور کا لاگ اور لیپ ٹاپ پر ip addr میل نہیں کھاتے، تو کوئی بھی غلط نہیں؛ وہ ایک ہی سیشن کی مختلف تہوں کی وضاحت کرتے ہیں۔

تین پتے، اور لاگ میں صرف ایک

الجھن تین پتوں کو ایک میں سمیٹنے سے آتی ہے۔ ہر ایک کا الگ مالک ہے، وہ الگ ہیڈر میں رہتا ہے اور الگ راستے سے سرور تک پہنچتا ہے۔

کنیکٹ کرتے وقت صرف درمیانی سطر نامعلوم ہوتی ہے۔ سرور اسے ڈیمن کے مطابق اپنی پیئر جدول، حالت فائل یا فلو لاگ میں لکھتا ہے: WireGuard اسے اینڈ پوائنٹ کہتا ہے، OpenVPN کی حالت فائل اسے Real Address لکھتی ہے، اور strongSwan اسے IKE_SA کے دور دراز میزبان کے طور پر بتاتا ہے۔ وہ قدر ہر بار تازہ ہوتی ہے جب کسی اور ماخذ سے پیکٹ آتا ہے، اس لیے کوئی کچھ دوبارہ شروع کیے بغیر یہ بدل جاتی ہے۔

سب سے نیچے کی سطر وہ ہے جسے لوگ غلطی سے شناخت کا دعویٰ سمجھتے ہیں۔ یہ سرور کنفیگریشن میں ایک جگہ کی نشاندہی کرتی ہے، کسی شخص کی نہیں، کیونکہ سرور نے اسے اپنے ہی پول سے چنا۔ دو صارف مختلف دنوں میں ایک ہی ٹنل پتہ لے سکتے ہیں، اور ایک شخص دو آلات سے دو رکھ سکتا ہے۔

ٹنل کے قائم رہنے کے دوران لاگ شدہ ٹوپل کیوں بدلتا ہے

پتوں کا ترجمہ ٹائمر والی جدول ہے، مستقل بندھن نہیں۔ گھریلو راؤٹر آخری پیکٹ کے بعد کچھ دیر اپنا UDP میپنگ رکھتا ہے، آپریٹر کا گیٹ وے اپنے شیڈول کے مطابق پورٹ دوبارہ استعمال کرتا ہے، اور Wi-Fi سے LTE پر جانے والا فون بالکل مختلف ماخذ کے ساتھ واپس آتا ہے۔ یہاں Linux conntrack کی ڈیفالٹ قدریں مفید پیمانہ ہیں: nf_conntrack_udp_timeout 30 سیکنڈ ہے اور اسٹریمنگ شکل 120، اس لیے خاموش ٹنل صارف کے محسوس کرنے سے بہت پہلے اپنی میپنگ کھو سکتا ہے۔

ٹنل اس لیے زندہ رہتا ہے کہ پروٹوکول پتے کی نہیں، پیئر کی تصدیق کرتا ہے۔ ہینڈ شیک کے بعد WireGuard بے حالت ہے، اس لیے کوئی بھی تصدیق شدہ پیکٹ محفوظ اینڈ پوائنٹ کو اپ ڈیٹ کرتا ہے اور دوبارہ بندھن اگلے پیکٹ پر ٹھیک ہو جاتا ہے؛ persistent-keepalive = 25 اسی لیے ہے، بیکار وقت میں میپنگ کو گرم رکھنے کے لیے۔ OpenVPN کا --float بھی یہی کام کرتا ہے اور تصدیق شدہ کلائنٹ کو نئے پتے اور پورٹ سے جاری رکھنے دیتا ہے۔ 2.4 اور 2.5 بلڈز میں جہاں float ڈیفالٹ میں بند ہے، دوبارہ بندھن سیشن ری سیٹ کرتا ہے اور کلائنٹ دوبارہ جڑتا ہے۔

IPsec وہاں زیادہ حرکت پذیر حصوں کے ساتھ پہنچتا ہے۔ IKEv2 NAT شناخت پے لوڈز میں ماخذ اور منزل کے ہیش کا موازنہ کر کے ترجمہ پہچانتا ہے، UDP 4500 انکیپسولیشن پر جاتا ہے، اور keepalive کو نئے ٹوپل تک تعاقب کرتا ہے۔ جب keepalive بلاک ہوں تو SA کاغذ پر قائم رہتا ہے اور ایک سمت میں ٹریفک خاموشی سے رک جاتا ہے۔

سرور کیا منسوب کر سکتا ہے، اور کیا نہیں

مارنے کے قابل افسانہ یہ ہے کہ ترجمہ آپ کو آپریٹر سے چھپاتا ہے۔ یہ لیبل بدلتا ہے، مشاہدہ نہیں۔ آپریٹر کے NAT کے پیچھے گیٹ وے 100.64.0.0/10 جگہ یا ایک عوامی پتہ دیکھتا ہے جو بہت سے صارفین میں مشترک ہے، اور پھر بھی بہاؤ کو سرٹیفکیٹ کے موضوع، WireGuard عوامی کلید، مختص شدہ ٹنل پتے، بائٹ کاؤنٹرز اور وقت کی کھڑکی سے جوڑ سکتا ہے۔ ان میں سے کسی کو آپ کے LAN پتے کی ضرورت نہیں۔

حدود مخالف سمت میں بھی چلتی ہیں۔ لاگ میں مشترک پتہ گیٹ وے کی طرف اشارہ کرتا ہے، گھر کی طرف نہیں؛ ایک ہی ترجمہ شدہ پتے سے مختلف پورٹس پر دو سیشن مختلف آلات ہیں؛ پورٹ دوبارہ استعمال ہوا ہو تو دو مختلف دنوں میں ایک ہی پتہ دو غیر متعلق صارفین ہو سکتے ہیں۔ صرف پیئر کیز درج کرنے والا سرور اکاؤنٹ ڈیٹا بیس کے بغیر انہیں گاہک سے نہیں جوڑ سکتا، اور صرف پتے درج کرنے والا سرور ایک ہی راؤٹر کے پیچھے لیپ ٹاپ اور فون میں فرق نہیں کر سکتا۔

اندازہ لگانے کے بجائے دونوں سرے موازنہ کریں

یہ طے کرنے کے لیے کہ کیا ہوا، وہی کنکشن دونوں سروں پر ایک ہی لمحے میں کیپچر کریں اور پتے کا نہیں، ٹوپل کا موازنہ کریں۔ کلائنٹ پر، کسی بھی ترجمے سے پہلے:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

پھر راؤٹر یا CGNAT گیٹ وے پر ترجمے کا اندراج اور وہ پڑھیں جو بالآخر سرور تک پہنچتا ہے:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

تین نمونے زیادہ تر عدم مطابقت کی وضاحت کرتے ہیں۔ سرور پر ماخذ پورٹ مقامی پورٹ سے مختلف ہے جبکہ منزل میل کھاتی ہے: عام پورٹ ترجمہ۔ سرور پر ماخذ پتہ ایسے ISP بلاک کا ہے جو آپ کا نہیں: کم از کم ایک اضافی NAT تہہ۔ پیکٹ بیکار دورانیے کے بعد رک جاتے ہیں اور نئی پورٹ کے ساتھ چلتے ہیں: میپنگ کی مدت ختم ہو گئی، راؤٹنگ خرابی نہیں۔ اگر ٹائم اسٹیمپ ایک یا دو سیکنڈ سے زیادہ دور ہوں تو آپ دو مختلف کوششوں کا موازنہ کر رہے ہیں۔

فرق کہاں چیزیں توڑتا ہے

سرور کی خرابی جیسے دکھنے والے وقفے عام طور پر یہیں سے شروع ہوتے ہیں۔ آپ کے گھر کے پتے پر لگا رسائی قاعدہ ISP لیز بدلنے کے بعد ناکام ہو جاتا ہے۔ ترجمہ شدہ پتے سے ملنے والا fail2ban قاعدہ اس گیٹ وے کے پیچھے تمام صارفین کو ایک ساتھ بلاک کرتا ہے۔ مستقل دور دراز پتے والا سائٹ تا سائٹ پیئر موبائل لنک بدلنے کے بعد کیز کی تجدید بند کر دیتا ہے۔ ٹنل پروٹوکول درست تھا؛ بیرونی ٹوپل کا مفروضہ نہیں۔

یہی الجھن سرور کی طرف بھی نظر آتی ہے۔ اگر VPN باکس خود NAT کے پیچھے ہے تو پورٹ فارورڈنگ اور کام کرنے والا فارورڈنگ راستہ درکار ہے؛ strongSwan کی فارورڈنگ گائیڈ IPsec کے لیے اس صورت کو محیط ہے۔ صرف نجی پتے پر دستیاب سرور اپنے کلائنٹس کا پیش کردہ ترجمہ شدہ ٹوپل کبھی نہیں دیکھتا، اور یہ کلائنٹس کے ترجمے ہونے سے مختلف مسئلہ ہے۔

یہ چار جانچیں ترتیب سے کریں اور پہلی ناکامی پر رکیں:

• دونوں سروں پر ایک ہی وقت کیپچر کریں؛ تصدیق کریں کہ ماخذ پورٹ، منزل پورٹ اور ٹائم اسٹیمپ میل کھاتے ہیں۔
• آپ نے جس پتے کی توقع کی اسے نہیں، سرور اب جو پتہ رکھتا ہے اسے پیئر فہرست میں پڑھیں۔
• اندراج اور اس کی باقی عمر conntrack یا NAT جدول میں دیکھیں۔
• تصدیق کریں کہ کلائنٹ پر ٹنل انٹرفیس کا پتہ LAN پتے سے نہیں، سرور کے دیے گئے پتے سے میل کھاتا ہے۔

اگر دونوں کیپچر ٹوپل پر متفق ہوں اور ٹنل پھر بھی ناکام ہو، تو ترجمہ آپ کا مسئلہ نہیں؛ ہینڈ شیک اور ٹنل کے اندرونی راؤٹنگ جدول کی طرف بڑھیں۔