پاسخ VPN سایت‌به‌سایت از تونل عبور نمی‌کند
پاسخی که تونل را دور می‌زند، تصمیمی درباره مسیریابی در سمت دور است. جدول میزبان، انتخاب‌گرها و rp_filter را بررسی کنید، سپس مسیر یا NAT را برگزینید.
یک صبح را صرف تونلی کردم که بی‌عیب بالا آمد و ترافیک را دقیقاً در یک جهت جابه‌جا می‌کرد: شعبه به سرور فایل در دفتر مرکزی می‌رسید و هر اتصالی که از دفتر مرکزی به شعبه باز می‌شد در نخستین SYN می‌مرد. SAها فعال بودند، شمارنده‌های تونل بالا می‌رفت و دست‌دادن هرگز مشکل نبود. پاسخ به جایی مسیریابی می‌شد که تونل آن را پوشش نمی‌دهد و این انتخاب به سمت دور تعلق دارد. VPN سایت‌به‌سایت فقط بسته‌هایی را حمل می‌کند که میزبان به دروازه تحویل می‌دهد و هر میزبان این انتخاب را جداگانه، در هر جهت، از جدول مسیریابی خودش انجام می‌دهد.
هر دو جهت جداگانه مسیریابی می‌شوند
IP هیچ حافظه‌ای از جهت گفتگو نگه نمی‌دارد. هر میزبانی که بسته‌ای می‌فرستد جست‌وجوی بلندترین پیشوند خودش را اجرا می‌کند، یک گام بعدی برمی‌گزیند و تصمیم را فراموش می‌کند. درخواست و پاسخ دو بسته بی‌ارتباط‌اند که تصادفاً به یک اتصال تعلق دارند و تونل یک گام است که هر یک از آن دو می‌تواند از آن استفاده کند یا نکند. هیچ چیز در تبادل IKE به سرور دور نمی‌آموزد که چگونه به زیرشبکه شما برسد؛ مذاکره فقط بر سر این توافق می‌کند که کدام پیشوندها می‌توانند رمزگذاری شوند.
آن توافق دروازه دوم است. در strongSwan انتخاب‌گرهای ترافیک leftsubnet و rightsubnet هستند و بسته‌ای که مبدأ یا مقصدش بیرون از جفت مذاکره‌شده بیفتد رمزگذاری نمی‌شود، هر چه جدول مسیریابی بگوید. پیشوندی که به تونل مسیریابی می‌شود اما در انتخاب‌گرها نیست، یک شکست یک‌طرفه خاموش است: مسیر درست به نظر می‌رسد، بسته باز هم آشکار خارج می‌شود یا دور انداخته می‌شود و تنها گزارش charon شکایت می‌کند.
میزبان دور هیچ چیزی از تونل شما نمی‌داند
درون شبکه محلی دور، پاسخ یک بسته معمولی به نشانی کلاینت شماست. میزبان مقصد هیچ سرآیند IPsec نمی‌بیند و دلیلی برای ترجیح دروازه VPN ندارد؛ پیشوند شما را جست‌وجو می‌کند، چیزی مشخص‌تر از مسیر پیش‌فرض خود نمی‌یابد و از آن پیروی می‌کند. اگر پیش‌فرض به یک دیوار آتش هسته اشاره کند، دیوار آتش یا مسیری به بازگشت در تونل دارد یا ندارد. وقتی ندارد، دور ریختن خاموش، یک ICMP unreachable یا پاسخی می‌گیرید که از رابط رو به اینترنت خارج می‌شود و می‌میرد.
یک رابط دوم کافی است تا این حتی وقتی مسیری وجود دارد بشکند. یک NAS با پیوند مدیریت در VLAN دیگر، سروری با uplink پشتیبان، قاعده‌ای سیاسی که یک بازه مبدأ را به جدول دوم می‌فرستد: هر یک از این‌ها می‌تواند پاسخ را بگیرد. در Linux، ip rule show و ip route show table all قواعد و جدول‌هایی را آشکار می‌کنند که فهرست پیش‌فرض پنهان می‌کند.
تصمیم را روی ماشینی بخوانید که پاسخ را می‌فرستد
پیش از تغییر هر چیز از هسته بپرسید و نشانی مبدأ را به آن بدهید، زیرا قواعد وابسته به مبدأ پاسخ را تغییر می‌دهند.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"خروجی رابط خروجی و گام بعدی را نام می‌برد. اگر رابط آن یکی نیست که رو به دروازه VPN است، نقص را یافته‌اید و کار باقی‌مانده برگزیدن این است که مسیر کجا باید باشد. پینگ از دروازه در اینجا چیز کمی اثبات می‌کند: با نشانی پاسخ می‌دهد که میزبان دور می‌تواند جایش را پیدا کند، نه با نشانی لپ‌تاپ شما.
در Windows معادل‌ها Find-NetRoute -RemoteIPAddress 10.10.5.10 برای تصمیم و Get-NetRoute برای جدول است. مسیری که با New-NetRoute اضافه شود و متریک بالاتری از پیش‌فرض داشته باشد خاموش می‌بازد، پس ستون متریک را بخوانید نه مدخل را. سپس با بسته‌ها تأیید کنید: tcpdump -ni any "host 10.10.5.10 and tcp port 445" روی رابط شبکه محلی دور درخواست را نشان می‌دهد و همان فیلتر در سمت تونل نشان می‌دهد پاسخی برگشته است یا نه. درخواست دیده‌شده بدون پاسخ یعنی پاسخ جای دیگری مسیریابی شده یا دور انداخته شده؛ پاسخ روی رابط اشتباه پیش از آنکه به مسیری دست بزنید مجرم را به شما می‌دهد.
وقتی دروازه سرور نقطه پایانی VPN نیست
بسیاری از سایت‌ها دیوار آتشی میان سرورها و متمرکزکننده می‌گذارند. آن دیوار آتش پاسخ را هدایت می‌کند، پس به مسیری برای پیشوند کلاینت شما نیاز دارد که به دروازه VPN اشاره کند و به سیاست هدایت در هر دو جهت. دستگاه‌های حالتمند بدترش می‌کنند: درخواست از میزبان شبکه محلی که اجازه داده بود از دیوار آتش گذشت، پاسخ اکنون از جهت دیگری می‌رسد و مدخل ردیابی اتصال دیگر منطبق نیست، پس بسته به‌جای رد شدن به‌عنوان نامعتبر دور انداخته می‌شود. به همین دلیل گزارش سیاست خالی به نظر می‌رسد در حالی که ترافیک ناپدید می‌شود.
دروازه فیلتر دوم خودش را دارد. فیلتر مسیر معکوس در Linux بسته‌هایی را دور می‌ریزد که مبدأشان از رابطی که بر آن رسیده‌اند قابل دسترسی نیست و این دقیقاً شکل یک مسیر بازگشت نامتقارن مشروع است. راهنمای هدایت strongSwan به همین دلیل net.ipv4.ip_forward و net.ipv4.conf.all.rp_filter شل‌تر را می‌خواهد. مقدار سخت‌گیرانه 1 روی هر یک از دو دروازه، مسیری درست را خاموش می‌شکند و nstat -az دور ریختن‌ها را نشان می‌دهد اگر بدانید کجا را ببینید.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
مسیریابی کنید یا ترجمه کنید، سپس در هر دو جهت بررسی کنید
دو تعمیر هم‌ارز نیستند. افزودن مسیر نشانی کلاینت را دست‌نخورده نگه می‌دارد، پس قواعد مبتنی بر مبدأ، گزارش‌های حسابرسی و برنامه‌هایی که فراخوان را ثبت می‌کنند کار می‌کنند؛ بهایش این است که هر گامی که تصمیم را می‌گیرد به مسیر نیاز دارد، یعنی جاهای بیشتری برای خطا. پوشاندن نشانی روی دروازه دور مسیر بازگشت را به یک گام فرو می‌کاهد، زیرا پاسخ اکنون به خود دروازه نشانه‌گذاری شده است، و پنهان می‌کند که کدام کلاینت چه کرد.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEآن را آگاهانه برگزینید: همین که کلاینت‌ها به شکل نشانی دروازه ظاهر شوند، ACLهای مبتنی بر مبدأ دیگر آن‌ها را از هم تشخیص نمی‌دهند و conntrack باید نگاشت را نگه دارد تا پاسخ به تونل بازنویسی شود. اگر انتخاب‌گرها هنوز پیشوند کلاینت را کنار می‌گذارند، NAT چیزی را تغییر نمی‌دهد، زیرا درخواست هرگز وارد تونل نشد.
پیش از آنکه آن را درست اعلام کنید، چهار چیز را به ترتیب تأیید کنید: مسیر روی میزبانی که پاسخ را می‌فرستد، مسیر روی هر گامی که آن را هدایت می‌کند، انتخاب‌گرهایی که هر دو پیشوند را پوشش می‌دهند و ثبت‌ای که نشان دهد پاسخ با مبدأی که انتظار دارید وارد تونل می‌شود. سپس آزمون را از سایت دیگر تکرار کنید. عبور یک جهت یک طراحی نیمه‌باز است و جهت دوم معمولاً به دلیلی متفاوت از آنچه همین حالا تعمیر کردید شکست می‌خورد.