VPN وصل است اما فایروال هنوز مسدود می‌کند: چطور بفهمیم کدام‌یک

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

مسیر را از سیاست جدا کنید

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

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

مسیر را در یک گذر بخوانید

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

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

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

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

سیاست را در لایه‌ای بخوانید که پاسخ می‌دهد

وقتی مسیر درست شد، سیاست را از میزبان به بیرون بپیمایید و به تنها لایه‌ای توجه کنید که شمارنده‌هایش حرکت می‌کند:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

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

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

وقتی تورل همان‌جا تمام می‌شود، تصمیم دروازه را بخوانید

در دروازهٔ سایت-به-سایت یا دسترسی راه‌دور، VPN کاربر را احراز هویت می‌کند و سیاست منبع را مجاز می‌کند، و این‌ها مجوزهای جداگانه‌اند. کاربری که به تورل راه یافته، به‌طور خودکار به هر میزبان داخلی راه ندارد، و رد اغلب از یک قاعدهٔ ارسال می‌آید در حالی که خود تورل سالم است. همین جداسازی در IPsec دیده می‌شود، جایی که سیاست امنیتی انتخاب‌کنندهٔ ترافیک از فیلتری که آن را می‌پذیرد متفاوت است، و به همین دلیل هر دو به‌عنوان سازوکارهای متفاوت در RFC 4301.

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

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

باریک‌ترین لایه را تغییر دهید، سپس بررسی کنید

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

با همان آزمونی که شکست خورد، از همان کلاینت بررسی کنید، و سپس یک بار دیگر پس از اتصال دوباره، چون قاعده‌ای که پیش از مذاکرهٔ دوبارهٔ تورل می‌خواند ممکن است بعد از آن دیگر نخواند:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

پیش از بستن آن:

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