VPN سایتبهسایت: کدام جهت واقعاً به یک قاعده نیاز دارد؟
درخواستها و پاسخها هر دو به اجازه نیاز دارند، اما یک فایروال حالتدار معمولاً بازگشت اتصالی را که پذیرفته است مجاز میکند. پیدا کنید کدام سمت قاعده ندارد.
هر دو طرف تونلی برقرار را گزارش میکنند، شعبه دور از دروازه پاسخ میدهد، و برنامه همچنان برای کاربران یک سمت به پایان مهلت میرسد. توصیه معمول این است که در هر دو جهت یک قاعده فایروال اضافه کنید. گاهی درست است، گاهی قاعدهای را که از قبل وجود دارد تکرار میکند، و گاهی قاعده دوم همان چیزی است که حالت را میشکند. اینکه کدام حالت صدق میکند بستگی دارد به اینکه فایروال بسته را کجا میبیند.
ترافیک بازگشتی حالتدار تعداد را تغییر میدهد
فایروال حالتدار درخواست را ثبت میکند و پاسخ را بدون قاعده دوم مجاز میکند، بنابراین طرحی که فقط به یک قاعده نیاز دارد طبیعی است. فهرست دسترسی بیحالت چنین حافظهای ندارد، و پاسخ باید صریحاً مجاز شود. هر دو روی پلتفرم خود درست هستند، و به همین دلیل توصیهها با هم تناقض دارند.
مستندات ارسال برای پلتفرمی که پیش روی دارید را بخوانید و بررسی کنید آیا سیاستی که ویرایش میکنید همانجایی که بسته را میبیند حالتدار است. یک منع صریح برای ترافیک برقرار، یا ترتیب قواعدی که پاسخ را پیش از جدول حالت ارزیابی میکند، طرحی کارآمد را به چیزی گیجکننده تبدیل میکند. تعداد قواعد جزئیات پیادهسازی است، در حالی که الزام این است که هر دو جهت یک گفتوگوی مجاز بتواند کامل شود.
جایی که فایروال بستههای رمزگشاییشده را میبیند
در تونل مبتنی بر سیاست، فایروال ممکن است بسته رمزگذاریشده را پیش از رمزگشایی و بسته رمزگشاییشده را پس از آن، روی رابطهای مختلف ارزیابی کند. قاعدهای که برای رابط اشتباه نوشته شده موجود، درست و هرگز مطابقت داده نمیشود. اینگونه است که مجموعه قواعدی که از استقرار کارآمد کپی شده میتواند روی سختافزار یکسان شکست بخورد.
IPsec مسیرمحور و بیشتر پیادهسازیهای مدرن یک رابط تونل ارائه میدهند، بنابراین بسته رمزگشاییشده به آنجا میرسد و قواعد معمول رابط اعمال میشوند. پیش از کپی کردن مجموعه قواعد از راهنمایی که برای دیگری نوشته شده، تأیید کنید استقرار از کدام مدل استفاده میکند. رابط تونل همچنین جایی است که باید نگاه کنید وقتی میخواهید بدانید آیا بسته اصلاً رمزگشایی شده است.
مسیریابی نامتقارن فرض را میشکند
فایروال حالتدار فرض میکند که هر دو نیمه گفتوگو را میبیند. اگر پاسخ از دروازه دیگری بازگردد، آن دستگاه هیچ حالتی برای درخواست نگه نمیدارد و آن را بر اساس سیاست خود میاندازد. نشانه، شکست یکطرفهای است که هیچ قاعدهای در سمت فرستنده نمیتواند آن را ترمیم کند. مسیر پاسخ را دنبال کنید پیش از ویرایش هر چیزی.
پیش از افزودن یک قاعده مجاز گسترده در هر دو سمت، مسیر پاسخ را بررسی کنید. تحمل همهچیز روی هر رابط، خطای مسیریابی را پنهان میکند و همزمان دسترسی را گستردهتر میکند، که بدترین ترکیب ممکن است.
هر دو جهت را با نشانیهای مبدأ واقعی بررسی کنید
با نشانیای آزمایش کنید که سمت دور واقعاً میبیند، زیرا ترجمه میتواند باعث شود قاعده مبدأ با هیچچیز مطابقت نداشته باشد. ضبط را همزمان روی هر دو دروازه اجرا کنید.
tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15
درخواستی که با نشانی مبدأ غیرمنتظره روی دروازه دور ظاهر میشود، قاعدهای را توضیح میدهد که هرگز مطابقت ندارد، و پاسخی که روی رابط اشتباه میرسد، ناسازگاری حالت را توضیح میدهد. سپس یک مقصد در محدوده تأییدشده و یکی بیرون از آن را آزمایش کنید تا مرز نشان داده شود نه فرض.
نشانی مبدأ پس از ترجمه، رابطی که بسته رمزگشاییشده استفاده کرد و قاعدهای که مطابقت داشت را ثبت کنید. این سه واقعیت به تیکت بعدی پاسخ میدهند بدون تکرار کل بررسی.