Azure OpenVPN سرنگ ہر ساٹھ سیکنڈ میں تقریباً کیوں گرتی ہے

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

کسی بھی ٹائمر کو چھونے سے پہلے وہ سطر پڑھیں۔

افسانہ: راستے میں کوئی چیز سرنگ روک رہی ہے

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

تال ہی مفید سراغ ہے۔ ٹائمر اسے پیدا کرتے ہیں؛ پیکٹ کا ضائع ہونا شاذ و نادر۔

ٹائمر سے پہلے منقطع ہونے کی وجہ پڑھیں

OpenVPN اپنی وجہ کا نام دیتا ہے، اور ہر نام کسی مختلف ذیلی نظام کی طرف اشارہ کرتا ہے۔ Session invalidated: KEEPALIVE_TIMEOUT ختم ہوتا ٹائمر ہے، اس لیے دونوں سروں پر ping اور ping-restart کی قدریں موازنہ کریں۔ AUTH_FAILED اسناد یا سرٹیفکیٹ کی حالت ہے، اور کوئی ٹائمر تبدیلی مدد نہیں کرے گی۔ TLS غلطی کا مطلب ہے کہ دونوں فریق کبھی keepalive مرحلے تک نہیں پہنچے۔

کنکشن کا وقت، منقطع ہونے کا وقت اور یہ کہ وقفہ سیکنڈ تک مستحکم ہے یا نہیں، درج کریں۔ وہی ایک پیمائش مقررہ شیڈول کو اتفاق سے الگ کرتی ہے۔

مستحکم وقفہ ٹائمر ہے۔ سرکتا وقفہ زیادہ امکان ہے کہ راستے کا مسئلہ یا منتقل شدہ سیشن ہو۔

دو keepalive ٹائمر جو کبھی متفق نہیں ہوئے

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

دونوں قدریں ایک ہی کنٹرول نہیں ہیں۔ ping یہ ہے کہ کلائنٹ کتنی بار گونج بھیجتا ہے، اور ping-restart یہ ہے کہ سرنگ گرانے سے پہلے وہ کچھ سنے بغیر کتنی دیر انتظار کرتا ہے۔ کم ping-restart والا پروفائل اور آہستہ جواب دینے والا گیٹ وے ہر خاموش دورانیے میں دوبارہ شروع ہوں گے، جو ٹھیک ایک منٹ کے چکر کی شکل ہے۔

کلائنٹ کی طرف سب سے چھوٹی تبدیلی یہ ہے کہ پروفائل کی سب سے اوپر سطح پر، ہر اِن لائن بلاک سے باہر، ٹائمرز کو غیر فعال کریں:

keepalive 0 0

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

سرٹیفکیٹ کا نام آپ کے قدموں کے نیچے سے سرک سکتا ہے

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

گیٹ وے میں ترمیم سے پہلے اسی مشین پر دوسری نسل کا کلائنٹ جانچیں۔ اگر ایک کلائنٹ چکر میں ہے اور دوسرا ٹکا ہوا ہے، تو پروفائل مسئلہ نہیں۔

کیا تبدیل کرنا ہے، اور کس ترتیب سے

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

پھر چند منٹ مسلسل ٹریفک چلا کر غیر فعال راستہ جانچیں۔ اگر ٹریفک بہتے وقت گرنا رک جائے، تو اہم ٹائمر OpenVPN کا نہیں، راستے میں موجود NAT ڈیوائس یا لوڈ بیلنسر کا ہے۔

گیٹ وے کی ترتیبات صرف ان چار جانچوں کے بعد بدلنی چاہئیں۔