پل TAP ایزوله بین دو برد از طریق OpenVPN

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

مسیر زیر اتصال TAP احراز‌شده بین دو رایانه لینوکس، یک پورت سیمی اختصاصی برای هر میز کار و یک رابط مدیریت که بخشی از آزمایش نیست را فرض می‌کند. ترتیب مهم است: ابتدا فریم‌ها، سپس آدرس‌ها، و در آخر مرز.

پل واقعاً چه چیزی را جابه‌جا می‌کند

پل یک سوئیچ است که در نرم‌افزار پیاده‌سازی شده است. یاد می‌گیرد کدام آدرس MAC پشت کدام پورت عضو ظاهر می‌شود و فریم‌ها را بین اعضا ارسال می‌کند بدون اینکه به جدول مسیریابی IP مراجعه کند. هیچ‌چیز در آن توصیف شامل زیرشبکه، دروازه یا مسیر پیش‌فرض نیست، به همین دلیل فعال‌کردن ارسال IP این اتصال را تولید نمی‌کند و به همین دلیل یک ping می‌تواند موفق شود در حالی که ترافیک دیگر هنوز شکست می‌خورد. یک برد می‌تواند بدون هیچ مسیر پیش‌فرض پیکربندی‌شده به همتای خود برسد، چیزی که کسانی را که انتظار دارند لایه دو مانند لایه سه رفتار کند شگفت‌زده می‌کند.

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

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

نام‌های یکسان روی هر دو رایانه نام‌های محلی‌اند، نه اشیای مشترک. بین میزهای کار یک مسیر Ethernet وجود دارد، بدون کابل دوم و بدون تونل دومی که حلقه را ببندد؛ پلی که ببیند همان MAC روی دو پورت می‌آید با خوشحالی در دایره ارسال می‌کند.

به پل آدرس بدهید، نه به پورت‌های عضو آن

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

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

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

چرا یک پورت اختصاصی برای هر میز کار

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

اتصال یک آداپتور مدیریت، شبکه محلی دفتر را یک تصمیم ارسال از برد توسعه دور می‌کند، و بردی که در لایه دو بدرفتاری می‌کند دقیقاً همان نوع دستگاهی است که در آن قطعه نمی‌خواهید. آداپتور Wi-Fi بدتر است: پل‌کردن یک رابط بی‌سیم در حالت زیرساخت مانند پل‌کردن Ethernet رفتار نمی‌کند و شکست گیج‌کننده است نه تمیز.

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

مرزی که پل ایجاد نمی‌کند

پل‌کردن مسیریابی نیست و ایزوله‌سازی هم نیست. فریم‌هایی که از پل عبور می‌کنند هنوز می‌توانند به قلاب‌های فیلتر میزبان برسند، بسته به مسیر bridge-netfilter نصب‌شده، بنابراین سیاست مؤثر را باید بررسی کرد نه فرض. غیرفعال‌کردن فایروال چون یک فریم گم شده، یک اشکال مشخص را با یک اشکال عمومی معاوضه می‌کند.

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

دو خانواده دیگر شایسته تصمیم صریح هستند. طرح آدرس‌دهی پل را فقط IPv4 نمی‌کند، پس IPv6 و EtherTypeهای دیگر به طرح یا فیلتر خود نیاز دارند. و یک ping موفق هیچ نمی‌گوید درباره اینکه آیا پخش‌های کشف برد، گروه‌های multicast یا فریم‌های jumbo از مسیر عبور می‌کنند، زیرا اینها کلاس‌های ترافیکی متفاوت با پیش‌فرض‌های متفاوت هستند.

در پایان، انتقال و محرمانگی دو خرید متفاوت‌اند. TAP Ethernet را حمل می‌کند؛ سرویس OpenVPN حفاظت پیرامون آن را تأمین می‌کند. یک لایه VXLAN هم Ethernet را حمل می‌کند و به‌خودی‌خود هیچ محرمانگی‌ای فراهم نمی‌کند، پس جایگزین‌کردن یکی با دیگری ویژگی‌های امنیتی را تغییر می‌دهد حتی وقتی نمودار توپولوژی یکسان به نظر می‌رسد.

پایداری و آزمون‌هایی که آن را اثبات می‌کنند

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

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

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