کاربران راه دور از طریق هاب VPN به سایت دوم دسترسی ندارند

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

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

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

به همین دلیل آزمودن هر تونل به‌تنهایی چیز بسیار کمی اثبات می‌کند. پینگ کردن نشانی LAN هاب تصمیم اول را می‌آزماید، و پینگ کردن هاب از دفتر مرکزی تصمیم سوم را. بسته‌ای که شکست می‌خورد منبعش استخر کاربران و مقصدش سایت دوم است، پس اول آن پیشوندها را بنویسید. اینجا استخر 10.80.0.0/24 است، LAN هاب 10.10.0.0/24 و دفتر مرکزی 10.20.0.0/24.

پیشوند دور را به کلاینت راه دور هل دهید

روی یک سرور دسترسی راه دور OpenVPN کلاینت مسیرها را هنگام اتصال یاد می‌گیرد. بدون push، کلاینت با تونل تقسیم‌شده 10.20.0.50 را به دروازهٔ خودش می‌فرستد و بسته هرگز وارد تونل نمی‌شود.

push "route 10.20.0.0 255.255.255.0"

مسیر هل‌داده‌شده هنگامی که کلاینت وصل می‌شود اعمال می‌شود، پس کاربری که آنلاین می‌ماند تا دوباره وصل نشود چیزی نمی‌بیند. روی کلاینت بررسی کنید: ip route get 10.20.0.50 در Linux، و route print در Windows. خروجی باید نام رابط تونل را بیاورد.

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

به هاب یک مسیر خروجی واقعی بدهید

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

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

جایی که شاخهٔ سایت به سایت خودش OpenVPN است، مسیر می‌تواند در همان پیکربندی با نشانی تونل همتا به‌عنوان دروازه زندگی کند: route 10.20.0.0 255.255.255.0 172.30.0.2. دروازه اختیاری نیست. اگر آن را حذف کنید، گام بعدی به پیش‌فرض پیاده‌سازی می‌افتد که میان کلاینت تک‌مقصد و هاب چندهمتا تفاوت دارد.

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

سمت مقابل را تا استخر کاربران گسترش دهید

دفتر مرکزی از قبل LAN هاب، 10.10.0.0/24 را پوشش می‌دهد. استخر کاربران پیشوند دوم است و باید در انتخابگرها هم باشد، وگرنه هیچ سیاستی پاسخی که به 10.80.0.25 فرستاده می‌شود را پوشش نمی‌دهد. هر همتا همان جفت مجموعهٔ پیشوند را از سمت خودش نام می‌برد:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

local_ts یک دستگاه همان remote_ts دیگری است. بلوک هاب را روی دفتر مرکزی کپی کنید و جفت وارونه می‌شود، پس SA فرزند هرگز بالا نمی‌آید.

نحو قدیمی‌تر ipsec.conf از leftsubnet جداشده با ویرگول استفاده می‌کند. انجمن امنیتی در حال اجرا انتخابگرهایی را که مذاکره کرده نگه می‌دارد، پس پس از ویرایش تونل را دوباره برقرار کنید. انتخابگری که در 10:00 تغییر کرده و در برابر SA‌ای که در 09:40 بالا آمده آزموده شده هنوز شکست می‌خورد، در حالی که پروندهٔ پیکربندی در تمام مدت درست به نظر می‌رسد.

سپس آخرین گام را بررسی کنید. ip route get 10.80.0.25 روی نقطهٔ پایانی دور باید به داخل تونل اشاره کند. اگر سرویس از روتر LAN به‌عنوان دروازهٔ پیش‌فرض خود استفاده می‌کند، آن روتر هم به مسیر بازگشت نیاز دارد، وگرنه پاسخ همان‌جا می‌میرد. اجرای tcpdump -ni eth1 host 10.80.0.25 روی آن بخش نشان می‌دهد آیا پاسخ اصلاً از نقطهٔ پایانی خارج شده است.

جریان را روی هاب مجاز کنید

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

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

فیلتر مسیر بازگشت شکست خاموش کنار آن است: با دو شاخه روی رابط‌های متفاوت، rp_filter=1 می‌تواند پاسخ را بیندازد در حالی که شمارندهٔ قاعدهٔ پذیرش هرگز حرکت نمی‌کند. iptables -vnL FORWARD را پیش و پس از یک تلاش مقایسه کنید. قاعده‌ای که هرگز افزایش نمی‌یابد به آن نمی‌رسند، پس یک لایه پایین‌تر را ببینید، نه اینکه آن را بازنویسی کنید.

اگر فقط یک گروه به عبور نیاز دارد، مسیر را در پروندهٔ هر کلاینت زیر client-config-dir بگذارید، نه اینکه push سراسری را گسترش دهید. Source NAT روی هاب هم نیاز به مسیر بازگشت سمت مقابل را از میان برمی‌دارد، اما نشانی کاربر را پنهان می‌کند، پس گزارش‌های سایت دور و قاعده‌های مبتنی بر نشانی دیگر کاربران را از هم تشخیص نمی‌دهند.

از کلاینت بررسی کنید، سپس به‌صورت معکوس عقب‌گرد کنید

یک درگاه TCP را بیازمایید، نه فقط ICMP، چون ping می‌تواند عبور کند در حالی که سرویس مسدود می‌ماند. nc -vz 10.20.0.50 445 و traceroute -n 10.20.0.50 از کلاینت نشان می‌دهند آیا گام دوم نشانی تونل هاب است. روی هاب، tcpdump -ni tun0 host 10.20.0.50 و همان فیلتر روی رابط سایت به سایت: درخواست روی هر دو بدون پاسخ روی هیچ‌کدام، مشکل را به سمت مقابل می‌برد.

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

فهرست عقب‌گرد نگه دارید، چون چهار شیء تغییر کرده و سه‌تا آسان فراموش می‌شود: مسیر هل‌داده‌شده، مسیر هاب، انتخابگرها و قاعده‌های دیوار آتش. آن‌ها را معکوس برگردانید، SA را دوباره برقرار کنید و بگذارید یک کاربر دوباره وصل شود. عقب‌گرد جزئی مسیری را باقی می‌گذارد که به تونلی اشاره می‌کند که دیگر مطابقت ندارد، و خواندنش از سکوت اولیه سخت‌تر است. راهنمای OpenVPN 2.6 push، route و iroute را برای نسخهٔ شما مستند می‌کند.