Redsocks روی loopback گوش می‌دهد اما ترافیک VPN هرگز نمی‌رسد

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

بسته تغییرمسیر‌یافته واقعاً کجا فرود می‌آید

پروکسی شفاف روی دروازه از REDIRECT در جدول nat در PREROUTING استفاده می‌کند تا مقصد یک اتصال ورودی را به پورت محلی بازنویسی کند. مقصد بازنویسی‌شده آدرس محلی است آن‌گونه که واسطی که بسته از آن رسیده می‌بیند، نه آدرس loopback فرآیندی که جای دیگری راه‌اندازی شده است. شنونده‌ای که فقط به 127.0.0.1 متصل است اتصالاتی را می‌پذیرد که از قبل روی میزبان محلی بودند، و دقیقاً همین حالت است که وقتی ترافیک تونل شکست می‌خورد همچنان کار می‌کند. loopback خود کارخواه آدرس سومی است و هرگز هدف قاعده دروازه نیست.

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

شنونده و قاعده تغییرمسیر را با هم بخوانید

جدول سوکت و قواعد nat را در یک گذر چاپ کنید، چون قاعده‌ای که به پورتی اشاره می‌کند که مالک ندارد دقیقاً مثل قاعده‌ای است که به آدرس اشتباه اشاره می‌کند. sudo ss -ltnp | grep redsocks آدرس اتصال و فرآیند مالک را نشان می‌دهد. sudo iptables -t nat -S PREROUTING هدف REDIRECT را نشان می‌دهد، و sudo iptables -t nat -L PREROUTING -v -n نشان می‌دهد آیا چیزی با آن مطابقت داشته است.

پرش به زنجیره کاربری به نام REDSOCKS هیچ کاری نمی‌کند مگر اینکه آن زنجیره وجود داشته باشد و استثناهای موردنظر و کنش REDIRECT را حمل کند. زنجیره‌ای را که به آن پرش می‌شود با sudo iptables -t nat -S REDSOCKS بخوانید، نه اینکه فرض کنید نام کار را انجام می‌دهد.

سپس دو مقدار را مقایسه کنید. اگر قاعده به آدرس دروازه روی پورت 12345 تغییرمسیر دهد و شنونده 127.0.0.1:12345 گزارش کند، ناهمخوانی شکست را بدون هیچ تشخیص بیشتری توضیح می‌دهد.

تنگ متصل شوید، سپس محدود کنید چه چیزی می‌تواند به آن برسد

پیکربندی نمونه بالادست شنونده را به دلیلی خوب به loopback می‌گذارد: پروکسی شفاف اتصالات را به نمایندگی از هر کسی که بتواند به آن برسد می‌پذیرد. تغییر اتصال به 0.0.0.0 تحویل را درست می‌کند و همزمان پورت را روی هر واسط باز می‌کند، که تغییری امنیتی است، نه تعمیری بی‌طرف. ترجیح دهید به آدرس محلی مشخصی که تغییرمسیر هدف گرفته متصل شوید و پورت را روی واسط‌های غیرقابل‌اعتماد بسته نگه دارید. اگر اتصال گسترده‌تر اجتناب‌ناپذیر است، قاعده دیوار آتش میزبان اضافه کنید که فقط محدوده مبدأ تونل و ترافیک محلی خود دروازه را مجاز می‌کند.

باز کردن پورت روی واسط عمومی هرگز برای ترافیک VPN تغییرمسیر‌یافته لازم نیست، چون اتصال پس از بازنویسی به‌صورت محلی پایان می‌یابد. پروکسی را برای کارکردن یک تغییرمسیر محلی در معرض اینترنت قرار ندهید.

آن را با اتصال تازه از یک کارخواه اثبات کنید

از یک کارخواه واقعی VPN با اتصال TCP تازه آزمایش کنید، نه از یک پوسته روی دروازه. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com روی کارخواه مسیر تغییرمسیر‌یافته را سرتاسر می‌آزماید.

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

در پایان به یاد داشته باشید این مسیر چه چیزی را پوشش نمی‌دهد. تغییرمسیر معمول TCP در redsocks، UDP، QUIC یا DNS را به ترافیک SOCKS تبدیل نمی‌کند، و مقصدهای خصوصی معمولاً به استثناهای صریح نیاز دارند. یک آزمایش محلی موفق فقط مسیر loopback را اثبات می‌کند که هرگز مشکل نبود.