ایک ہی میزبان سے TCP اور UDP پر OpenVPN سروس دینا
2.7 سے پہلے ایک عمل صرف ایک ٹرانسپورٹ باندھتا ہے۔ پل سے جڑی TAP جوڑی، دو TUN ذیلی جال اور مشترکہ پول کا موازنہ کریں، پھر ہر پروفائل کو اس کے سننے والے سے ملائیں۔
وہ نیٹ ورک جو صرف TCP 443 کی اجازت دیتے ہیں، ایسے نیٹ ورک کے ساتھ ساتھ چلتے ہیں جو UDP کو بآسانی گزرنے دیتے ہیں، اور ایک سرور کو دونوں کی خدمت کرنی ہوتی ہے۔ proto udp والا پروفائل دوسرے گروہ کو جواب دیتا ہے اور پہلے پر ناکام ہوتا ہے، اور اسی کنفیگریشن کو proto tcp کہنے کے لیے بدلنے سے دوسرا سننے والا نہیں بنتا۔ یہ ہدایت ایک عمل کے لیے صرف ایک ٹرانسپورٹ چنتی ہے۔ باقی سب اسی پابندی سے نکلتا ہے۔
یا آپ ایک سے زیادہ عمل چلاتے ہیں، یا ایسا نسخہ چلاتے ہیں جو ایک وقت میں کئی ساکٹ باندھ سکے۔
2.7 سے پہلے ایک عمل صرف ایک ٹرانسپورٹ باندھتا ہے
کمیونٹی کا OpenVPN وہ ساکٹ باندھتا ہے جسے proto بیان کرتا ہے، اور یہ ہدایت مثال کے لیے ایک ہی ٹرانسپورٹ چنتی ہے۔ TCP اور UDP الگ اسٹیک ہیں، اس لیے ایک ہی پورٹ نمبر ایک ہی وقت میں دونوں لے سکتے ہیں، مگر ایک عمل نہیں۔ اسی لیے 2.6 سلسلہ آپ کو ہر ڈیمن کے لیے ایک ٹرانسپورٹ دیتا ہے۔ OpenVPN 2.7 نے سرورز کے لیے یہ پابندی ہٹا دی، جو ایک ہی عمل میں کئی --local بیانات کے ذریعے کئی ساکٹ باندھ سکتے ہیں۔
کسی بھی جواب کے گرد ڈیزائن کرنے سے پہلے نسخہ دیکھیں، کیونکہ 2.7 کی ترتیب اپنی کنفیگریشن نحو کے ساتھ الگ عملی نمونہ ہے۔ 2.6 کے لیے لکھی گائیڈ دو عمل بیان کرتی ہے، چاہے وہ ایسا نہ کہے۔
دو مثالیں چلانے کے تین طریقے
TAP انٹرفیس کے ساتھ، ہر ٹرانسپورٹ کے لیے ایک مثال چلائیں اور میزبان پر دو tap آلات کو پل سے جوڑیں۔ دونوں کلائنٹ گروہ ایک ہی براڈکاسٹ ڈومین میں آتے ہیں، جس سے ایک پتہ پول انہیں ڈھانپ سکتا ہے اور براڈکاسٹ پر منحصر پروٹوکول کام کرتے رہتے ہیں۔ TUN کے ساتھ پل دستیاب نہیں، اس لیے سادہ ترین تقسیم ہر مثال کو اپنا ذیلی جال دیتی ہے اور روٹنگ دونوں کلائنٹ گروہ الگ رکھتی ہے۔ تیسرا اختیار ایک ہی پول رکھتا ہے: ہر مثال learn-address اسکرپٹ کو بلاتی ہے جو اس مثال کے آلے سے کلائنٹ کے لیے /32 روٹ نصب کرتا ہے۔
وہی تیسری ترتیب وہ ہے جو لوگ مانگتے ہیں اور جسے سب سے زیادہ احتیاط چاہیے، کیونکہ اسکرپٹ ڈیٹا راستے کا حصہ بن جاتا ہے اور شامل کرنے، اپ ڈیٹ کرنے اور حذف کرنے کے واقعات کو درست طریقے سے سنبھالنا ہوتا ہے۔
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
دونوں مثالیں الگ رکھیں
ہر مثال کو الگ پورٹ یا پتہ، الگ حالت فائل اور الگ لاگ منزل بھی چاہیے۔ ایک ہی حالت فائل میں لکھنے والے دو ڈیمن ایسا آؤٹ پٹ بناتے ہیں جو واقعے کے وقت پڑھا نہیں جا سکتا، اور اسی وقت اس کی ضرورت ہوتی ہے۔ اگر دوسری مثال کوئی مخصوص پتہ باندھے، تو عمل شروع ہوتے وقت وہ پتہ میزبان پر موجود ہونا چاہیے؛ ورنہ چابیوں کے بارے میں کچھ کہنے سے پہلے ہی بائنڈ ناکامی کے ساتھ باہر نکل جاتا ہے۔
یونٹوں اور پروفائلز کے نام ایسے رکھیں کہ فائل نام سے ٹرانسپورٹ واضح ہو۔ اگلے آپریٹر کو یہ جاننے کے لیے کنفیگریشن کھولنے کی ضرورت نہ ہو کہ کون سا TCP ہے۔
پروفائل کو سننے والے سے ملائیں
proto tcp چلانے والا سرور proto tcp-client والے کلائنٹ پروفائل کی توقع کرتا ہے، اور اب بھی proto udp رکھنے والا پروفائل اس سننے والے کے سامنے ایسی غلطی کے بغیر وقت بڑھا کر رک جاتا ہے جس پر صارف کارروائی کر سکے۔ اگر تعیناتی دونوں ٹرانسپورٹ دیتی ہے تو دو پروفائل رکھیں، اور ایسے لیبل کریں کہ معاونت جان سکے کون سا آزمایا گیا۔ صرف پورٹ نمبر ٹرانسپورٹ بیان نہیں کرتا۔
فائر وال قواعد اسی تقسیم پر چلتے ہیں: UDP 1194 کا قاعدہ TCP 1194 کے بارے میں کچھ نہیں کہتا، اور ایک پتے کا قاعدہ دوسرے سننے والے کو نہیں ڈھانپتا۔
پہلے سرور کا منظر پڑھیں
سرور پر ss -lntup سے شروع کریں اور تصدیق کریں کہ TCP اور UDP دونوں سننے والے نظر آتے ہیں۔ پھر ہر قسم کا ایک کلائنٹ جوڑیں اور مختلف پتوں والی دو اندراجات کے لیے حالت کا آؤٹ پٹ دیکھیں۔ اگر ساکٹ موجود ہیں اور کوئی کلائنٹ نہیں آتا، تو ڈیمن کے دیکھنے سے پہلے راستہ یا فائر وال پیکٹ مسترد کر رہے ہیں۔
کبھی نظر نہ آنے والا ساکٹ کنفیگریشن یا بائنڈ کا مسئلہ ہے، اور نظر آ کر بھی کبھی کنکشن درج نہ کرنے والا ساکٹ فلٹرنگ کا مسئلہ ہے۔ کلائنٹ سے دونوں ایک جیسے لگتے ہیں، اسی لیے سرور کا اپنا منظر پہلے آتا ہے۔ یاد رکھیں کہ TCP میں قطار کے سر کی رکاوٹ ہوتی ہے، اس لیے اسے دینا صاف UDP راستے والے کلائنٹس کے لیے اپ گریڈ نہیں بلکہ رسائی کا اقدام ہے۔