باز کردن درگاه VPN دسترسی کلاینت‌ها به LAN را فراهم نمی‌کند
یک قاعده ورودی بسته‌هایی را می‌پذیرد که به خود دروازه نشانی داده شده‌اند. ترافیک کلاینت به میزبان دیگر به ارسال، مسیریابی و مسیر بازگشت نیاز دارد که جداگانه آزمایش می‌شود.
تونل بالا می‌آید، کلاینت احراز هویت می‌شود، اما LAN پشت دروازه نامرئی می‌ماند. قاعده‌ای که قرار بود این را درست کند درگاه VPN را مجاز می‌کند و دقیقاً همان‌طور که نوشته شده کار می‌کند، چون آن قاعده بسته‌های نشانی‌شده به خود دروازه را کنترل می‌کند. ترافیک کلاینت به میزبانی پشت دروازه مقصد دیگری و زنجیره دیگری دارد. ورود موفق تغییری در این نمی‌دهد که هسته کدام یک از دو زنجیره را بررسی می‌کند.
دو زنجیره، دو مقصد متفاوت
سرنوشت بسته با جایی که می‌رود تعیین می‌شود، نه با نحوه رسیدنش. ترافیک به نشانی روی دروازه به‌صورت محلی تحویل و با قواعد ورودی سنجیده می‌شود. ترافیکی که دروازه به جلو می‌فرستد با قواعد ارسال سنجیده می‌شود. همان رابط تونل می‌تواند هر دو نوع بسته را تولید کند، پس یک قاعده نمی‌تواند هر دو کار را پوشش دهد.
کل افسانه در یک جمله: اجازه دادن به شنونده هیچ چیزی درباره اجازه دادن به شبکه پشت آن نمی‌گوید. این‌ها دو تصمیم جدا با دو شاهد جدا هستند و نام رابط روی هر دو آن‌ها را یکی نمی‌کند.
قاعده شنونده در واقع چه چیزی را مجاز می‌کند
بسته‌های شنونده در فرایند VPN پایان می‌یابند و همین است که برپایی تونل را ممکن می‌کند. صفحه مدیریت دروازه و پاسخ تشخیصی محلی نیز از مسیر ورودی خود میزبان استفاده می‌کنند، بنابراین آزمون به دروازه موفق می‌شود در حالی که همه‌چیز پشت آن شکست می‌خورد. هر دو نتیجه درست است و هیچ‌کدام درباره LAN نیست.
وقتی فرایند ترافیک کلاینت را برای مقصد دیگری کپسول‌زدایی می‌کند، بسته وارد مسیر ارسال می‌شود و آنجا به اجازه نیاز دارد. احراز هویت موفق مشخص می‌کند کلاینت کیست؛ مشخص نمی‌کند کجا می‌تواند برود. دو پرسش صاحبان مختلف، گزارش‌های مختلف و پیام‌های خطای مختلف دارند.
از کلاینت آزمایش کنید، هرگز از دروازه
آزمونی که روی دروازه ساخته می‌شود مسیر خروج خود میزبان را دنبال می‌کند و می‌تواند موفق شود در حالی که مسیر ارسال بسته است. آزمون را از کلاینت آغاز کنید و دو سر جریان را ببینید.
nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25اگر درخواست روی tun0 دیده شود و چیزی به مقصد نرسد، بسته پس از رسیدن دور ریخته می‌شود، که به قواعد ارسال یا فیلتر خود مقصد اشاره دارد. اگر روی tun0 هیچ چیزی دیده نشود، کلاینت آن را حتی به تونل نمی‌فرستد و مشکل مسیریابی روی کلاینت است نه سیاست روی دروازه. آن را با درخواستی مقایسه کنید که درست بیرون می‌رود و چیزی برنمی‌گرداند، که همان مورد مسیر بازگشت است.
ارسال به سه چیز نیاز دارد، نه یکی
ارسال در هسته باید فعال باشد، یک قاعده فیلتر باید جریان را بپذیرد و مقصد باید با مسیری برای بازگشت پاسخ قابل دسترسی باشد. اگر یکی از سه نباشد، سکوت از دید کلاینت همان است.
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUTسه خروجی را با هم بخوانید. صفر در اولی دو تای دیگر را بی‌اهمیت می‌کند و سیاست رد پیش‌فرض در دومی بسته‌های کلاینت را دور می‌ریزد در حالی که ترافیک خود دروازه به کار ادامه می‌دهد. خروجی سوم نشان می‌دهد چرا قاعده شنونده هرگز مشکل نبود.
دو مجموعه قاعده را در مستندات جدا نگه دارید
قاعده شنونده و قاعده سرویس ارسال‌شده را در خطوط جدا با صاحبان و دلایل جدا بنویسید. وقتی درگاه VPN تغییر می‌کند یا سرویس تازه‌ای منتشر می‌شود، این جدایی مانع می‌شود یک تغییر دیگری را بی‌صدا گسترش دهد.
به‌جای اینکه هر همتای احرازشده را عضو مورد اعتماد LAN بدانید، از قواعد باریک برای محدوده‌های کلاینت و سرویس‌هایی که به آن نیاز دارند استفاده کنید. یادداشت‌های ارسال StrongSwan سمت مسیر بازگشت و ترجمه همان مرز را توصیف می‌کند که باز هم تصمیم سوم است.
سرانجام، لایه‌ها را درست نگه دارید وقتی کاربری رد می‌شود. اگر درخواست به میزبان برسد و برنامه حساب را رد کند، مجوز برنامه را در همان لایه درست کنید؛ گسترش ارسال نمی‌تواند اعتبارنامه اشتراک فایل بدهد و دسترسی را برای همه دیگرانی که موفق وصل می‌شوند گسترش می‌دهد.