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

بسته را پس از رمزگشایی رسم کنید، نه پیش از آن

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

بخش درونی را به شکل دنباله‌ای شماره‌دار با انواع دستگاه نام‌برده بنویسید، نه به شکل یک پیکان. پیکان پنهان می‌کند که آیا درخواست از یک پالایه می‌گذرد، و گذشتن یا نگذریدن تمام مسئله است. هر گام در پایین دستگاه و مجموعه قواعدی را که آنجا عمل می‌کند نام می‌برد، بنابراین پالایه غایب به شکل شکاف دیده می‌شود نه چیزی که یک خط القا کرده باشد.

  1. کارخواه دوردست: دستگاه کاربری که تونل را ایجاد می‌کند.
  2. سیاست لبه: مجموعه قواعدی که انتقال بیرونی را به شنونده عمومی می‌پذیرد.
  3. دستگاه پایانی: نقطه پایانی VPN که بسته را واسرشته‌سازی می‌کند و به IP معمولی می‌سپارد.
  4. پالایه درونی: مجموعه قواعد ارسال یا گروه‌های امنیتی که ترافیک کارخواه به سرویس را محدود می‌کند.
  5. میزبان برنامه: سرویسی که درخواست رمزگشایی‌شده را دریافت می‌کند.

دو سیاست، دو مالک

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

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

جایگاه تعیین می‌کند درخواست کدام مرز را می‌گذراند

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

PlacementWhat terminates thereWhat sees plaintextWhich control can still denyFailure domain
Termination in a dedicated segmentA dedicated VPN endpointThe endpoint and anything on its segmentThe filter between that segment and the applicationThe segment path can bypass the filter if no rule sits on it
Termination on the edge firewallThe firewall's public listenerThe firewall, after decapsulationThe firewall's inner rule setAdmission and inspection fail together
Termination on the protected LANThe appliance's LAN legEvery host on the protected LANOnly a host control or a downstream gatewayThe appliance and the protected hosts fail together

جایگاه سوم همان است که اجرا را بی‌صدا حذف می‌کند، چون بخشی روی قطعه محافظت‌شده مسیری مستقیم به دستگاه می‌دهد که ممکن است نمودار نشانش ندهد. رابط‌ها و مسیرها را بررسی کنید نه تصویر را: ip route get 10.20.5.10 می‌گوید بسته از کدام رابط خارج می‌شود، و پاسخ اغلب آن نیست که طراحی فرض کرده بود. نقش کلاسیک دیوار آتش در کنترل ترافیک میان حالت‌ها، چنان‌که درNIST SP 800-41 توصیف شده، آزمایشی سودمند در اینجاست، چون دستگاهی که بخشی نامحدود به شبکه محافظت‌شده دارد چیز زیادی را کنترل نمی‌کند. جست‌وجوی مسیر نموداری صادقانه‌تر از نمودار ارائه است.

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

ترجمه تغییر می‌دهد که قواعد پایین‌دست چه می‌بینند

ترجمه مبدأ راحت است و اطلاعات را نابود می‌کند. پس از masquerade هر کارخواه شبیه دستگاه به نظر می‌رسد، بنابراین قاعده‌ای در پایین‌دست که برای تشخیص کاربران نوشته شده دیگر نمی‌تواند این کار را بکند. این تنها مشکل ثبت رویداد نیست، مشکل سیاست است: قاعده‌ای که بر نشانی کارخواه کلید خورده بی‌صدا به قاعده‌ای کلیدخورده بر درگاه تبدیل می‌شود. اگر سیاست به‌ازای هر کاربر مهم است، مبدأ را حفظ کنید یا سیاست را پیش از ترجمه اعمال کنید.

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

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

یک عملیات مجاز و یک عملیات ردشده را بپذیرید

از کارخواه دوردست واقعی آزمایش کنید نه از میزبان مدیریت، چون میزبان مدیریت معمولاً جایی نشسته که کاربر هرگز نخواهد بود. یک عملیات مجاز ثابت می‌کند مسیر کار می‌کند، و یک عملیات ردشده ثابت می‌کند سیاست اصلاً کاری می‌کند. هر دو را پس از هر تغییر جایگاه اجرا کنید و هویت مبدأ و مقصدی را که به کار بردید ثبت کنید. آزمایشی که تنها موفقیت را ثابت می‌کند نمی‌تواند قاعده درست را از قاعده غایب تشخیص دهد.

سپس مواردی را آزمایش کنید که حالت را تغییر می‌دهند: اتصال دوباره، نشستی که از چرخش کلید جان سالم به در می‌برد، و شکست خود دستگاه. به‌روزرسانی‌ها، ظرفیت و بازیابی را بخشی از همان چیدمان بدانید و مقایسه کنید، چون دستگاهی که چند کنترل منطقی را نگه می‌دارد یک دامنه شکست با چند برچسب است. جعبه دوم هم مستقل نیست وقتی یک اعتبارنامه مدیریتی مشترک یا مسیری نامحدود مرزی را که باید می‌ساخت شکست می‌دهد.

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

مقالات مرتبط