پیشوند عمومی از طریق OpenVPN: تعمیر مسیر بازگشت

ببینید تونل بالا می‌آید و کلاینت طرف مقابل را پینگ می‌کند، و بعد نشانی عمومی‌ای که پشت VPN است از جای دیگری پاسخ می‌دهد، یا اصلاً پاسخ نمی‌دهد. این نشانه معمولاً هیچ ربطی به رمزنگاری یا گواهی‌ها ندارد. پیشوندی که ارائه‌دهنده مسیریابی می‌کند به‌صورت یک مسیر IP تحویل داده می‌شود، و حمل آن از طریق OpenVPN به معنای بازتولید آن مسیر در دو لایه و حفظ نشانی مبدأ در مسیر بازگشت است. پل‌زدن WAN لازم نیست، و افزودن نشانی به یک رابط، مسیر بالادستی را ایجاد نمی‌کند.

پیشوند باید ابتدا به سمت شما مسیریابی شود

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

اگر ارائه‌دهنده 198.51.100.64/28 را به سرور ورودی شما مسیریابی کند، بسته‌های آن محدوده به سرور می‌رسند و همان‌جا می‌مانند مگر اینکه آن‌ها را ارسال کنید. اگر ارائه‌دهنده به‌جای آن محدوده را روی لینک بالادستی شما پل بزند، سرور باید برای آن به ARP پاسخ دهد، که مشکل دیگری است.

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

دو لایه مسیریابی: مسیر هسته و iroute

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

مسیر سمت سرور چنین است، و پیشوند و ماسک باید با تخصیص همخوان باشند:

ip route add 198.51.100.64/28 dev tun0

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

iroute 198.51.100.64 255.255.255.240

مستندات شبکه‌های مسیریابی‌شده OpenVPN هر دو لایه و دلیل جدابودنشان را توضیح می‌دهد. مسیر هسته بدون iroute بسته‌ها را بدون مالک به تونل می‌فرستد و OpenVPN آن‌ها را دور می‌ریزد. iroute بدون مسیر هسته بسته‌ها را روی مسیر پیش‌فرض سرور می‌گذارد. هر دو خطا از سمت کلاینت مانند یک تونل خراب به نظر می‌رسند.

نشانی سرویس کجا زندگی می‌کند

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

روی کلاینت Linux که سرویس را محلی پایان می‌دهد، یک نشانی میزبان کافی است:

ip address add 198.51.100.70/32 dev lo

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

مبدأ عمومی را در مسیر بازگشت نگه دارید

پاسخ از پیشوند واگذارشده باید از تونل خارج شود و به مسیر ارائه‌دهنده برسد. اگر میزبان دور آن را از ISP خودش بفرستد، نشانی مبدأ جعلی به نظر می‌رسد و ارائه‌دهنده یا مقصد آن را دور می‌ریزد. راه‌حل یک قاعده مبتنی بر مبدأ یا یک جدول مسیریابی اختصاصی است، نه NAT گسترده‌تر. بدون آن، سرویس از همتای تونل کار می‌کند و از هر جای دیگری شکست می‌خورد.

روی سرور ورودی، یک قاعده masquerade گسترده مقصر معمول است. مبدأ عمومی را به نشانی اصلی سرور بازنویسی می‌کند، و کلاینت هرگز نشانی واقعی را نمی‌بیند:

iptables -t nat -S POSTROUTING

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

قبل از اعتماد، هر دو جهت را بررسی کنید

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

از هسته بپرسید یک نشانی واگذارشده کدام مسیر را می‌گیرد، و هنگام اجرای یک درخواست تونل را زیر نظر بگیرید:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

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

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

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