OpenVPN میں روٹ کہاں ہونا چاہیے: کلائنٹ میں یا سرور میں؟
سرور کنفگ میں ننگا روٹ سرور کو بدلتا ہے، کلائنٹ کو نہیں۔ کلائنٹ فائل، عالمی push یا ایک کلائنٹ کے لیے push منتخب کریں اور دیکھیں کہ کیا پہنچا۔
آپ سرور کنفیگریشن میں route 10.60.0.0 255.255.255.0 شامل کرتے ہیں، دوبارہ شروع کرتے ہیں، لیپ ٹاپ کو دوبارہ جوڑتے ہیں، اور اس لیپ ٹاپ سے ذیلی نیٹ اب بھی ناقابل رسائی ہے۔ سطر قبول ہو گئی، سروس صاف شروع ہوئی، اور لاگ میں کچھ بھی غلط نہیں لگتا۔ جو ہوا وہ یہ ہے کہ روٹ اسی مشین پر نصب ہوا جسے آپ نے ترمیم کیا: گیٹ وے اب سمجھتا ہے کہ وہ اس سابقے تک پہنچ سکتا ہے، جبکہ کلائنٹ کو کچھ نہیں بتایا گیا۔ جگہ ہی پورا سوال ہے، اور چار جگہیں ہیں جہاں وہی سطر رہ سکتی ہے۔
چار جگہیں اور ہر ایک کس کو ملتی ہے
روٹ کلائنٹ کی اپنی کنفیگریشن سے شامل کیا جا سکتا ہے، عالمی push کے ذریعے ہر کلائنٹ کو پیش کیا جا سکتا ہے، کلائنٹ کے لیے مخصوص فائل کے ذریعے ایک کلائنٹ کو پیش کیا جا سکتا ہے، یا سرور کے اپنے روٹنگ سیاق میں لکھا جا سکتا ہے۔
یہ چاروں صورتیں تقریباً ایک جیسا نحو استعمال کرتی ہیں اور بالکل مختلف نتائج دیتی ہیں۔ پہلی تین اس بات پر اثر انداز ہوتی ہیں کہ کلائنٹ سرنگ میں کیا بھیجتا ہے؛ چوتھی اس پر کہ سرور کسی نیٹ ورک تک کیسے پہنچتا ہے، جو اس وقت مفید ہے جب سرور کو خود راستہ درکار ہو اور اس وقت نقصان دہ جب اسے تقسیم سمجھ لیا جائے۔
سطر لکھنے سے پہلے طے کریں کہ چاروں میں سے کون سا چاہیے، پھر وصول کنندہ کی تصدیق کریں۔
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
ننگا سرور روٹ لوگوں کو کیوں حیران کرتا ہے
سرور کنفیگریشن وہ جگہ ہے جہاں منتظمین سب سے پہلے دیکھتے ہیں، اور وہاں کی روٹ ہدایت VPN نیٹ ورک کے بارے میں ایک بیان کی طرح پڑھی جاتی ہے۔ ایسا نہیں ہے۔ OpenVPN اسے ڈیمون چلنے والی مشین پر مقامی روٹ کی تنصیب سمجھتا ہے، جو بالکل اسی قسم کی تبدیلی ہے جو آپ ip route سے کرتے اور پھر بھول جاتے۔
تقسیم کے لیے ضروری ہے کہ روٹ push کیا جائے، اور push کے لیے ضروری ہے کہ کلائنٹ اسے کھینچے۔ کھینچے گئے اختیارات بند کر کے شروع کیا گیا کلائنٹ پیشکش کو مکمل نظر انداز کرتا ہے۔ سرور فائل دوبارہ لکھنے سے پہلے اس مصافحے کے دونوں سرے جانچیں، کیونکہ سرور کا لاگ شکایت نہیں کرے گا: اس کی طرف سے پیشکش بھیج دی گئی تھی۔ قبول شدہ روٹ بھی صرف اگلی کنکشن پر نافذ ہوتا ہے، کبھی اس سیشن میں نہیں جس میں آپ پہلے سے ہیں۔
جب آپ دونوں کو الگ الگ کارروائیاں سمجھتے ہیں، تو ناکامی پراسرار رہنا چھوڑ دیتی ہے: سرور سابقے تک پہنچتا ہے، کلائنٹ نہیں پہنچ سکتا، اور دونوں بیانات بیک وقت درست ہیں۔
فی کلائنٹ فائلیں اور وہ شناخت جس سے وہ ملتی ہیں
کلائنٹ کے لیے مخصوص فائل کا نام اس شناخت پر رکھا جاتا ہے جس کی سرور نے تصدیق کی، جو بطور ڈیفالٹ سرٹیفکیٹ کا عام نام ہے۔ ڈیسک ٹاپ کلائنٹ میں دوستانہ کنکشن نام وہ قدر نہیں ہے، اور عدم مطابقت ایسی فائل بناتی ہے جو کبھی نہیں پڑھی جاتی۔
وہ ڈائریکٹری جانچیں جو سرور واقعی استعمال کرتا ہے، پھر تصدیق کریں کہ فائل کا نام تصدیق شدہ شناخت سے بالکل مطابقت رکھتا ہے، بشمول بڑے اور چھوٹے حروف۔
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/اس فائل کے اندر بھی روٹ push کرنا ضروری ہے، کیونکہ فی کلائنٹ سیاق اس کلائنٹ کے سیشن پر لاگو اختیارات کا مجموعہ ہے، مقامی روٹنگ ٹیبل نہیں۔ وہاں کا ننگا روٹ عالمی فائل کے ننگے روٹ جیسا ہی مسئلہ رکھتا ہے۔
کلائنٹ کی اپنی فائل اور اس کی مالک اوزار
کلائنٹ کی کنفیگ میں رکھا گیا روٹ اس کلائنٹ کے جڑنے پر نصب ہوتا ہے اور منقطع ہونے پر ہٹایا جاتا ہے، جو مستقل منزل کے لیے درست زندگی کا چکر ہے۔
اگر نیٹ ورک مینیجر پروفائل کا مالک ہے، تو وہ ان اختیارات کو ایک بار درآمد کر کے پھر اپنی نقل رکھ سکتا ہے۔ بعد میں ڈاؤن لوڈ کی گئی فائل میں ترمیم کرنے سے کچھ نہیں بدلتا، جو "روٹ موجود ہے مگر لاگو نہیں ہوتا" کی عام وجہ ہے۔
آپ نے جو فائل ڈاؤن لوڈ کی اس کے بجائے فعال پروفائل جانچیں، اور مینیجر کی دکھائی گئی درآمد شدہ ترتیبات جانچیں۔ پھر جڑیں اور نظام سے پوچھیں کہ کوئی مخصوص پتہ کون سا راستہ استعمال کرتا ہے، بجائے یہ ماننے کے کہ سرنگ جیت گئی کیونکہ روٹ کسی متنی فائل میں تھا۔
کلائنٹ پر تصدیق کریں، پھر واپسی راستہ جانچیں
منزل کے بارے میں کلائنٹ کے اپنے روٹنگ ٹیبل سے پوچھیں، سرور کے سے نہیں۔ سابقے کے اندر ایک میزبان کی تلاش ہی یہ دکھانے کے لیے کافی ہے کہ کون سا انٹرفیس اور اگلا قدم استعمال ہوگا۔
ip route get 10.60.0.10اگر تلاش سرنگ کی طرف اشارہ کرتی ہے تو تقسیم کام کر گئی اور باقی مسئلہ کہیں اور ہے۔ اگر یہ ڈیفالٹ گیٹ وے کی طرف اشارہ کرتی ہے، تو روٹ نصب نہیں ہوا، کلائنٹ کی طرف کے اختیار نے فلٹر کر دیا، یا ایسے پروفائل کا ہے جسے کلائنٹ استعمال نہیں کرتا۔
فرض کریں تقسیم کام کر گئی اور پھر بھی کچھ جواب نہیں دیتا: تب گیٹ وے پر فارورڈنگ، دوسری طرف کا واپسی روٹ، اور ان کے درمیان کوئی بھی فائر وال جانچیں۔ روٹ راستہ چنتا ہے، یہ رسائی نہیں دیتا۔