بوٹ کے وقت OpenVPN ٹنل تیار ہونے سے پہلے RRAS شروع ہوتا ہے

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

ٹھنڈے بوٹ پر علامت کیسی دکھتی ہے

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

کچھ بھی بدلنے سے پہلے دونوں حالتوں کو ریکارڈ کریں: بوٹ پر RRAS کیا بتاتا ہے، اور جس لمحے ہاتھ سے دوبارہ آغاز کامیاب ہوتا ہے اُس وقت کیا موجود ہے۔ اگر یہ دونوں مشاہدات یکساں ہوں، تو آغاز کی ترتیب آپ کی وضاحت نہیں اور انحصار مدد نہیں کرے گا۔ یہ موازنہ دس منٹ لیتا ہے اور ایک ہفتے کا اندازہ بچاتا ہے۔

«دوبارہ آغاز کے بعد کام کرتا ہے» کی بنیاد پر شامل کیا گیا انحصار اُسی ناکامی کو صرف اُتنی دیر مؤخر کرتا ہے جتنا پیشگی سروس کو RUNNING بتانے میں لگتا ہے۔ یہ بوٹ کو سمجھنا بھی مشکل بناتا ہے، کیونکہ ترتیب کی قید اب وضاحت جیسی لگتی ہے۔ پوچھیں کہ انحصار کس چیز کی ضمانت دیتا ہے اور کیا وہی چیز ہے جو RRAS نہیں دیکھ سکا۔

وسیلے کا نام دیں، صرف سروس کا نہیں

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

یہ بھی طے کریں کہ یہ OpenVPN انسٹنس کیسے شروع ہوتا ہے۔ GUI کے زیرِ انتظام ٹنل اور سروس کے زیرِ انتظام ٹنل کے بوٹ لائف سائیکل مختلف ہیں، اور سروس کا نام آپ کے سامنے والی مشین سے آنا چاہیے، کسی دوسرے انسٹالر کے لیے لکھی مثال سے نہیں۔ یاد رکھے نام پر بھروسا کرنے کے بجائے امیدواروں کی فہرست بنائیں۔

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

شامل کرنے سے پہلے انحصار کی زنجیر پڑھیں

Service Control Manager START_PENDING اور RUNNING جیسی حالتیں بتاتا ہے، اور SERVICE_STATUS reference ہر فیلڈ کا مطلب بالکل متعین کرتا ہے۔ ان حالتوں میں سے کوئی بھی یہ وعدہ نہیں کرتی کہ ساتھی، DNS نام یا نچلی ایپلیکیشن قابلِ رسائی ہے۔ یہی خلا وہ پوری وجہ ہے کہ یہ ناکامی درست طور پر ترتیب دیے گئے انحصار کے باوجود برقرار رہتی ہے۔

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

sc.exe qc سے آنے والی DEPENDENCIES سطر وہ فہرست ہے جسے آپ کو محفوظ رکھنا ہے، کیونکہ sc.exe config RemoteAccess depend= پوری فہرست بدلتا ہے، اس میں اضافہ نہیں کرتا۔ VPN سروس شامل کرتے وقت غیر متعلق پیشگی شرط چھوڑ دینے سے دوسری خرابی پیدا ہوتی ہے جو کسی اور بوٹ پر ظاہر ہوتی ہے، اور اس کی تشخیص اصل سے کہیں زیادہ مشکل ہے۔ اسے چھونے سے پہلے موجودہ فہرست اپنے تبدیلی ریکارڈ میں نقل کریں۔

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

دوبارہ آغاز کو ٹائمر پر نہیں، شرط پر مشروط کریں

مقررہ انتظار فرض کرتا ہے کہ ٹنل ہمیشہ اُس ونڈو میں تیار ہوگا، اور یہی مفروضہ اُس بوٹ پر ناکام ہوتا ہے جہاں سرٹیفکیٹ سست ہو یا لنک ڈاؤن ہو۔ وسیلے کو ہی ایک مدت کے ساتھ جانچیں، اور فیصلہ جانچ کو کرنے دیں کہ دوبارہ آغاز درکار ہے یا نہیں۔

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-WinEvent -LogName System -MaxEvents 40 |
  Where-Object ProviderName -eq 'Service Control Manager'

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

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

منتقلی لاگ کریں تاکہ اگلا بوٹ خود کو سمجھا سکے

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

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