VPN مسیریابی‌شده یا پل‌دار: بر اساس آنچه کلاینت باید به آن برسد انتخاب کنید

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

دو درخواست که پشت باجه یکسان به نظر می‌رسند

نیاز کارمند یک سرویس است که از طریق IP و از دستگاهی که شما کنترلش نمی‌کنید قابل دسترسی باشد. نیاز مهندس در سطح لینک است: ابزار انتظار دارد فریم‌های Ethernet و کشف پخش را ببیند، و شاید DHCP از سگمنتی که فکر می‌کند در آن است.

این‌ها پرسش‌های متفاوتی هستند و پاسخ دادن به هر دو با یک پل، دسترسی کارمند را بی‌دلیل به کل LAN دفتر گسترش می‌دهد.

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

یک مسیر از عضویت در LAN باریک‌تر است

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

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

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

پل پرسش پذیرش را تغییر می‌دهد

پل‌سازی یک اینترفیس فیزیکی و یک دستگاه TAP را در یک سوئیچ نرم‌افزاری ترکیب می‌کند، بنابراین دستگاه‌های راه دور به همان دامنه پخش می‌پیوندند. این یک توانایی واقعی و یک ریسک واقعی است: دستگاه راه دور دیگر مهمان مسیریابی‌شده نیست، بلکه مشارکت‌کننده است.

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

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

فیلتر کردن در هر دو توپولوژی وجود دارد

پل ذاتاً غیرقابل فیلتر نیست و مسیر ذاتاً امن نیست. فیلتر پل در Linux قلاب‌ها و نحو قواعد خودش را دارد و قاعده‌ای که برای ارسال IP مسیریابی‌شده نوشته شده، به‌طور خودکار بر فریم‌های پل‌شده اعمال نمی‌شود.

پیش از وعده دادن یک مرز، بررسی کنید که پلتفرم واقعاً از چه چیزی پشتیبانی می‌کند:

bridge link show
nft list ruleset

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

مرز را با سه تلاش اثبات کنید

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

مسیر مجاز و مسیر ردشده را از همان کلاینت اجرا کنید و هر دو را ثبت کنید:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

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