یک NIC یا دو تا؟ تعیین چیدمان رابط‌های یک سرور VPN

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

سه شرطی که آن را تعیین می‌کنند

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

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

هیچ‌یک از این سه درباره شمار پورت‌های روی شاسی نیست. آن‌ها درباره مسیریابی، مالکیت نشانی و این هستند که طراحی تا چه اندازه به جداسازی فیزیکی وابسته است.

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

وقتی سرویس روی خود میزبان VPN اجرا می‌شود

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

با این حال دو چیز باید درست باشد: سرویس باید روی نشانی گوش دهد که تونل بتواند به آن برسد و فایروال میزبان باید ترافیکی را که به رابط تونل می‌رسد بپذیرد. هر دو در فرمان‌های زیر دیده می‌شوند.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

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

وقتی مقصد روی LAN قرار دارد

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

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

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

چرا یک نام مستعار منطقه دوم نمی‌سازد

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

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

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

چیدمان را با ترافیکی که مجاز می‌کنید بسنجید

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

سپس رابط‌های واقعی و ثبت واقعی را تأیید کنید، نه نمودار در سند طراحی. فرمان‌های زیر هر دو نما را چاپ می‌کنند.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

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