VPN پتہ اور LAN DHCP کرایہ: سرنگ کا IP کون دیتا ہے؟
آپ کا VPN کلائنٹ ایسا پتہ دکھاتا ہے جو LAN کرایہ فائل میں کبھی نہیں آتا۔ اصل تقسیم کرنے والا تلاش کرنے کے لیے کلائنٹ، IKEv2 پے لوڈ اور گیٹ وے پول پڑھیں۔
کلائنٹ جوڑیں اور Wi-Fi آئیکن کی بجائے اڈاپٹر دیکھیں۔ 10.80.0.14 جیسا پتہ سرنگ پر ہو سکتا ہے جبکہ دفتر کے LAN میں کسی DHCP سرور نے وہ کرایہ کبھی درج نہیں کیا۔ کس عمل نے نمبر چنا، یہی طے کرتا ہے کہ مسئلے کی جانچ کہاں سے شروع ہوگی۔
کلائنٹ پر سب کچھ یکساں لگتا ہے: ایک IPv4 پتہ، ایک ماسک، کبھی کبھار ڈیفالٹ گیٹ وے۔ فرق صرف تب ظاہر ہوتا ہے جب آپ پوچھیں کہ اس پتے کا جواب کون دیتا ہے اور اس کا ریکارڈ کون رکھتا ہے۔
کلائنٹ کی طرف سے سرنگ کا پتہ پڑھیں
اگر آپ پہلی سطر کی بجائے پورا بلاک پڑھیں تو Windows فرق دکھاتا ہے۔ ipconfig /all اڈاپٹر کی تفصیل، طبعی پتہ اور DHCP کی سطر چھاپتا ہے۔ PPP یا IKEv2 ڈائل اپ اڈاپٹر عام طور پر DHCP کو غیر فعال بتاتا ہے، کیونکہ کنکشن نے اپنا پتہ ڈائل کے دوران طے کیا تھا، LAN سرور سے کرائے پر لینے کی بجائے۔ DHCP فعال والا سرنگ اڈاپٹر غیر معمولی ہے اور الگ جانچ کے قابل ہے۔
Linux وہی معلومات دو اوزاروں میں تقسیم کرتا ہے۔ ip -4 addr show dev tun0 پتہ اور سابقہ کی لمبائی دیتا ہے۔ nmcli -f IP4 connection show work ظاہر کرتا ہے کہ قدر کنکشن پروفائل سے آئی، لنک پر DHCP تبادلے سے، یا دھکیلے گئے کنفیگریشن سے۔ WireGuard سب سے واضح صورت ہے، کیونکہ انٹرفیس نمودار ہونے پر wg-quick کنفگ فائل کی Address سطر لاگو کرتا ہے اور جڑنے کے وقت کوئی پیر کچھ تقسیم نہیں کرتا۔
سابقہ بھی کچھ کہتا ہے۔ /32، یا 255.255.255.255 کا ماسک، یعنی گیٹ وے ایک ہی ہوسٹ پتے کی طرف راستہ بنانے کی توقع رکھتا ہے، جبکہ وسیع تر ماسک سرنگ کے پیچھے کہیں آن لنک ذیلی نیٹ کا اشارہ دیتا ہے۔
IKEv2 کنفیگریشن پے لوڈ کیا اٹھاتا ہے
اس کام کے لیے IKEv2 کے پاس مخصوص طریقہ کار ہے۔ RFC 7296، حصہ 3.15.1 میں بیان کردہ کنفیگریشن پے لوڈ INTERNAL_IP4_ADDRESS، INTERNAL_IP4_NETMASK، INTERNAL_IP4_DNS اور ان کے IPv6 ہم منصبوں جیسی خصوصیات اٹھاتا ہے۔ ترجیح نہ ہونے پر کلائنٹ صفر لمبائی کی قدر والی خصوصیت بھیجتا ہے، اور جواب دینے والا وہ قدر واپس کرتا ہے جو وہ استعمال کرانا چاہتا ہے۔ یہ تبادلہ پہلے ہی خفیہ کردہ IKE_AUTH کے اندر چلتا ہے، اس لیے کوئی DHCP نشریات سرنگ عبور نہیں کرتیں۔
اس کے دو نتائج ہیں۔ پہلا، پتہ جواب دینے والا یا وہ کسی بھی اجازت دینے والے بیک اینڈ سے مشورہ کرتا ہے، اسی لیے پول گیٹ وے پر، RADIUS جواب میں یا شناخت فراہم کنندہ کی میپنگ میں رہ سکتا ہے۔ دوسرا، DNS خصوصیت پتے کی خصوصیت سے الگ ہے۔ 10.80.0.14 ملنے سے یہ کچھ پتہ نہیں چلتا کہ کون سا حل کنندہ واپس آیا، یا آیا بھی یا نہیں۔
نیٹ ماسک خصوصیت عملاً اختیاری ہے۔ بہت سی تنصیبات صرف پتہ واپس دیتی ہیں اور کلائنٹ کو ہوسٹ راستہ لگانے دیتی ہیں، اسی لیے ایک ہی پول ایک کلائنٹ پر /32 اور دوسرے پر /24 لگ سکتا ہے۔
جہاں LAN DHCP دائرہ اور VPN پول ٹکراتے ہیں
مسئلہ تب شروع ہوتا ہے جب دونوں تقسیم کرنے والے ایک ہی حدود کی طرف اشارہ کریں۔ 10.20.30.0/24 کے لیے DHCP سرور 10.20.30.128/25 کے لیے ترتیب دیے گئے VPN پول کے بارے میں کچھ نہیں جانتا، اس لیے گیٹ وے کے اسی پتے کو دور دراز کلائنٹ کو دینے کے دوران اسے 10.20.30.140 کسی پرنٹر کو کرائے پر دینے سے کوئی نہیں روکتا۔ ٹکراؤ کئی دن خاموش رہتا ہے اور پھر وقفے وقفے سے آنے والی نقل کے طور پر سامنے آتا ہے۔
روٹ شدہ سائٹ تا سائٹ ڈیزائن اپنی ساخت ہی سے ٹکراؤ سے بچتا ہے۔ شاخ کا ہوسٹ وہ پتہ رکھتا ہے جو اسے مقامی DHCP سرور نے دیا۔ دونوں گیٹ ویز کے سرنگ انٹرفیس اپنے اپنے لنک پتے رکھتے ہیں، اور پیکٹ کیسے سفر کریں گے یہ روٹنگ جدول طے کرتا ہے۔ دور دراز رسائی کلائنٹس کے پتے تیسری قسم ہیں اور انہیں گیٹ وے کے لنک پتوں میں نہیں ملانا چاہیے۔
سرنگ کو LAN پر پل باندھنا وہ علیحدگی ختم کرتا ہے۔ اگر ڈیزائن کو واقعی ایک نشریاتی ڈومین درکار ہو، تو VPN اختتامی نقطہ کو خود پتے جاری کرنے کی بجائے ریلے یا مشترکہ مستند ذریعے کے توسط سے DHCP سرور جیسے ہی تقسیم کے فیصلوں میں شریک ہونا چاہیے۔
حدود بدلنے سے پہلے ملکیت ثابت کریں
حدود بدلنے سے پہلے ملکیت ثابت کریں۔ کلائنٹ پر پتہ اور سابقہ لکھیں۔ LAN پر کرایہ ڈیٹا بیس میں تلاش کریں۔ گیٹ وے پر وہ پول درج کریں جو اسے دینے کے لیے ترتیب دیے گئے ہیں۔ کرایہ فائل میں ملا پتہ DHCP سرور کا ہوتا ہے، یعنی سرنگ پل بندھی ہوئی یا ریلے شدہ ہے؛ صرف گیٹ وے پول میں ملا پتہ سرنگ کے اختتامی نقطے کا ہوتا ہے۔
# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0
# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases
# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools
جواب واضح ہونے پر چار چیزیں لکھیں: کون سا جزو کلائنٹ کا پتہ تقسیم کرتا ہے، اس کے لیے کون سی حدود محفوظ ہے، واپسی ٹریفک ان حدود تک کیسے پہنچتی ہے، اور کون سے وسائل اسے قبول کرتے ہیں۔ یہ چار اندراجات ورچوئل اڈاپٹر کی ایک سطر کو عملی حقیقت بنا دیتی ہیں۔
وہیں رہتے ہوئے DNS خصوصیت کے لیے جانچ دہرائیں۔ جو پول پتے دیتا ہے مگر حل کنندہ نہیں، وہ کلائنٹ کو اس کے مقامی DNS پر چھوڑ دیتا ہے، جو LAN کے پہلے سے استعمال شدہ پتے کو دینے والے پول سے مختلف ناکامی ہے۔