VPN کے پیچھے IoT سینسر رکھنے سے پہلے تین پتہ فیصلے
تین پتے تین کام کرتے ہیں: عوامی مرکز، تصدیق شدہ سائٹ کا ساتھی اور سینسر کا نجی پتہ۔ کچھ بھی عوامی تقسیم کرنے سے پہلے ہر ایک کی منصوبہ بندی کریں۔
ہر IoT-بذریعہ-VPN منصوبے میں تین پتے الجھ جاتے ہیں، اور وہ ایک ہی قسم کا فیصلہ نہیں ہیں۔ ایک یہ ہے کہ دور بیٹھا آپریٹر سرنگ کا آخری نقطہ کیسے ڈھونڈتا ہے، دوسرا یہ ہے کہ سائٹ کیسے ثابت کرتی ہے کہ وہی سائٹ ہے، اور تیسرا یہ ہے کہ سینسر کی خدمت واقعی کہاں سنتی ہے۔ انہیں اسی ترتیب سے جواب دیں اور ڈیزائن زیادہ تر خود ہی نکل آتا ہے۔ انہیں ایک ہی سوال کے طور پر جواب دیں اور آپ ایسے آلات کو عوامی پتے تقسیم کرنے تک پہنچ جائیں گے جنہیں کبھی اس کی ضرورت نہیں تھی۔ باہر جانے والی سائٹ سرنگ کے پیچھے بیٹھا سینسر سینسر کی طرف اشارہ کرنے والے کسی بھی اندر آنے والے قاعدے کے بغیر مجاز آپریٹر کے لیے قابل رسائی ہے۔
اس سے شروع کریں کہ کون شروع کرتا ہے
کون ڈائل کرتا ہے یہ باقی تقریباً سب کچھ طے کرتا ہے۔ جب سائٹ مرکز کی طرف ڈائل کرتی ہے، سائٹ کو کسی اندر آنے والی رسائی کی ضرورت نہیں ہوتی، اور مرکز کو ایسا نام یا پتہ چاہیے جو سائٹ حل کر سکے۔ یہ ایک انتخاب مستقل عوامی پتہ بندی کی بحث کا بڑا حصہ شروع ہونے سے پہلے ہی ہٹا دیتا ہے۔
پھر تین کردار صاف طور پر الگ ہو جاتے ہیں، اور نیچے دی گئی جدول فیصلے کی سب سے مختصر شکل ہے۔
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
ہر قطار کا الگ مالک ہے، اور یہی اصل بات ہے۔ مرکز اس کا ہے جو VPN خدمت چلاتا ہے، سائٹ کا ساتھی نیٹ ورک ٹیم کا، اور سینسر کا پتہ اس کا جو آلہ رکھتا ہے۔
مرکز کا پتہ آغاز ہے، منزل نہیں
عوامی پتے کی طرف حل ہونے والا نام مرکز کے لیے کافی ہے۔ DNS ریکارڈ آخری نقطہ کے منتقل ہونے پر اس کا پیچھا کر سکتا ہے، ہر سائٹ کنفیگریشن کو ہاتھ سے تبدیل کیے بغیر۔ DNS جو نہیں کرتا وہ رسائی پیدا کرنا یا پرانے جواب کو محفوظ رکھنے والے کلائنٹ کو تازہ کرنا ہے، اور یہ الگ مسائل ہیں الگ حلوں کے ساتھ۔
اگر آپ مرکز کے بغیر سائٹ سے سائٹ سرنگیں چلاتے ہیں، وہی منطق دوسری شکل میں لاگو ہوتی ہے: ایک طرف کو قابل رسائی آخری نقطہ چاہیے، یا دونوں طرف کسی تیسرے فریق کو ڈائل کرتے ہیں۔ کسی کو بہرحال اس پتے اور اس کی تجدید کا مالک ہونا پڑتا ہے۔
سائٹ کا ساتھی پیش لفظ کے ساتھ جڑی شناخت ہے
ساتھی پہلے شناخت ہے اور دوسرے پیش لفظ۔ WireGuard کی اصطلاحات میں ساتھی کلیدوں کا جوڑا رکھتا ہے اور مرکز کا AllowedIPs اندراج اس کلید کو سائٹ کے پیش لفظ سے باندھتا ہے۔ IKEv2 کی اصطلاحات میں سرٹیفکیٹ یا پہلے سے مشترکہ کلید سائٹ کی شناخت کرتی ہے اور اس کے ٹریفک منتخب کنندگان بتاتے ہیں کہ وہ کیا لے جا سکتا ہے۔ صرف ایک آدھا بدلنا ترتیب توڑ دیتا ہے، اسی لیے پتے کی تبدیلی کو کبھی شناخت کی تبدیلی نہیں سمجھا جانا چاہیے۔
کلید یا سرٹیفکیٹ کی ملکیت مرکز کے آپریٹر کے پاس نہیں بلکہ سائٹ کے پاس رکھیں، تاکہ فراہم کنندہ کی تبدیلی شناخت کی تبدیلی نہ بن جائے۔
پیش لفظ وہ حصہ ہے جس کی منصوبہ بندی لوگ بھول جاتے ہیں۔ مرکز کو سینسر کے ذیلی نیٹ کو درست ساتھی سے جوڑنا ہوتا ہے، اور آپریٹر کے کلائنٹ کو وہاں تک راستہ چاہیے؛ جو راستہ صرف کلائنٹ پر ہو وہ ٹریفک کو ایسی سرنگ میں بھیجتا ہے جو اسے خاموشی سے گرا دیتی ہے۔ کلید کے فنگر پرنٹ کے پاس سائٹ ریکارڈ میں پیش لفظ لکھیں، تاکہ تبدیل شدہ گیٹ وے بغیر کسی کے علم کے مختلف کوریج کے ساتھ نہ آ سکے۔
سینسر کا پتہ ایپلیکیشن کا ہے
سائٹ کے منصوبے سے نجی پتہ کافی ہے، اور اسے عوامی رسائی نہیں بلکہ استحکام چاہیے: DHCP ریزرویشن، مستقل تخصیص، یا سائٹ کے اپنے زون میں نام۔ اگر آلے کو دوبارہ شمار نہیں کیا جا سکتا، تو سائٹ گیٹ وے پر ترجمہ جائز جواب ہے، بشرطیکہ ترجمہ دستاویزی ہو اور واپسی کی ٹریفک اس کی پیروی کرے۔
ایک اور عادت جو رکھنے کے قابل ہے: سینسر کے ہوسٹ پر اگلے ہاپ کے خانے میں کبھی عوامی مرکز کا پتہ نہ چپکائیں۔ VPN اپنا راستہ نصب کرتا ہے، اور کسی عوامی آخری نقطے کے ساتھ عام ایتھرنیٹ ہمسائیگی ایک خیالی بات ہے جو قابل اعتماد دکھنے والی کنفیگریشن بناتی ہے۔
جواب وہ آدھا حصہ ہیں جو چھوڑ دیا جاتا ہے۔ آلے کو اپنا جواب سرنگ کی طرف واپس بھیجنا ہوتا ہے، یا آپریٹر کے کلائنٹ تک راستے سے یا اسی گیٹ وے سے جس نے درخواست کا ترجمہ کیا۔ غلط ڈیفالٹ گیٹ وے والا سینسر درخواست قبول کرتا ہے اور خالی جگہ میں جواب دیتا ہے، اور فارورڈنگ نوٹس بتاتے ہیں کہ آمد اور جواب کی روٹنگ ایک نہیں بلکہ دو ضرورتیں کیوں ہیں۔
فیصلہ کریں، پھر حد لکھیں
کوئی جڑنے سے پہلے رسائی کی حد لکھیں۔ گیٹ وے کو IoT حصے اور آپریٹر کو درکار مخصوص خدمات تک محدود رکھیں، کیونکہ کام کرنے والا راستہ حادثاتی طور پر عام رسائی بن جاتا ہے۔ صرف پڑھنے والی نگرانی اور کنفیگریشن کا اختیار الگ شناختوں والے الگ کرداروں کے طور پر رکھیں، اور معاہدہ ختم ہونے پر رسائی ہٹانے والے شخص کا نام لکھیں۔
منظوری نیٹ ورک کے مالک کی ہے، اور DMZ میں ہونا رسائی کی پالیسی نہیں ہے۔
تعیناتی کے بعد کا امتحان بورنگ اور فیصلہ کن ہے: اجازت یافتہ پیش لفظ کے اندر ایک درخواست جو کامیاب ہوتی ہے، گیٹ وے پر بڑھنے والا ایک کاؤنٹر، اور پیش لفظ سے باہر ایک دانستہ کوشش جو ناکام ہوتی ہے۔