مسیریابی یک حساب لینوکس از طریق OpenVPN با قاعده UID

مسیریابی مبتنی بر حساب زمانی مناسب است که هر سوکت IPv4 متعلق به یک کاربر لینوکس باید از یک تونل موجود خارج شود، و زمانی مناسب نیست که به جداسازی در سطح برنامه نیاز دارید. این روش بر پایه UID انتخاب می‌کند، پس هر چیزی که با آن حساب اجرا شود در دامنه است، از جمله کار دسته‌ای که فراموش کرده‌اید. پیش از آنکه به یک ip rule دست بزنید، این پرسش را روشن کنید.

مثال زیر یک حساب مرورگر اختصاصی در UID 1500، یک دستگاه تونل tun-office با نشانی محلی 10.80.0.11 و یک VPN را فرض می‌کند که مقصدهای مورد بحث را مجاز می‌داند. خود دیمن بیرون از آن UID اجرا می‌شود.

سه شرطی که سازوکار را انتخاب می‌کنند

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

اشتباهی که باید از آن پرهیز کرد این است که فرض کنیم راه‌انداز مالک را تعیین می‌کند. مرورگری که نشست کاربر دیگری نشانی به آن داده است، سوکتی زیر UID 1500 نساخته است و هیچ قاعده‌ای ترافیکی را که تولید می‌کند جابه‌جا نمی‌کند.

جدول، قاعده و نگهبان

پس از بررسی قاعده‌های موجود و انتخاب شماره‌های بلااستفاده جدول و اولویت، چیدمان کوتاه است: یک مسیر پیش‌فرض در جدول اختصاصی که نشانی مبدأ تونل را حمل می‌کند، قاعده‌ای که جست‌وجوهای حساب را به آن جدول می‌فرستد و قاعده‌ای پایانی که مسیر جایگزین را مسدود می‌کند. در نوشتار، این یک جایگزینی مسیر idempotent است، ip -4 route replace default dev tun-office src 10.80.0.11 table 51820، و پس از آن ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

نگهبان ip -4 rule add priority 12101 uidrange 1500-1500 unreachable است و بیش از آنکه طولش القا می‌کند اهمیت دارد. بدون آن، مسیر گم‌شده در جدول 51820 به پیوند بالادستی معمول می‌افتد و حساب بی‌صدا ترافیکی را نشت می‌دهد که سیاست قرار بود بگیرد. با آن، همان خطا به وقفه زمانی تبدیل می‌شود، یعنی مسدودسازی نه جایگزین.

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

چیزی که مسیریابی UID بیرون می‌گذارد: DNS

دیمن resolver سوکت‌های بالادستی خود را زیر UID خودش باز می‌کند، پس انتخاب 1500 آن پرس‌وجوها را به جدول 51820 منتقل نمی‌کند. یکپارچه‌سازی DNS تصمیمی جداگانه است: حساب را به resolverی که از طریق تونل قابل دسترسی است اشاره دهید، یا بپذیرید که حل نام مسیر میزبان را دنبال می‌کند و ترافیک نه.

پرس‌وجوی loopback به یک stub محلی مدرکی نیست بر اینکه پرس‌وجوی بالادستی از مسیر مرورگر استفاده کرده است، و بارگذاری موفق صفحه از حافظه نهان هم مدرک نیست.

IPv6 در طراحی جمله خودش را می‌خواهد

قاعده‌های بالا تنها IPv4 را پوشش می‌دهند. اگر نیاز یک تونل IPv4 بدون IPv6 مستقیم از این حساب است، قاعده پایانی بازبینی‌شده‌ای مانند ip -6 rule add priority 12101 uidrange 1500-1500 unreachable اضافه کنید، سپس قاعده‌های پیشین IPv6 و استثناهای loopback را که می‌خواهید نگه دارید بررسی کنید.

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

با حساب واقعی بررسی کنید و سپس چرخه عمر را بر عهده بگیرید

جست‌وجوها را مقایسه کنید: ip -4 route get 198.51.100.25 uid 1500 با همان مقصد با یک UID معمولی. سپس درخواستی مجاز زیر حساب اختصاصی انجام دهید و نشانی مبدأیی را که سر دور می‌بیند بررسی کنید. نشانی مبدأ ترجیحی source NAT نیست و بر برنامه‌ای که چیز دیگری را مقید می‌کند چیره نمی‌شود. اگر هر دو جست‌وجو یک مسیر برگردانند، قاعده آنچه فکر می‌کنید را انجام نمی‌دهد.

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