مسیریابی سیاستی OpenWrt: زنجیرهای که DNS محلی را میگیرد
پرس‌وجوهای کلاینت‌ها و پرس‌وجوهای خود روتر از قلاب‌های متفاوتی وارد می‌شوند. سیاستی که به prerouting نشانه رفته، هر پرس‌وجوی LAN را حمل می‌کند و روتر را روی uplink ارائه‌دهنده می‌گذارد.
کلاینت‌های LAN از طریق تونل حل می‌کنند و پرس‌وجوهای خود روتر بی‌صدا این کار را نمی‌کنند. به‌روزرسانی بسته‌ها، همگام‌سازی زمان و DNS پویا همه از uplink معمولی خارج می‌شوند، در حالی که هر پرس‌وجوی ارسال‌شده VPN را میگیرد، و هیچ چیز در رابط کاربری نشان نمی‌دهد که دو مسیر متفاوت وجود دارد. توضیح، باگ در سیاست نیست بلکه پرسش این است که کدام قلاب بسته را می‌بیند. دو جریان، یک نشانی resolver، و تنها یکی از آن‌ها از روتر عبور می‌کند. جدا کردن این دو، تمام درمان است.
دو جریان، یک نشانی resolver
جریان اول همان است که مردم تصور می‌کنند. کلاینت از resolver روتر می‌پرسد، resolver به بالادست ارسال می‌کند، و آن بستهٔ ارسال‌شده هنگام خروج از روتر عبور می‌کند. آن بسته برای هر چیزی که ترافیک ارسال‌شده را رصد می‌کند قابل مشاهده است.
جریان دوم هرگز از جایی نمی‌رسد. روتر آن را می‌سازد، پس بستهٔ ورودی و مرحلهٔ ارسال برای تطبیق وجود ندارد.
هر دو ممکن است یک نشانی resolver را هدف بگیرند، و دقیقاً به همین دلیل تفاوت به‌سادگی از چشم می‌افتد. مقصد یکسان، مبدأ متفاوت، زنجیرهٔ متفاوت. وقتی مبدأ را ببینید، بقیهٔ تشخیص دنبال می‌شود.
بسته‌های ارسال‌شده و تولیدشدهٔ محلی متفاوت وارد می‌شوند
ترافیک ارسال‌شده وقتی از رابط دیگری می‌رسد ارزیابی می‌شود. بسته‌های مسیریابی سیاستی آن را به‌صورت زنجیرهٔ prerouting نشان می‌دهند، و قاعده‌ای که آنجا گذاشته شود هر بسته‌ای را که از روتر عبور می‌کند می‌بیند. به همین دلیل پرس‌وجوهای کلاینت دقیقاً همان‌طور که سیاست توصیف می‌کند رفتار می‌کنند، و به همین دلیل روتر آن را نادیده میگیرد. قاعده اشتباه نیست، فقط به قلابی بسته شده که روتر هرگز به آن نمی‌رسد. آن را جابه‌جا کنید و همان تطبیق شروع به کار می‌کند.
ترافیک تولیدشدهٔ محلی را فرایندی روی روتر می‌سازد و به‌جای آن به مسیر خروج وارد می‌شود. تصمیم خود روتر آن را مسیریابی می‌کند و تنها وقتی به سیاست می‌رسد که سیاست آن زنجیره را پوشش دهد. نه رابط ورودی برای تطبیق وجود دارد و نه تصمیم ارسالی برای مشاهده.
این ویژگی جایی است که بسته‌ها زاده می‌شوند، نه ویژگی هیچ بستهٔ خاصی. قاعده‌ای که برای یک زنجیره نوشته شده، دربارهٔ دیگری به‌سادگی نظری ندارد. هیچ مقدار تنظیم قاعده این را تغییر نمی‌دهد.
زنجیرهٔ خروج را انتخاب کنید، سپس تطبیق را محدود کنید
درمان این است که همان قصد را به زنجیرهٔ خروج هم ببندید، یا وقتی پرس‌وجوهای خود روتر برایتان مهم است قاعده را به آنجا منتقل کنید. در چیدمانی از OpenWrt که روی بستهٔ مسیریابی سیاستی ساخته شده، این یعنی در تنظیم زنجیرهٔ قاعده به‌جای prerouting گزینهٔ output را انتخاب کنید. اگر هر دو گروه به پوشش نیاز دارند هر دو قاعده را نگه دارید.
سپس تطبیق قاعده را محدود کنید. نشانی‌های resolver مقصد روی پورتی که resolver واقعاً استفاده می‌کند تصمیم بسیار کوچک‌تری از فرستادن هر چیزی است که روتر تولید می‌کند به تونل.
دو قاعده را صریح نگه دارید به‌جای اینکه بخواهید یکی بنویسید که هر دو زنجیره را پوشش دهد. قاعده‌های جدا خواناترند و به شما اجازه می‌دهند هنگام اشکال‌زدایی مسیر روتر را بدون مختل کردن ترافیک کلاینت غیرفعال کنید. همچنین شمارنده‌ها را یک‌به‌یک معنادار می‌کنند.
انتقال خود تونل را از قاعده بیرون نگه دارید
اتصال بیرونی تونل هم توسط روتر ساخته می‌شود. قاعده‌ای که همهٔ ترافیک تولیدشدهٔ محلی را به تونل بفرستد، تونل را از خودش عبور می‌دهد و اصلاً بالا نمی‌آید.
دسترسی مدیریت دومین قربانی است. نشست‌های مدیریتی که از روتر شروع می‌شوند، یا پاسخ‌های آن‌ها، می‌توانند با قاعده‌ای محلی و بیش‌ازحد گسترده به تونل کشیده شوند و از LAN دست‌نیافتنی شوند.
نقطهٔ پایانی تونل را از تطبیق کنار بگذارید و قاعده را محدود به نشانی‌های resolver نگه دارید. این برای نیاز DNS کافی است و به‌قدر کافی کوچک است که دربارهٔ آن استدلال شود.
هر دو گروه را آزمایش کنید، نه یکی را
تماشا کنید که روتر پرس‌وجوی خودش را می‌کند و یادداشت کنید کدام رابط آن را برد. جست‌وجو را از میزبان LAN تکرار کنید و مسیری را که طی کرد یادداشت کنید. شمارنده‌های روی قاعده‌های سیاست هر دو پاسخ را بدون حدس زدن آشکار می‌کنند.
نتایج را دو یافتهٔ جدا در نظر بگیرید. کلاینتی که از طریق تونل حل می‌کند چیزی دربارهٔ روتر نمی‌گوید، و روتری که درست حل می‌کند چیزی دربارهٔ کلاینت روی شنوندهٔ دیگر نمی‌گوید. آن‌ها را به‌صورت خطوط جدا در سابقهٔ تغییر بنویسید.
پورت را هم بررسی کنید: قاعده‌ای که پورت مقصد 53 را تطبیق می‌دهد، resolverی را که از طریق DNS over TLS روی 853 یا نقطهٔ پایانی HTTPS به آن می‌رسد از دست می‌دهد. انتقالی را تطبیق دهید که upstream پیکربندی‌شده واقعاً استفاده می‌کند، و نشتی به دلیل درست بسته می‌شود.