OpenVPN کلید بنانے کے لیے آپ کو عارضی فائل کی ضرورت نہیں

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

فائل کبھی وہ افشا نہیں تھی جو آپ نے سوچا تھا

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

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

جب فائل کا نام نہ دیا جائے تو کلائنٹ کیا لکھتا ہے

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

import subprocess
proc = subprocess.run(
    ["openvpn", "--genkey", "tls-crypt"],
    stdout=subprocess.PIPE,
    stderr=subprocess.PIPE,
    check=True,
)
key_material = proc.stdout

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

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

دو بہاؤ، دو معنی

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

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

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

اگر آپ پھر بھی اسے محفوظ رکھیں تو سچیت طور پر کریں

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

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

مشترکہ کلید کوئی شناخت نہیں

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

کلید کی اقسام بھی ایک دوسرے کے بدل نہیں لگ سکتیں۔ ایک خصوصیت کے لیے سمانی کلید دوسری کے لیے تیار متبادل نہیں، اور نئے ورژن ہر سرے پر مختلف فائلوں کے ساتھ اپنی اقسام شامل کرتے ہیں۔ وہ قسم بنائیں جس کا نام آپ کی ترتیب واقعی لیتی ہے، پھر اسے اس کردار میں استعمال کریں جو وہ قسم متعین کرتی ہے۔

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