VPN سرور کے پول فیلڈ سے شروع کریں، اسپریڈشیٹ سے نہیں۔ آپ وہاں جو لکھیں گے وہ بعد میں جڑنے والے ہر کلائنٹ کے لیے اندرونی پتہ جگہ بن جاتا ہے، اور اسے اُن LAN، اُن کے پیچھے کے روٹ شدہ سائٹس اور کلائنٹ کے گھر میں پہلے سے موجود کسی بھی پتے کے ساتھ مل کر رہنا ہوگا۔ پول محفوظ ہوتے ہی ایک کلائنٹ جوڑیں، کیونکہ وہی پہلا کنکشن بتاتا ہے کہ قدر عملاً کام کرتی ہے یا نہیں۔ وہاں سے رہنمائی باہر کی طرف بڑھتی ہے: کلائنٹ کو ملا پتہ، جواب کا راستہ، اور وہ ریکارڈ جو آپ پیچھے چھوڑتے ہیں۔

کسی بھی کلائنٹ کے جڑنے سے پہلے پول فیلڈ سے شروع کریں

ہر مصنوعات اسے مختلف انداز میں دکھاتی ہے، اس لیے وہ شے تلاش کریں جو واقعی پتے تفویض کرتی ہے۔ OpenVPN میں سرور کی طرف پول کی ہدایت ہے جو اگلا خالی پتہ دیتی ہے، IKEv2 گیٹ وے میں ہم منصب کی ترتیب سے بندھا پول حصہ ہے، اور WireGuard میں دونوں نہیں کیونکہ ہر ہم منصب اپنا پتہ اپنی ترتیب کی فائل میں رکھتا ہے۔ پول ہدایت اور فی ہم منصب پتہ قابل تبادلہ نہیں، اور غلط میں ترمیم باقی رہنمائی ضائع کر دیتی ہے۔

فیلڈ ملنے کے بعد پہلے سے موجود رینجز کی فہرست بنائیں: دفتر کا LAN، ہر روٹ شدہ سائٹ، کلاؤڈ VPC اور سروس میں باقی کوئی بھی پول۔ اوورلیپ کا فیصلہ سابقے کی حساب سے ہوتا ہے، اس سے نہیں کہ میزبان نمبر مانوس لگتے ہیں، اس لیے مجموعے کا موازنہ اُن ہر رینج سے کریں۔ 10.x جیسی دکھنے والی دو رینجیں بے ضرر ہیں جب اُن کے مجموعے ایک دوسرے کو نہ کاٹیں اور معاون واقعہ ہیں جب کاٹیں۔

پھر فیصلہ کریں کہ پتہ اس بات کا فعل ہے کہ کون جڑتا ہے یا کہ وہ کب جڑتے ہیں۔ متحرک تفویض وہ دیتی ہے جو خالی ہو، جبکہ شناخت کے مطابق تفویض ایک مقررہ پتہ کسی اسناد سے باندھتی ہے۔ انتخاب لکھ لیں، کیونکہ یہ بدلتا ہے کہ بعد میں دوبارہ جڑنا کیسا ہونا چاہیے۔

وہ پتہ پڑھیں جو کلائنٹ کو واقعی ملا

ایک کلائنٹ جوڑیں اور پول کے وعدے کے بجائے سرنگ کی رپورٹ پڑھیں۔ کلائنٹ کنکشن کی حالت میں اپنا اندرونی پتہ دکھاتا ہے، اور Linux پر انٹرفیس اسے براہ راست رکھتا ہے۔

اس پتے کا موازنہ اُس رینج سے کریں جو آپ نے محفوظ کی۔ اگر یہ رینج سے باہر ہے تو آپ اُس سے مختلف تفویض راستہ دیکھ رہے ہیں جس میں ترمیم کی تھی۔ سابقے کی لمبائی بھی جانچیں، کیونکہ /32 رکھنے والے کلائنٹ کا لنک پر کوئی ہم منصب نہیں ہوتا اور وہ ہر منزل اپنے طے شدہ راستے سے بھیجتا ہے۔

ip -4 addr show tun0
ip route get 192.168.50.20

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

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

سروس سے جواب کو واپس ٹریک کریں

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

ترجمہ بدل دیتا ہے کہ باقی نظام کیا دیکھتا ہے۔ جب ماخذ دوبارہ لکھا جاتا ہے، میزبان کے فائر وال اور ایپلیکیشن لاگ میں موجود پتہ ترجمہ شدہ ہوتا ہے، اس لیے پول کے پتے کے خلاف لکھا گیا قاعدہ کسی سے نہیں ملتا اور لاگ کی لائن کلائنٹ تک ٹریس نہیں ہو سکتی۔ strongSwan کی آگے بھیجنے کی دستاویز IKEv2 گیٹ وے کے لیے اُس راستے کا سرور کی طرف کا آدھا حصہ ڈھانپتی ہے۔ DNS بھی وہی پابندی رکھتا ہے، کیونکہ ایسے پتے کی طرف حل ہونے والا نام جہاں کلائنٹ نہیں پہنچ سکتا بعد میں اور کہیں اور ناکام ہوتا ہے۔

دو کلائنٹ، پھر ایک منسوخی

ایک ہی وقت میں دو کلائنٹ جوڑیں اور دونوں پتے پڑھیں۔ وہ مختلف، قابل استعمال اور پول کے اندر ہونے چاہئیں، اور ہر ایک کو وہی سروس ملنی چاہیے جس کے لیے وہ ہے۔ نقل شدہ پتے دینے والا پول عام طور پر یہاں ظاہر ہوتا ہے، پہلے واحد کلائنٹ کے امتحان میں نہیں۔

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

ایسی منزل پر ختم کریں جسے انکار ہونا چاہیے۔ ہر جگہ پہنچنے والا کلائنٹ جوڑا گیا ہے، آزمایا نہیں گیا۔

چاروں قدریں وہیں لکھیں جہاں اگلی تبدیلی انہیں پائے گی

ریکارڈ مختصر ہے: پول رینج اور سابقہ، تفویض کا موڈ، واپسی راستہ یا زیرِ استعمال ترجمہ، اور وہ DNS دائرہ جو اُن منزلوں کے لیے جواب دیتا ہے۔ اسے ٹکٹ میں نہیں، سرور کی ترتیب کے پاس رکھیں اور تاریخ ڈالیں۔ بعد میں چاروں میں سے ایک بدلنے والے کو باقی تین سامنے چاہیے، کیونکہ پول کا حجم بدلنے سے راستہ ٹوٹتا ہے اور راستہ بدلنے سے DNS جواب ٹوٹتا ہے۔

اس کے ساتھ ملکیت کا نوٹ رکھیں: سرنگ کی رینج VPN سرور کی ہے، اور LAN کے DHCP دائرے میں کی گئی مختص سرنگ کے اندر کے کلائنٹ کے لیے کچھ مختص نہیں کرتی۔ وہی ایک سطر سب سے عام دوبارہ کام روکتی ہے، جہاں کوئی مختص کرتا ہے اور توقع کرتا ہے کہ سرنگ کا پتہ اس کی پیروی کرے گا۔

متعلقہ مضامین