AWS Client VPN: ورود انجام می‌شود اما به زیرشبکه نمی‌رسید

کلاینت شما Connected نشان می‌دهد، گواهی معتبر است و صفحه اینترانت همچنان با پایان زمان تمام می‌شود. این فاصله تقریباً هرگز مربوط به احراز هویت نیست. AWS Client VPN مقصدها را جدا از ورود مجاز می‌کند و دو علت معمول عبارت‌اند از مقدار گروهی که با آنچه ارائه‌دهنده هویت فرستاده مطابقت ندارد و قاعده مقصد دقیق‌تری که بر قاعده گسترده غالب می‌شود. هر دو در پیکربندی endpoint دیده می‌شوند، وقتی بدانید کجا را نگاه کنید.

ورود موفق شد؛ قاعده مطابقت نداشت

احراز هویت پاسخ می‌دهد که کاربر چه کسی است. قواعد مجوزدهی پاسخ می‌دهند که این هویت به کدام پیشوندهای شبکه دسترسی دارد. کاربر می‌تواند اولی را بگذراند و در دومی شکست بخورد، و کلاینت چیزی بیش از اتصالی که برپا می‌ماند در حالی که هر درخواست به پایان زمان می‌رسد به شما نمی‌دهد.

با تأیید این شروع کنید که endpoint قاعده مجوزدهی دارد که مقصدش نشانی ناموفق را در بر می‌گیرد. اگر قاعده منطبقی وجود ندارد، اتصال درست رفتار می‌کند؛ سیاست است که غایب است.

مقدار گروه در واقع از کجا می‌آید

در Active Directory، فیلد access-group شناسه SID گروه را نگه می‌دارد، نه نام نمایشی آن را. در فدراسیون SAML، شناسه یا نام گروهی را نگه می‌دارد که صفت گروه SAML پیکربندی‌شده واقعاً حمل می‌کند. مقدار را از assertion یا از جست‌وجوی دایرکتوری کپی کنید، نه از یک صفحه ویکی.

گروه IAM صفحه کنترل دیگری است. اجازه مدیریت یک endpoint در Client VPN گروه IAM را به گروه VPN کاربر تبدیل نمی‌کند و چسباندن نام گروه IAM در فیلد access-group آن را به SID در AD یا مقدار صفت SAML ترجمه نمی‌کند.

گروهی با نام مشابه در دایرکتوری دیگر چیزی را ثابت نمی‌کند. روش احراز هویت endpoint و عضویت یا assertion کاربر را در همان سامانه بررسی کنید.

پیشوند بلندتر برنده است، از جمله 0.0.0.0/0

مجوزدهی با بلندترین تطابق پیشوند ارزیابی می‌شود و قاعده همه مقصدها آخر ارزیابی می‌شود، نه اول. قاعده 10.46.0.0/16 را برای Engineering و قاعده 0.0.0.0/0 را برای همه اضافه کنید، و کاربری بیرون از Engineering باز هم از طریق قاعده گسترده به 10.46.20.10 نمی‌رسد.

اینجاست که یک اصلاح می‌تواند اشتباه شود. حذف قاعده باریک دسترسی کاربر را برمی‌گرداند و آن زیرشبکه را به هر هویتی که قاعده گسترده پوشش می‌دهد هم می‌دهد. پیش از حذف هر چیزی ماتریس گروه به شبکه را بسازید و بنویسید کدام گروه‌ها باید به کدام بازه برسند. این قواعد فقط اجازه می‌دهند؛ هیچ ورودی رد برای بریدن یک استثنا از یک اجازه گسترده وجود ندارد.

تغییرها برای داوری منصفانه به اتصال تازه هم نیاز دارند. پس از ویرایش قواعد کلاینت را دوباره وصل کنید و سپس دوباره آزمایش کنید.

مجوزدهی را از مسیر داده جدا کنید

قاعده‌ای که مطابقت دارد مسیر نیست. endpoint به یک زیرشبکه مرتبط و یک ورودی در جدول مسیریابی برای مقصد نیاز دارد و گروه امنیتی منبع هدف باید ترافیک را بپذیرد. ترافیک برگشتی و DNS هم باید کار کنند.

کاربری را آزمایش کنید که باید موفق شود و کاربری که باید بیرون بماند. هر دو می‌توانند وارد شوند در حالی که فقط یکی به زیرشبکه می‌رسد، و همین تفاوت شاهدی است که می‌خواهید.

اگر یک نشانی IP کار می‌کند اما نام میزبان نه، پیش از دست زدن به مجوزدهی به resolver نگاه کنید. اگر هیچ مسیری نشانی را پوشش نمی‌دهد، پیوند یا جدول مسیریابی را درست کنید. اگر بسته می‌رسد و سرویس آن را رد می‌کند، ایستگاه بعدی سیاست همان سرویس است. گسترش ماتریس مجوزدهی به همه کاربران پنهان می‌کند که کدام یک از این لایه‌ها واقعاً خراب بود.

پیش از بستن تیکت، منبع هویت، مقدار دقیق گروه، پیشوندهای مقصد و مسیری که ترافیک را حمل می‌کند ثبت کنید. این ثبت گزارش بعدی درباره اتصال بدون دسترسی را به مقایسه‌ای دو دقیقه‌ای بدل می‌کند، نه دور دیگری از حدس.