روتر LAN بههمراه کلاینت VPN: دو دستگاه، دو جدول مسیر

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

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

یک چیدمان نمونه در نظر بگیرید: میزبانهای LAN روی 192.168.50.0/24، روتر معمولی روی 192.168.50.1، یک کلاینت اختصاصی روی 192.168.50.15 و یک LAN دور روی 10.60.0.0/24 که فقط از طریق تونلی که آن کلاینت دارد قابل دسترسی است. هیچکدام از دو محدوده خصوصی با دیگری همپوشانی ندارد، و تونل طرح آدرس خودش را دارد.

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

گام 1: روتر را به کلاینت نشانه بگیرید، نه به تونل

روی روتر LAN، یک مسیر مقصد اضافه کنید که پرش بعدیاش آدرس LAN کلاینت است:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

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

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

گام 2: به کلاینت مسیر خودش را از سمت تونل بدهید

کلاینت اکنون بستهای برای 10.60.0.0/24 دریافت میکند و جدول خودش را میبیند. اگر پیکربندی تونلش مسیری برای آن پیشوند نصب کرده باشد، بسته رمزنگاریشده ادامه مییابد. اگر نه، بسته با پیشفرض معمولی تطبیق مییابد و به 192.168.50.1 برمیگردد، که آن را دوباره به کلاینت میفرستد.

پیش از افزودن چیزی نگاه کنید:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

نبودِ مسیر پیشوند در همه جدولها همان یافتهای است که به دنبالش هستید. آن را از طریق پیکربندی خود تونل اضافه کنید تا اتصال بعدی دوباره نصبش کند؛ ip route add دستی با نشست از بین میرود و خرابی را در نامناسبترین زمان برمیگرداند. پرش بعدی رابط تونل است یا آدرسی که VPN به عنوان همتایش اختصاص میدهد، بسته به کلاینت، و آدرس همتا باید از پروفایل فعلی بیاید نه از یک یادداشت قدیمی.

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

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

دریافت و ارسال رو به جلو دو اجازه متفاوتاند. net.ipv4.ip_forward=1 روی کلاینت عبور را در سطح هسته مجاز میکند، و یک قاعده فایروال هنوز باید آن را بین رابط LAN و تونل مجاز کند. قاعدهای که دسترسی به صفحه مدیریت خود کلاینت را مجاز میکند، عبور به LAN دور را مجاز نمیکند، و این تمایز وقتی همان میزبان بهصورت محلی به ping پاسخ میدهد آسان از چشم میافتد.

سمت دور مشکل آینهای دارد. باید بداند که 192.168.50.0/24 از طریق این کلاینت احرازشده قابل دسترسی است. با OpenVPN معمولاً یعنی یک مسیر برای هر کلاینت که پیکربندی سرور آن را هُل میدهد، یا یک فایل مخصوص کلاینت روی سرور که LAN پشت کلاینت را اعلام میکند. بدون آن، LAN دور یا پاسخ را رها میکند یا آن را به درگاه پیشفرض خودش، یعنی اینترنت، میفرستد.

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

گام 4: هر دو تصمیم را ماندگار کنید، سپس مسیر واقعی را آزمایش کنید

هر مسیر یک مالک دارد، و مالک همان پیکربندی است که هنگام راهاندازی یا اتصال مجدد بازتولید میشود. روی روتر ممکن است یک ورودی مسیر ایستا باشد؛ روی کلاینت میتواند پروفایل VPN، NetworkManager یا systemd-networkd باشد. با اتصال مجدد تونل و راهاندازی مجدد کلاینت بررسی کنید، سپس جدول را دوباره بخوانید نه اینکه به ویرایش اعتماد کنید.

مسیر پیشفرضی را که اتصال بیرونی تونل را حمل میکند دستنخورده نگه دارید. جایگزین کردنش برای «سادهسازی» پیکربندی، مسیر رمزنگاریشده را پیش از آنکه هر ترافیک داخلی بتواند از آن استفاده کند میشکند، و نشانهاش تونلی است که پس از تغییر هرگز دوباره برقرار نمیشود.

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