ترافیک کلاینت VPN و وضعیت فایروال: جریان بیرونی در برابر درونی
جریان تونل و اتصال پس از کپسول‌زدایی بسته‌های متفاوتی هستند. تعیین کنید کدام را مجاز می‌کنید و آیا هر مرز وضعیت را ردیابی می‌کند.
دست‌دادن VPN کامل می‌شود، کلاینت نشانی می‌گیرد، و همچنان سرویسی پشت دروازه اتصال را رد می‌کند. فایروال اغلب دقیقاً همان کاری را می‌کند که به آن گفته شده است. جریان بیرونی تونل را مجاز کرده است، که بستهٔ متفاوتی از اتصال برنامه پس از کپسول‌زدایی است. دو تصمیم از این نتیجه می‌شود: کدام جریان را مجاز می‌کنید و آیا مرز اصلاً وضعیت را ردیابی می‌کند.
تا زمانی که این دو را از هم جدا نکنید، هر تغییر قاعده یک حدس است.
فایروال دو بستهٔ متفاوت می‌بیند
پیش از کپسول‌زدایی، فایروال ترافیکی را می‌بیند که به نقطهٔ پایانی VPN نشانی داده شده است: جریان بیرونی UDP به شنونده. پس از کپسول‌زدایی، بستهٔ ارسال‌شده نشانی درونی کلاینت و مقصد سرویس را حمل می‌کند.
مجوز جریان بیرونی، اتصال TCP ارسال‌شده را مجاز نمی‌کند. این دو ممکن است در زنجیره‌های متفاوت، مقابل رابط‌های متفاوت و با نشانی‌های متفاوت پس از ترجمه ارزیابی شوند.
ضبط‌های گرفته‌شده از موقعیت‌های معادل در دو طرف را مقایسه کنید. ضبط در لبهٔ تونل و ضبط در سرور، چندتایی‌های متفاوتی برای همان نشست نشان می‌دهند.
تصمیم نخست: مجاز کردن تونل یا سرویس
اگر کلاینت فقط خود نقطهٔ پایانی VPN را لازم دارد، مجوز بیرونی ممکن است کافی باشد. اگر به سرویسی فراتر از دروازه نیاز دارد، به مجوز ارسال برای آن مقصد و درگاه نیاز دارید. قاعدهٔ تونلی که سرویس را هم مجاز می‌کند، یک تصمیم طراحی است که باید نامش را ببرید، نه یک تصادف.
دامنهٔ کلاینت و گسترهٔ سرویس را باریک نگه دارید. مجوز از زیرشبکهٔ تونل به کل شبکهٔ محلی، تصمیم به اعتماد به هر میزبان است، نه میانبری برای یک برنامه.
هر دو قاعده را جداگانه بنویسید. قاعدهٔ تونل و قاعدهٔ سرویس به شکل‌های متفاوت شکست می‌خورند و با شواهد متفاوت اشکال‌زدایی می‌شوند. وقتی یکی شکست می‌خورد، می‌دانید کدام لایه را اول بررسی کنید.
تصمیم دوم: با وضعیت یا بی‌وضعیت در هر مرز
قاعدهٔ جریان برقرار می‌تواند پاسخ‌ها را برای تبادلی مجاز بپذیرد، اما رفتارش به محصول بستگی دارد. گروه امنیتی ابری معمولاً وضعیت را نگه می‌دارد؛ فهرست کنترل زیرشبکه اغلب وضعیت نگه نمی‌دارد و در هر دو جهت به رسیدگی صریح نیاز دارد. فرض نکنید هر مرزی در مسیر، وضعیت را یکسان می‌بیند. پیش از طراحی قواعد، هر مرز را فهرست کنید و آن را با وضعیت یا بی‌وضعیت علامت بزنید.
اگر قاعده‌ای تغییر کند، ممکن است جریان‌های ردیابی‌شدهٔ موجود همچنان کار کنند در حالی که جریان‌های جدید شکست می‌خورند، یا برعکس. این تفاوت سرنخ مفیدی است، نه دلیلی برای پاک کردن همهٔ وضعیت اتصال‌ها روی یک دروازهٔ فعال.
با یک درخواست تازه و کنترل‌شده آزمایش کنید و شمارنده‌های مربوط را بررسی کنید. یک آزمایش پاک بهتر از یک بازنشانی مخرب است. نام شمارنده را در سابقهٔ تغییر بنویسید تا آزمایش بعدی از همان شواهد استفاده کند.
مسیر بازگشت را زیر همان سیاست بررسی کنید
درخواست تازه‌ای از کلاینت به سرویس بفرستید، سپس شمارنده‌های رفت و برگشت را در هر مرز بررسی کنید. تأیید کنید که پاسخ از مسیری که انتظار دارید استفاده می‌کند، به‌ویژه اگر ترجمه در میان باشد.
دامنهٔ کلاینت موردنظر و گسترهٔ سرویس را باریک نگه دارید و مسیر بازگشت را زیر همان مجموعه قواعدی بررسی کنید که درخواست را مجاز کرد. قاعده‌ای که فقط چون جریان قدیمی هنوز باز است کار می‌کند، قاعدهٔ کارآمدی نیست.