مسیریابی تنها یک سرویس وب محلی دور از VPN بر اساس پورت

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

پیش از نوشتن قاعده سه شرط را بررسی کنید

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

شرط دوم سیاست است نه مکانیک. هر مسیری که تونل را دور بزند استثنایی بر هدف تونل است، و روی میزبان مدیریت‌شده آن تصمیم از آنِ صاحب سیاست است، نه کسی که یک مهلت زمانی را اشکال‌زدایی می‌کند.

پاسخ را تطبیق دهید، نه پورت مقصد کلاینت را

پاسخ سروری که روی TCP 443 گوش می‌دهد با پورت مبدأ 443 از میزبان خارج می‌شود. مرورگری روی همان میزبان هنگام اتصال به یک سایت HTTPS دوردست یک پورت مبدأ گذرا و پورت مقصد 443 می‌فرستد. هر دو ترافیک پورت 443 هستند و فقط یکی از آن‌ها باید جدول WAN را بردارد، به همین دلیل تطبیق پورت مقصد نیمهٔ اشتباه را می‌گرفت.

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

پیش از آن‌که قاعده به آن اشاره کند یک جدول بازگشت کامل بسازید

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

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

شماره‌ها را از میزبان زنده بخوانید نه اینکه کپی کنید. ip -4 rule show می‌گوید کدام اولویت‌ها گرفته شده‌اند، و افزودن قاعده روی اولویتی که از قبل وجود دارد بی‌صدا ترتیب دو قاعده‌ای را تغییر می‌دهد که هر کدام به‌تنهایی درست به نظر می‌رسند.

دو انتخابگر کار واقعی را اینجا انجام می‌دهند. iif lo روشی است که هسته بسته‌های تولیدشدهٔ خود میزبان را گزارش می‌کند، پس قاعده نمی‌تواند به‌طور تصادفی ترافیک فورواردشدهٔ ورودی از بیرون را بگیرد. ipproto tcp sport 443 آن را به یک پروتکل انتقال و یک پورت محدود می‌کند، که به‌قدری که نیاز اجازه می‌دهد تنگ است. انتخابگر پروتکل را بردارید و قاعده UDP 443 را هم می‌گیرد، که سرویس دیگری با رفتار دیگر است.

پاسخ‌های خصوصی را داخل تونل نگه دارید

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

ip -4 route add table 100 throw 10.90.0.0/24

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

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

TCP را تست کنید، سپس QUIC، سپس یک ری‌استارت

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

HTTP/3 روی UDP سرو می‌شود و با قاعدهٔ TCP تطبیق داده نمی‌شود، پس شنوندهٔ QUIC به انتخابگر خودش نیاز دارد وگرنه تا وقتی HTTPS کار می‌کند همچنان از تونل استفاده خواهد کرد. هر قاعده‌ای که بر آن توافق کردید را در مؤلفه‌ای که رابط را در اختیار دارد ذخیره کنید، و پس از اتصال دوباره یا تمدید DHCP آن‌ها را تأیید کنید. وقتی مدیری رقیب پس از ری‌استارت یک مسیر زمان اجرا را حذف می‌کند، این مشکل مالکیت است که باید در منبع حل شود، نه دلیلی برای افزودن قواعد NAT گسترده‌تر روی آن.