AWS Client VPN: لاگ اِن کامیاب ہوتا ہے لیکن سب نیٹ تک رسائی نہیں

آپ کا کلائنٹ Connected دکھاتا ہے، سرٹیفکیٹ درست ہے، اور انٹرانیٹ صفحہ پھر بھی وقت ختم ہونے پر رکتا ہے۔ یہ فرق تقریباً کبھی تصدیق نہیں ہوتا۔ AWS Client VPN منزلوں کو لاگ اِن سے الگ اجازت دیتا ہے، اور عام طور پر دو وجوہات ہوتی ہیں: ایسی گروپ ویلیو جو شناختی فراہم کنندہ کی بھیجی گئی ویلیو سے مطابقت نہیں رکھتی، اور زیادہ مخصوص منزل کا قاعدہ جو وسیع قاعدے کو شکست دیتا ہے۔ کہاں دیکھنا ہے معلوم ہو تو دونوں endpoint کنفیگریشن میں نظر آتے ہیں۔

لاگ اِن کامیاب ہوا؛ قاعدہ مطابق نہیں آیا

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

اس بات کی تصدیق سے شروع کریں کہ endpoint کے پاس ایسا اجازت کا قاعدہ ہے جس کی منزل میں ناکام ہونے والا پتہ شامل ہے۔ اگر مطابق قاعدہ نہیں ہے تو کنکشن درست برتاؤ کر رہا ہے؛ کمی پالیسی کی ہے۔

گروپ ویلیو دراصل کہاں سے آتی ہے

Active Directory میں، access-group فیلڈ گروپ کا ڈسپلے نام نہیں بلکہ اس کا SID رکھتی ہے۔ SAML فیڈریشن میں، یہ وہ گروپ ID یا نام رکھتی ہے جو کنفیگر شدہ SAML گروپ صفت واقعی لے کر چلتی ہے۔ ویلیو کو assertion یا ڈائریکٹری تلاش سے کاپی کریں، وکی صفحے سے نہیں۔

IAM گروپ ایک الگ کنٹرول سطح ہے۔ Client VPN endpoint کے انتظام کی اجازت IAM گروپ کو صارف کا VPN گروپ نہیں بناتی، اور access-group فیلڈ میں IAM گروپ کا نام چپکانے سے وہ AD SID یا SAML صفت ویلیو میں تبدیل نہیں ہوتا۔

کسی دوسری ڈائریکٹری میں ملتے جلتے نام کا گروپ کچھ ثابت نہیں کرتا۔ endpoint کا تصدیقی طریقہ اور اسی نظام میں صارف کی رکنیت یا assertion چیک کریں۔

سب سے لمبا سابقہ جیتتا ہے، بشمول 0.0.0.0/0

اجازت سب سے لمبے سابقے کی مطابقت سے جانچی جاتی ہے، اور تمام منزلوں کا قاعدہ پہلے نہیں بلکہ آخر میں جانچا جاتا ہے۔ Engineering کے لیے 10.46.0.0/16 قاعدہ اور سب کے لیے 0.0.0.0/0 قاعدہ شامل کریں، پھر بھی Engineering سے باہر صارف وسیع قاعدے سے 10.46.20.10 تک نہیں پہنچ سکتا۔

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

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

اجازت کو ڈیٹا راستے سے الگ کریں

مطابق قاعدہ راستہ نہیں ہے. endpoint کو منسلک سب نیٹ اور منزل کے لیے روٹ ٹیبل اندراج درکار ہے، اور ہدف وسیلے کا سکیورٹی گروپ ٹریفک قبول کرے۔ واپسی ٹریفک اور DNS بھی کام کرنے چاہئیں۔

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

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

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