می‌خواهید ترافیک پروکسی SOCKS از VPN خارج شود و بقیه میزبان مسیر عادی خود را حفظ کند. دو طراحی این کار را می‌کنند و در این تفاوت دارند که وقتی چیزی اشتباه می‌شود چه چیزی می‌شکند. یکی مسیر پیش‌فرض را به تونل هل می‌دهد و بعد از آن دور می‌زند؛ دیگری جدول اصلی را دست‌نخورده می‌گذارد و یک نشانی مبدأ را به جدول دوم می‌فرستد. دومی پاکیزه‌تر است و تله‌های خودش را دارد.

دو طراحی، دو شعاع خرابی متفاوت

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

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

این باریکی همان محدودیت هم هست: طراحی فقط وقتی کار می‌کند که بسته‌های خروجی پروکسی واقعاً آن نشانی را حمل کنند.

تنظیم external در Dante چه می‌کند

تنظیم external نشانی‌هایی را انتخاب می‌کند که پروکسی برای اتصال‌های خروجی به کار می‌برد؛ به سیاست مسیریابی هسته دست نمی‌زند. همین جداسازی طراحی دوم را ممکن می‌کند و درست همین‌جاست که مردم مستندات را اشتباه می‌خوانند. نشانه‌رفتن external به یک نشانی تونل باعث می‌شود پروکسی اتصال‌هایش را از آن نشانی مبدأ بگیرد و سپس جدول مسیریابی تصمیم می‌گیرد آن بسته‌ها کجا بروند.

شنونده موضوعی جداست. internal را به کلاینت‌هایی محدود کنید که باید از پروکسی استفاده کنند، احراز هویت را الزامی کنید و درگاه را با فایروال ببندید، چون شنونده باز ویژگی خروج VPN نیست.

تأیید کنید که نشانی پیکربندی‌شده واقعاً در فضای نام شبکه پروکسی به تونل تعلق دارد.

ساختن جدول انتخاب‌شده بر اساس مبدأ

برای نشانی TUN برابر 10.90.0.2/24 با همتایی قابل دسترس در 10.90.0.1، و شماره جدولی که چیز دیگری از آن استفاده نمی‌کند، چیدمان چنین است:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

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

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

کجا قاعده مبدأ نشت می‌کند

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

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

IPv6 به قواعد و مسیرهای خودش نیاز دارد، چون چیدمان IPv4 چیزی درباره‌اش اثبات نمی‌کند.

بر اساس شکستی که می‌توانید تحمل کنید انتخاب کنید

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

هر کدام را که انتخاب کردید، از هر دو سو بررسی کنید: درخواستی از طریق پروکسی و درخواستی مستقیم از میزبان، با ثبت نشانی خروج مشاهده‌شده برای هر یک.

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

مقالات مرتبط