آیا پروکسی پس از اتصال دوباره VPN هنوز روی نشانی قدیمی تونل است؟
اتصال دوباره می‌تواند ارسال‌کننده شما را به نشانی‌ای گره بزند که تونل دیگر مالک آن نیست. چهار بررسی مرتب، یک تحویل شماره‌دار و یک درخواست آزمایشی واقعی.
راه‌اندازی مجدد کلاینت VPN فقط ثابت می‌کند که تونل برگشته است. هیچ چیزی درباره پروکسی‌ای که به آن گفته شده بود از طریق تونل خارج شود نمی‌گوید. Squid و tinyproxy و بیشتر ارسال‌کننده‌های دیگر نشانی مبدأ محلی را که هنگام شروع حل کرده‌اند نگه می‌دارند تا چیزی آن‌ها را مجبور به بارگذاری دوباره کند. وقتی اتصال دوباره نشانی تونل تازه‌ای می‌دهد، ارسال‌کننده یا در هر اتصال خروجی شکست می‌خورد، یا شروع می‌کند از مسیر معمول شما خارج شدن.
شکست دوم خطرناک است: تونل برقرار است، صفحه‌ها بارگذاری می‌شوند و فقط نشانی خروج اشتباه است.
از شنونده شروع کنید، نه از تونل
سه نشانی در کار است و اتصال دوباره فقط بعضی از آن‌ها را جابه‌جا می‌کند. شنونده جایی است که مرورگر شما به آن اشاره می‌کند، معمولاً 127.0.0.1 یا یک نشانی شبکه محلی، و برایش مهم نیست که تونل تغییر کرده است. مبدأ محلی خروجی چیزی است که ارسال‌کننده هنگام شماره‌گیری گام بعدی از هسته می‌خواهد استفاده کند، و به دستگاه تونل گره خورده است. خروج عمومی چیزی است که یک وب‌سرور ثبت می‌کند، و می‌تواند نشانی‌ای ترجمه‌شده چند گام دورتر باشد.
جست‌وجوی IP عمومی فقط به پرسش آخر پاسخ می‌دهد. نمی‌تواند بگوید ارسال‌کننده باید به کدام نشانی محلی گره بخورد، چون یک خروج عمومی می‌تواند چند مبدأ داخلی را پنهان کند. نشانی را از کسی بخوانید که اتصال را در اختیار دارد: خروجی وضعیت کلاینت، خود واسط، یا فضای نامی که تونل در آن زندگی می‌کند. گرفتن نخستین واسطی که نامش شبیه تونل است، به‌محض وجود پروفایل دوم پاسخ نادرست می‌دهد.
چیدمان‌های کانتینر و فضای نام این فرض را بی‌صدا می‌شکنند. ارسال‌کننده در یک فضای نام شبکه نمی‌تواند به تونلی که در فضای دیگری است گره بخورد، و هیچ مقدار ویرایش پیکربندی آن را درست نمی‌کند.
چهار بررسی پیش از ویرایش هر چیز
این‌ها را به ترتیب انجام دهید. نخستین بررسی‌ای که شکست می‌خورد جایی است که می‌ایستید، چون بعدی‌ها فرض می‌کنند قبلی‌ها برقرارند.
- تأیید کنید که تونل در استفاده همان پروفایلی است که پروکسی بر گرد آن ساخته شده، نه پروفایل دومی که خودش وصل شده است.
- نشانی‌ای که اکنون روی آن دستگاه است را چاپ کنید و آن را با نشانی در پیکربندی در حال اجرا مقایسه کنید.
- از ارسال‌کننده بپرسید چه مبدأیی را حل کرده، نه آنچه پرونده روی دیسک ادعا می‌کند.
- تأیید کنید که ترافیک ارسال‌کننده واقعاً تابع سیاست مسیریابی و دیوار آتشی است که انتظار دارید.
نشانی دستگاه آسان است: ip -4 addr show dev tun0 نشانی کنونی را چاپ می‌کند و ip -4 route get 1.1.1.1 نشان می‌دهد هسته برای آن مقصد کدام واسط را انتخاب می‌کند. ارسال‌کننده‌ای که به نشانی دقیق گره می‌خورد وقتی نشانی ناپدید شود با صدای بلند شکست می‌خورد. ارسال‌کننده‌ای که به دستگاه گره می‌خورد یا به مبدأ پیش‌فرض برمی‌گردد، به کار ادامه می‌دهد و نشت می‌کند، و این نتیجه بی‌صداست.
مستندات را با نسخه‌ای که اجرا می‌کنید تطبیق دهید، نه با نخستین نتیجه جست‌وجو. دستور نشانی خروجی Squid برای v7 و پیش‌تر مستند شده است، و مستندات v8 صریح می‌گوید که آن دستور در آنجا در دسترس نیست، پس اسکریپتی که بر گرد آن ساخته شود از این مرز جان سالم به در نمی‌برد (به مرجع Squid tcp_outgoing_address نگاه کنید). پیش از بارگذاری دوباره هر چیز، با تحلیل‌گر خود محصول اعتبارسنجی کنید: squid -k parse خطاها را گزارش می‌کند و بدون دست زدن به فرایند در حال اجرا خارج می‌شود.
هر تونل را شماره‌دار کنید و جابه‌جایی‌های کهنه را دور بریزید
اتصال دوباره یک تحویل است و تحویل به ترتیب نیاز دارد. هر اتصال مشاهده‌شده را با شمارنده یا مهر زمانی که با هر برقراری موفق زیاد می‌شود علامت بزنید، سپس آن برچسب را درون پیکربندی نامزد حمل کنید. وقتی برچسب یک نامزد از برچسب کنونی قدیمی‌تر است، نامزد را دور بریزید نه اینکه اعمالش کنید، چون به‌روزرسانی کندی که برای تونل پیشین نوشته شده وگرنه تنظیمات تونل کنونی را بازنویسی می‌کند. انبوه رویدادها را یکی کنید تا پیوندی که نوسان می‌کند یک گذار تولید کند نه پانزده تا.
کار را در چهار حرکت مرتب کنید: وضعیت خروج کهنه را باطل کنید، منتظر بمانید که صاحب اتصال تکمیل را گزارش دهد، فقط بخش مدیریت‌شده را بسازید، سپس از طریق مدیر سرویس اعتبارسنجی و فعال کنید. بازتولید کل پرونده از دو مقدار نشانی همان راهی است که محدودیت‌های شنونده، احراز هویت و سیاست مقصد بی‌صدا ناپدید می‌شوند. به توقف عمدی هم احترام بگذارید. کمکی که همچنان تونلی را شماره می‌گیرد که کاربر خاموشش کرده، باگ است نه تاب‌آوری.
سوکت‌های باز نشانی تازه را دنبال نمی‌کنند
پیکربندی دوباره ارسال‌کننده هیچ چیزی درباره اتصال‌هایی که پیش‌تر برقرار شده‌اند نمی‌گوید. اینکه تخلیه شوند یا بمیرند به محصول بستگی دارد، پس رفتار را مشاهده کنید نه اینکه فرضش کنید.
درخواستی که از سوکتی باز پیش از جابه‌جایی سرو شود همچنان از مسیر کهنه خارج می‌شود، حتی وقتی پیکربندی تازه درست است. اگر این مهم است صریح تصمیم بگیرید: پنجره تخلیه کوتاهی بدهید و پذیرش کار تازه را متوقف کنید، یا سوکت‌های کهنه را ببندید و خطاها را بپذیرید. سپس با اتصال تازه آزمایش کنید و آن نتیجه را از بررسی تخلیه جدا نگه دارید. گره خوردن به مبدأ هم مرز امنیتی نیست. وقتی ترافیک هرگز نباید مسیر معمول را لمس کند، آن را با نشانه‌ها و قواعد دیوار آتش، شامل DNS و IPv6، تحمیل کنید تا بارگذاری دوباره ناموفق پروکسی را صریحاً خاموش بگذارد نه باز.
خروج تازه را با یک درخواست تازه ثابت کنید
آنچه مهم است درخواستی است که پس از فعال‌سازی باز شود، نه ping و نه صفحه‌ای که پیش‌تر در حافظه پنهان بوده. از پروکسی یک URL واقعی بخواهید و نشانی خروجی را که طرف دور گزارش می‌دهد بخوانید، سپس وقتی ارائه‌دهنده یکی را نشان می‌دهد آن را با دید خود کلاینت از تونل مقایسه کنید.
تحلیل، بارگذاری دوباره و درخواست را فرمان‌های جدا نگه دارید تا شکست به یک گام اشاره کند. دو مورد نخست وقتی شکست می‌خورند چیزی را تغییر نمی‌دهند، و دقیقاً به همین دلیل پیش از راه‌اندازی مجدد اجرا می‌شوند.
squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.comاگر بارگذاری دوباره شکست خورد، سرویس را متوقف کنید و بخش را تعمیر کنید؛ پروکسی‌ای که با خروج کهنه سرو می‌دهد از یک قطع کوتاه بدتر است. اگر بارگذاری دوباره موفق شد اما درخواست تازه هنوز جایی غیرمنتظره خارج می‌شود، به جای ویرایش دوباره نشانی‌ها به بررسی مسیریابی برگردید. نسل تونلی را که در برابر آن اعتبارسنجی کردید ثبت کنید تا اتصال دوباره بعدی چیزی مشخص برای مقایسه داشته باشد.