کلاینت VPN روی سرور LAN: چرا پاسخ‌ها از مسیر اشتباه خارج می‌شوند

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

پاسخ یک بستهٔ جدید است، نه بازگشت معکوس

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

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

هنگام خواندن بقیه دو زیرشبکه را در ذهن نگه دارید. یکی استخر آدرس VPN است که کلاینت‌های دور از آن می‌آیند، در این مثال 10.64.0.0/24. دیگری LAN است که باید کار کند، 172.16.24.0/24 با روترش روی 172.16.24.1. اشکال این است که ترافیک بین آن‌ها با مسیر پیش‌فرض تعیین می‌شود.

آن را با گرفتن بسته و جست‌وجو اثبات کنید

پیش از تغییر هر چیز، تأیید کنید پاسخ از کدام دستگاه استفاده خواهد کرد. جست‌وجو از گرفتن بسته سریع‌تر است و دقیقاً به همان پرسشی پاسخ می‌دهد که هسته هنگام ساخت بسته پاسخ خواهد داد.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

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

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

باریک‌ترین مسیری را که بر تونل پیشی می‌گیرد نصب کنید

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

به‌جای add از replace استفاده کنید، چون کلاینتی که دوباره وصل شود ورودی خودش را نصب کرده است و یک add دوم با خطای «مسیر از قبل وجود دارد» شکست می‌خورد که مثل مشکل دسترسی خوانده می‌شود. روی میزبان Windows معادلش route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p است، که -p ورودی را در طول راه‌اندازی‌های مجدد نگه می‌دارد، چون کلاینت ممکن است جدول را وقتی تونل دوباره بالا می‌آید بازسازی کند. روی میزبان Windows امروزی معادل پشتیبانی‌شده New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore است، و فرمان قدیمی‌تر route به‌عنوان شکل قدیمی حفظ می‌شود.

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

پاسخ را پس از اتصال دوباره نگه دارید

مسیری که با دست اضافه شده در بهترین حالت تا اتصال دوبارهٔ بعدی زنده می‌ماند. اگر استخر کلاینت‌ها پویا است، آن را در پیکربندی سرور سنجاق کنید تا پیشوندی که مسیریابی کردید همان پیشوندی بماند که کلاینت‌ها می‌گیرند؛ وگرنه ورودی به محدوده‌ای خالی اشاره می‌کند و نشانه هفته‌ها بعد بدون علت آشکار برمی‌گردد. نوشتن مسیر در up-script خود کلاینت گزینهٔ مطمئن دیگر است، چون پس از بازنویسی جدول توسط کلاینت اجرا می‌شود.

فایروال حالت‌دار می‌تواند مسیر درست را شکست دهد. اگر گرفتن بسته اکنون نشان می‌دهد پاسخ از eth0 خارج می‌شود و کلاینت باز هم مهلت زمانی می‌گیرد، بررسی کنید آیا میزبان بسته را پیش از ارسال حذف می‌کند. فیلتر سخت‌گیرانهٔ مسیر معکوس و net.ipv4.conf.all.rp_filter که روی 1 تنظیم شده، بسته‌هایی را حذف می‌کنند که مبدأشان از همان رابطی که رسیده‌اند به عقب مسیریابی نمی‌شد، و این دقیقاً همان حالت نامتقارنی است که همین حالا ساختید و سپس درست کردید، و وضعیت conntrack همین داستان را برای پورت‌های فوروارد‌شده می‌گوید.

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