iPhone Always On VPN: دو ٹنل ایک ورچوئل IP شیئر کر سکتے ہیں

ایک زیرِ نگرانی iPhone پر جس میں منظم Always On پروفائل ہے، فون ہر فعال IP انٹرفیس کے لیے ایک ٹنل رکھتا ہے، اس لیے سیلولر اور Wi-Fi دونوں کو اپنی اپنی ملتی ہے۔ پھر سرور ایک ڈیوائس کے لیے دو IKE سکیورٹی ایسوسی ایشنز کی فہرست دکھاتا ہے، اکثر ایک ورچوئل پتہ شیئر کرتے ہوئے، اور پہلا ردِعمل اسے rekey لوپ کہنا اور ٹائمر بدلنا شروع کرنا ہوتا ہے۔ یہ ردِعمل عموماً غلط ہوتا ہے۔ نیچے دیے گئے مراحل اسی ترتیب سے کریں جس ترتیب سے شواہد سرور پر ظاہر ہوتے ہیں، اور فون کی سیٹنگز کو تب تک نہ چھیڑیں جب تک سرور نہ بتائے کہ آپ کا کیس کون سا ہے۔

سرور کے پاس پہلے سے موجود دو قطاروں سے شروع کریں

ایسوسی ایشنز کو swanctl --list-sas سے فہرست کریں اور دونوں اندراجات میں چار فیلڈ پڑھیں: دور کا پتہ، تصدیق شدہ شناخت، مختص شدہ ورچوئل IP اور بننے کا وقت۔ ایک شناخت اور ایک ورچوئل IP کے ساتھ دو مختلف بیرونی پتے وہی شکل ہیں جس نے یہ سوال شروع کیا، اور کسی بھی تبدیلی سے پہلے اسے لکھ لینا مناسب ہے۔ پھر ہر ایک سے منسلک چائلڈ ایسوسی ایشنز چیک کریں، کیونکہ ٹریفک سلیکٹرز طے کرتے ہیں کہ منزل کی تلاش کبھی دونوں ٹنلوں میں فرق کر سکتی ہے یا نہیں۔ چند سیکنڈ میں نمودار ہو کر غائب ہونے والا جوڑا گھنٹوں تک زندہ رہنے والے جوڑے سے مختلف جانور ہے۔

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

فیصلہ کریں کہ آپ کون سی اوورلیپ دیکھ رہے ہیں

IKEv2 rekey اور make-before-break دوبارہ تصدیق جان بوجھ کر مختصر اوورلیپ بناتے ہیں، پرانی ایسوسی ایشن حذف کرنے سے پہلے نئی قائم کر کے۔ وقت کے نشان فیصلہ کرتے ہیں، کیونکہ نئی کے ظاہر ہونے کے ایک دو سیکنڈ بعد غائب ہونے والی پرانی SA وہ تجدید ہے جو اپنا کام کر رہی ہے۔ خودمختار انٹرفیس ٹنل کبھی ایسی نظر نہیں آتیں، کیونکہ ہر ایک اپنے انٹرفیس کے فعال رہنے تک قائم رہتی ہے، اور ایک کو حذف کرنا دوسری کے بننے سے نہیں آتا۔

Apple کا منظم Always On رویہ فی انٹرفیس ہے، اسی لیے زیرِ نگرانی ڈیوائس ہاتھ سے ترتیب دیے گئے پروفائل سے قانونی طور پر زیادہ مصروف دکھ سکتی ہے۔ کسی پرووائیڈر ایپ کا آٹو کنیکٹ ٹوگل وہی بات نہیں بتاتا، اور عام on-demand قاعدہ بھی نہیں۔ Apple کا تعیناتی جائزہ فی انٹرفیس ماڈل بیان کرتا ہے؛ لوپ فرض کرنے سے پہلے اپنی دونوں قطاریں اس سے موازنہ کریں۔ دونوں شکلیں ایک ہی سرور پول سے لیتی ہیں، اس لیے اوورلیپ ہی آپ کا واحد ابتدائی اشارہ ہے۔

دیکھیں کہ ایک ورچوئل پتہ دو ٹنلوں کے جواب کیوں توڑتا ہے

فون کو جواب اندرونی پتے پر بھیجا جاتا ہے، اور کرنل منزل اور پالیسی کے مطابق باہر جانے والی ٹنل چنتا ہے، نہ کہ اس انٹرفیس کے مطابق جو فون نے استعمال کیا۔ ایک ہی ورچوئل IP اور ملتی جلتی پالیسیوں والی دو بیک وقت ایسوسی ایشنز روٹنگ فیصلے کو یہ بتانے کا کوئی راستہ نہیں چھوڑتیں کہ جواب کس سیشن کا ہے۔ کچھ جواب غلط ٹنل سے جاتے ہیں، اور فون ایک طرف چلنے والا یا Wi-Fi آنے پر مرنے والا کنکشن دکھاتا ہے۔ دو کمانڈ آؤٹ پٹ حالت ثابت کرتے ہیں: swanctl --list-sas دونوں SA پر ایک ہی ورچوئل IP دکھاتا ہے، اور ip xfrm policy دو یکساں سلیکٹر دکھاتا ہے۔

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

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

پول یا ہم وقتی ماڈل بدلیں، rekey ٹائمر نہیں

swanctl کنفیگریشن میں، انفرادیت کنکشن پر ایک واضح پالیسی ہے: unique = replace نئی کے قائم ہونے پر پرانا کنکشن ہٹاتا ہے، اور unique = keep نئے آنے والے کو مسترد کرتا ہے۔ دونوں قدریں کنکشن قائم ہونے کے وقت عمل کرتی ہیں، اس کے اندر کی چائلڈ SA پر نہیں۔

connections {
  ios-alwayson {
    unique = replace
  }
}

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

وہ منتقلیاں آزمائیں جو آپ واقعی تعینات کرتے ہیں

فعال سیشن کے ساتھ Wi-Fi کی حد سے باہر جائیں، پھر واپس آئیں، اور چیک کریں کہ جواب دونوں سمتوں میں آتے ہیں۔ یہ دو بار کریں، کیونکہ دوسری منتقلی ہی وہ جگہ ہے جہاں پرانی پالیسی عموماً ظاہر ہوتی ہے۔ اُس سروس سے آزمائیں جو آپ کے کھولے گئے کنکشن پر جواب دیتی ہے، اور باہر جانا تب دہرائیں جب ٹنل ٹریفک لے جا رہی ہو نہ کہ خالی بیٹھی ہو۔ جو فون بھیج سکتا ہے مگر وصول نہیں کر سکتا، وہ handshake لاگ میں صحت مند اور براؤزر میں ٹوٹا ہوا دکھتا ہے۔

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