آیا کلاینت VPN روی وبسرور شما پاسخهایش را خراب میکند؟

سایت از یک لپتاپ در همان شبکه بارگذاری میشود و از هر جای دیگر با پایان مهلت مواجه میشود، و میزبان همچنین یک کلاینت VPN برای ترافیک خروجی خودش اجرا میکند. این ترکیب خرابی مشخصی پدید میآورد: اتصال ورودی میرسد، پاسخ از مسیر اشتباه خارج میشود و کلاینت بیرون هرگز پاسخی نمیبیند. هر دو نیمه در یک ضبط بسته دیده میشوند، پس ترتیب رویدادها بخشی است که ارزش خواندن دارد.

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

نشانه: بهصورت محلی پاسخ میدهد و از بیرون نه

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

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

هنگام کار یک مسیر مدیریتی مستقل باز نگه دارید. قاعدهای که نشست SSH خودتان را میشکند، اصلاح ده دقیقهای را به یک بازدید فیزیکی تبدیل میکند.

انتخابگر مبدأ در واقع چه چیزی را تطبیق میدهد

در مسیریابی سیاستی لینوکس، قاعدهای مانند from 192.168.50.2 بستههایی را تطبیق میدهد که مبدأشان آن نشانی است. این قاعده رمزگذاری نمیکند که بسته گفتوگویی را ادامه میدهد که از روتر خانه وارد شده، و نمیداند کدام فرایند آن را ساخته است. نشانی در آن مثال نمونه است؛ نشانیای را جایگزین کنید که میزبان شما واقعاً استفاده میکند. خط را بیانیهای درباره نشانیها بدانید و نه بیشتر.

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

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

مسیر بازگشت و ترافیکی را که قصدش را نداشتید بررسی کنید

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

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

سپس یک اتصال خارجی تازه و بهطور جداگانه درخواستی را بپذیرید که هنوز باید از VPN خارج شود. اگر دومی اکنون مستقیم خارج میشود، استثنا از مشکلی که حل میکردید گستردهتر است و آزمون مهم همانی است که قصد تغییرش را نداشتید.

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

تصمیم بگیرید استثنا چقدر میتواند باریک باشد

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

قراردادی را که به آن تکیه میکنید ثبت کنید: نگاشت عمومی، نشانی میزبانی که درخواست به آن تحویل داده میشود، و مسیری که انتظار میرود پاسخ طی کند. سرویس ورودی که از طریق ارائهدهنده VPN منتشر میشود قراردادی متفاوت از سرویسی است که از طریق روتر خانه منتشر میشود، و استثنایی که از یک مثال کپی شده اغلب برای دیگری نادرست است.

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