مسیر VPN یا قاعده دیوار آتش: کدام بسته را می‌اندازد؟
مسیر یک راه انتخاب می‌کند و فیلتر درباره اجازه تصمیم می‌گیرد. پیش از گسترش یک قاعده دیوار آتش، هر دو را برای همان مبدأ، مقصد و جهت بررسی کنید.
دو تصمیم مستقل روی همان بسته گرفته می‌شود و هر یک از آن‌ها می‌تواند درخواست را بی‌صدا پایان دهد. جست‌وجوی مسیریابی یک رابط و گام بعدی را انتخاب می‌کند، سپس فیلتر بسته تصمیم می‌گیرد که آیا آن ترکیب مجاز است. یک پایان مهلت به شما می‌گوید که یکی از آن دو رد کرده است، نه کدام‌یک. مراحل را به ترتیب پیش ببرید و معمولاً تعمیر دیگر حدس نیست.
دو تصمیم، یک بسته، دو مالک
جست‌وجوی مسیریابی نخست قواعد سیاست را بررسی می‌کند، سپس جدولی را که به آن اشاره می‌کنند، و مشخص‌ترین پیشوندی را که با مقصد می‌خواند انتخاب می‌کند. کارخواهی که مسیر تونل را نصب کرده است صاحب آن تصمیم است و چیزی در قاعده دیوار آتش نمی‌تواند جای آن را بگیرد. وقتی جست‌وجو به جایی غیرمنتظره اشاره می‌کند، هر مرحله بعدی روی بسته اشتباه کار می‌کند.
فیلترکردن جداگانه است. روی میزبان Linux قلاب‌های netfilter ترافیک را بر اساس اینکه بسته برای چه کسی است تقسیم می‌کنند: خروج ماشین را ترک می‌کند، ورود روی آن پایان می‌یابد، ارسال از میان آن می‌گذرد. دروازه‌ای که کارخواهان VPN را می‌پذیرد و آن‌ها را به یک LAN مسیریابی می‌کند به مسیر ارسال نیاز دارد و این همان زنجیره‌ای است که بیشتر پیکربندی‌های پیش‌فرض خالی می‌گذارند.
انتخاب مبدأ به همان تصمیم تعلق دارد و بیشتر ناسازگاری‌ها همان‌جا پنهان است. هسته یک نشانی مبدأ از رابط خروجی انتخاب می‌کند مگر اینکه مسیر یکی را نام ببرد، بنابراین قاعده فیلتری که برای زیرشبکه LAN نوشته شده هرگز با بسته‌ای که با نشانی تونل خارج می‌شود نمی‌خواند.
بخوانید که جست‌وجو واقعاً چه چیزی را انتخاب کرد
تصمیم را چاپ کنید به‌جای اینکه آن را استنباط کنید. فرمان زیر مسیری را حل می‌کند که هسته برای آن مقصد به کار می‌برد، از جمله رابط و مبدأیی که انتخاب می‌کرد:
ip route get 10.8.0.5 ip route get 10.8.0.5 from 192.0.2.44 ip rule show ip route show table all | sed -n '1,40p'
کارخواهان VPN اغلب قواعد سیاست را در اولویت‌های پایین‌تر از جدول اصلی نصب می‌کنند، بنابراین یک جدول اصلی تمیز به‌خودی خود چیزی را ثابت نمی‌کند. اولویت قواعد را با جدول‌هایی که انتخاب می‌کنند مقایسه کنید و بررسی کنید که آیا مسیر تونل از اتصال دوباره جان سالم به در می‌برد، به‌جای اینکه یک بار دستی افزوده شود.
IPsec مبتنی بر سیاست یک مرحله تطبیق سوم اضافه می‌کند که مسیریابی آن را پوشش نمی‌دهد، همان‌طور که یادداشت‌های ارسال strongSwan برای پیکربندی‌های تونل و انتقال توضیح می‌دهند. سیاست امنیتی ترافیک را بر اساس پیشوند و پروتکل انتخاب می‌کند، در حالی که مسیر فقط تصمیم می‌گیرد بسته بدون‌محافظت کجا می‌رفت. زیرشبکه‌ای که مسیریابی می‌شود اما انتخابگر منطبقی ندارد یا بی‌محافظت می‌ماند یا بسته به پیکربندی دور انداخته می‌شود، و هیچ‌یک از این دو نتیجه شبیه مشکل دیوار آتش نیست. سیاست را چاپ کنید و انتخابگرهای آن را با پیشوندهایی مقایسه کنید که انتظار داشتید تونل حمل کند.
فیلترکردن روی یک قلاب اعمال می‌شود، نه روی یک مسیر
قاعده‌ای که شنونده VPN را مجاز می‌کند قاعده‌ای درباره ترافیکِ خطاب‌شده به خود دروازه است. درباره کارخواهانی که به میزبان‌های پشت آن دروازه می‌رسند چیزی نمی‌گوید، زیرا ترافیک ارسال‌شده از زنجیره دیگری می‌گذرد. خواندن مجموعه قواعد به‌عنوان یک فهرست تخت، دلیل معمول این است که قاعده‌ای درست‌نما هرگز فعال نمی‌شود.
شمارنده‌ها پرسش را سریع روشن می‌کنند. قاعده‌ای با شمار بسته صفر هرگز به آن نرسیده‌اند، که به زنجیره اشتباه، رابط اشتباه یا دورانداختن زودتر اشاره دارد. قاعده‌ای با شمار فزاینده زیر سیاست دورانداختن همان مرزی است که می‌جستید و بسته به‌جای مسیریابی نادرست دور انداخته می‌شود.
یک کاوشگر از همان مسیری بفرستید که کارخواه به کار می‌برد
آزمون‌هایی که روی خود دروازه اجرا می‌شوند از خروج و ورود با نشانی مبدأ خود دروازه می‌گذرند. این مسیری متفاوت از درخواست ارسال‌شده کارخواه است، بنابراین یک curl محلی موفق کمتر از آنچه به نظر می‌رسد را ثابت می‌کند. از ماشینی که شکست می‌خورد آزمایش کنید یا رابط و مبدأ را صریحاً تثبیت کنید.
nc -vz -w 3 10.8.0.5 443 ping -c 3 -W 1 10.8.0.5 tcpdump -ni any host 10.8.0.5 and port 443 iptables -vnL FORWARD --line-numbers nft list ruleset | sed -n '1,60p'
ضبط در هر دو سر، موارد باقی‌مانده را جدا می‌کند. SYN که کارخواه را ترک می‌کند و هرگز نمی‌رسد یعنی مسیریابی، رمزنگاری یا فهرست دسترسی بالادست. SYN که می‌رسد و پاسخی نمی‌گیرد یعنی سرویس یا فیلتر میزبان آن، و تونل هرگز مشکل نبود.
ترافیک بازگشتی مستحق نگاهی جداگانه است. مسیریابی نامتقارن به‌همراه فیلترکردن مسیر معکوس پاسخ‌هایی را که روی رابط اشتباه می‌رسند دور می‌اندازد، که به‌صورت اتصال یک‌طرفه و نه درگاه مسدود دیده می‌شود. پیش از سرزنش دیوار آتش برای نشانه‌ای که آن را ایجاد نکرده است، مقدار sysctl را بررسی کنید.
ثبت وقایع به‌عنوان نظر دوم کار می‌کند، نه گام اول. یک دستور ثبت موقت روی زنجیره ارسال، رابط و نشانی‌هایی را که به آن خورده‌اند نام می‌برد و بعداً آسان حذف می‌شود. اگر آن را دائمی بگذارید، به‌جای پاسخ یک مشکل حجم گزارش ساخته‌اید.
هر تغییر را جایی بگذارید که از اتصال دوباره جان سالم به در ببرد
مسیری که با ip route add افزوده شده تا وقتی رابط پایین بیاید زنده است. به‌جای آن در نمایه اتصال ذخیره کنید: NetworkManager مسیرهای اضافی روی اتصال را می‌پذیرد و netplan آن‌ها را در میان راه‌اندازی‌ها نگه می‌دارد. همین قاعده برای استثنای دیوار آتش سمت کارخواه صادق است که پس از بارگذاری دوباره بعدی از میان می‌رود.
قواعد سمت سرور به فایل پیکربندی تعلق دارند که سرویس هنگام شروع بار می‌کند، نه به نشستی تعاملی که با بستن آن پایان می‌یابد. قاعده را بنویسید، دوباره بار کنید و تأیید کنید که شمارنده جابه‌جا شده است، زیرا بارگذاری دوباره‌ای که نحو را رد کرده باشد، بی‌صدا مجموعه قواعد قدیمی را سر جای خود می‌گذارد.
سپس درخواست اصلی برنامه را از ابتدا تا انتها تکرار کنید و ثبت کنید کدام لایه تغییر کرد. تعمیر مسیری که به تغییر فیلتر هم نیاز داشت باز هم شکست می‌خورد، و شکست دوم وقتی بدانید اولی رفته بسیار آسان‌تر خوانده می‌شود. تاریخ و نسخه کارخواه را کنار نتیجه بنویسید، چون پیش‌فرض‌های مسیریابی و فیلترکردن هر دو میان انتشارها جابه‌جا می‌شوند. آن یادداشت را روی تیکت نگه دارید تا نفر بعدی از همان‌جا شروع کند که شما ایستادید، نه اینکه راه دو مرحله‌ای را تکرار کند.