کیا ہر OpenVPN پیر کو remote لائن کی ضرورت ہے؟ بالکل نہیں
remote بتاتا ہے کہ پہلا پیکٹ کہاں جاتا ہے؛ یہ کلائنٹ، سرور یا TLS کا کردار نہیں چنتا۔ دونوں اطراف میں نقل کرنے سے پہلے ترتیب پڑھیں۔
دو پیر کنفیگریشنوں کا ساتھ ساتھ موازنہ کیا جاتا ہے، ایک میں remote لائن ہے اور دوسری میں نہیں، اور نتیجہ یہ ہے کہ ان میں سے ایک خراب ہے۔ یہ اندازہ تجزیے کے قابل حد تک اکثر غلط ہوتا ہے۔ ہدایت بیان کرتی ہے کہ پہلا پیکٹ کہاں بھیجنا چاہیے۔ یہ نہیں چنتی کہ عمل شروع کرنے والے کلائنٹ یا انتظار کرنے والے گیٹ وے کے طور پر کام کرتا ہے، اور یہ بھی طے نہیں کرتی کہ کون سا فریق دوسرے کے سامنے اپنی شناخت ثابت کرتا ہے۔
remote دراصل کیا متعین کرتا ہے
remote اندراج ایک میزبان، اختیاری طور پر پورٹ اور ٹرانسپورٹ، اور اختیاری طور پر ایسی کئی اندراجات کا نام دیتا ہے جنہیں ترتیب سے آزمایا جاتا ہے۔
اس کی عدم موجودگی کا مطلب غیر متعین نہیں بلکہ متعین ہے: عمل انتظار کرتا ہے اور کسی پتے سے آنے والے پیکٹوں پر کارروائی نہیں کرتا جب تک وہ پیر تصدیق نہ کرے۔ اس لیے گھومنے پھرنے والے صارفین کی خدمت کرنے والے گیٹ وے کو ان میں سے کسی کا نام پہلے سے لینے کی کوئی وجہ نہیں۔
اندراج کو پتے کے تعلق کے طور پر پڑھیں۔ دور کا سرا قابلِ اعتماد ہے یا نہیں، اس کا جواب سرٹیفکیٹ اور توثیق کے اختیارات دیتے ہیں، پتہ لکھا جانا نہیں۔
تین ترتیبیں جواب کا تعین کرتی ہیں
گھومنے پھرنے والے کلائنٹ کو منزل درکار ہے، کیونکہ اسے آغاز کرنا ہے اور اس کے بغیر اسے معلوم نہیں کہ گیٹ وے کہاں ہے۔ کثیر کلائنٹ گیٹ وے کو فی صارف منزل کی ضرورت نہیں، کیونکہ کلائنٹ آتے ہیں اور تصدیق کرتے ہیں۔ جانے پہچانے سروں والے جان بوجھ کر بنائے گئے دو پیر رابطے میں ایک طرف، دونوں طرف یا کسی بھی طرف منزل ہو سکتی ہے، یہ اس پر منحصر ہے کہ کون سا فریق آغاز کرتا ہے۔
عام گیٹ وے میں مستقل کلائنٹ پتہ چپکانا وہ غلطی ہے جو ان اقسام کو نظر انداز کرنے سے آتی ہے۔ یہ صرف اس ایک پیر کے لیے کام کرتی ہے جس کا پتہ درج تھا اور باقی سب کو گمراہ کرتی ہے۔
ہدایت میں کوئی چیز کنفیگریشن کو کثیر کلائنٹ سرور نہیں بناتی، اور اس کی موجودگی میں کوئی چیز سرور کے کردار کو نہیں روکتی۔ OpenVPN 2.6 حوالہ اختیاری دلائل اور remote کے بغیر رویے کو الگ الگ درج کرتا ہے، جو اس بات کا اشارہ ہے کہ وہ کتنے آزاد ہیں۔
| Arrangement | Needs a destination |
|---|---|
| Roaming client | Yes, which gateway to contact |
| Multi-client gateway | No, peers authenticate on arrival |
| Two known peers | Depends on which side initiates |
ٹرانسپورٹ کے کردار دوسرا محور ہیں
TCP میں ایک فریق انتظار کرتا ہے اور دوسرا کال کرتا ہے۔ یہ منزل سے الگ ہدایات ہیں، اور انہیں ملانا ایسا جوڑا بناتا ہے جس میں دونوں انتظار کرتے ہیں یا دونوں کال کرتے ہیں۔
TCP ماخذ فلٹر کا کردار بھی ہے، اسی لیے یہ سیدھا بیان غلط ہے کہ سرور میں کبھی remote نہیں ہو سکتا۔
UDP میں قائم کرنے کے لیے کوئی رابطہ نہیں، اس لیے دونوں سرے متعلقہ UDP ٹرانسپورٹ استعمال کرتے ہیں اور ہدایت صرف یہ بتاتی ہے کہ کہاں نشانہ لگانا ہے۔ تصدیق شدہ پیر کے پتے کی تبدیلیاں مزید اندراجات جوڑنے کے بجائے مخصوص رویے سے نمٹی جاتی ہیں۔ ٹرانسپورٹ کا درست ہونا اس بات کی پیش شرط ہے کہ منزل کا کوئی مطلب ہو، اور دونوں کو ملانا ایسی کنفیگریشنوں کو جنم دیتا ہے جو قابلِ اعتماد لگتی ہیں اور کبھی ہینڈ شیک مکمل نہیں کرتیں۔
remote کی عدم موجودگی کھلا دروازہ کیوں نہیں
منزل کے بغیر عمل بھی ان پیروں کی آمدورفت مسترد کرتا ہے جو تصدیق نہیں کرتے، اور لوگ جب غیر موجود لائن کو سب کے لیے کھلا سامع پڑھتے ہیں تو یہی حصہ چھوڑ دیتے ہیں۔
تصدیق اور منزل آزاد ہیں، اور اعتماد کے لیے پہلی ہی اہم ہے۔
الٹی غلطی زیادہ خطرناک ہے۔ مستقل ماخذ پتہ رسائی کنٹرول جیسا محسوس ہو سکتا ہے کیونکہ یہ مخصوص اور جانچنے میں آسان ہے، لیکن یہ اس بارے میں کچھ ثابت نہیں کرتا کہ دوسرے سرے پر کون ہے۔ سرٹیفکیٹ کی توثیق رکھیں، اور وہ شناختی جانچیں بھی رکھیں جو سرٹیفکیٹ کو اس کے کردار سے باندھتی ہیں۔ انہیں پتے کی مطابقت سے بدلنا حقیقی کنٹرول کو اس کے ظاہری روپ سے بدل دیتا ہے۔
لکھیں کہ کنفیگریشن کیا فرض کرتی ہے
ہر فریق کے لیے تین چیزیں درج کریں: پہلا پیکٹ پیر تک کیسے پہنچتا ہے، کون سا فریق ٹرانسپورٹ قبول کر سکتا ہے، اور ہر فریق دوسرے کے بارے میں کیا توثیق کرتا ہے۔
یہی مفروضے ڈیزائن ہیں۔ ہدایات صرف ان کی ہجے ہیں۔
اگر دونوں فائلیں مختلف ہیں تو یہ فرض کرنے کے بجائے کہ ایک غلط ہے، دیکھیں کہ آیا وہ مختلف مفروضے بیان کر رہی ہیں۔ ہم شکل فائلوں کا جوڑا کام کرنے والی سرنگ کے لیے نہ ضروری ہے نہ کافی، اور عدمِ تشاکل ہی اکثر وہ حصہ ہوتا ہے جو ٹوپولوجی کو کام کرنے دیتا ہے۔