VPN سایت به سایت فقط یک طرف کار می‌کند: دو ایراد متفاوت
پاسخی که هرگز برنمی‌گردد و اتصالی که رد شده است دو ایراد متفاوت هستند. خط‌مشی، مسیریابی و نشانی مبدأیی را که سرور واقعاً می‌بیند مقایسه کنید.
سایت A به B می‌رسد، B نمی‌تواند به A برسد و تونل در هر دو جهت سالم به نظر می‌رسد. پیش از دست زدن به تونل، مشخص کنید واقعاً کدام ایراد را دارید. اتصال تازه‌ای که در B آغاز و رد می‌شود و پاسخی به اتصالی که در A آغاز شده و هرگز نمی‌رسد، شکایت‌های مشابه و تشخیص‌های کاملاً متفاوت تولید می‌کنند. یکی مشکل خط‌مشی یا مسیر در راه است؛ دیگری مشکل مسیر بازگشت یا وضعیت برای ترافیکی است که از پیش مجاز بوده.
همین تفاوت تعیین می‌کند کدام فرمان‌ها ارزش اجرا دارند.
دو ایراد که یکسان به نظر می‌رسند
در حالت نخست، میزبان B یک SYN به A می‌فرستد و چیزی بازنمی‌گردد. در حالت دوم، میزبان A نشستی را با موفقیت باز می‌کند و پاسخ در راه بازگشت ناپدید می‌شود. هر دو کاربر می‌گویند پیوند یک‌طرفه است و هر دو بسته‌ای را توصیف می‌کنند که ناپدید شده، پس توصیف به‌تنهایی نمی‌تواند آن‌ها را از هم جدا کند.
بپرسید کدام طرف تلاش ناموفق را آغاز کرده بود. همین یک واقعیت نیمی از علت‌های ممکن را حذف می‌کند.
سپس بررسی کنید که آزمون در تمام مدت از همان میزبان‌ها و همان سرویس استفاده کرده باشد. ping از یک طرف و اتصال به پوشه اشتراکی از طرف دیگر دو چیز متفاوت را می‌آزمایند، و یک عیب‌یابی از دروازه ممکن است نشانی تونلی را برگزیند که هیچ ترافیک کاربری از آن استفاده نمی‌کند.
حالت یکم: مسیر بازگشت غایب است
سرور دوردستی که از طریق دروازه پیش‌فرض دیگری پاسخ می‌دهد می‌تواند درخواست را دریافت و پاسخ را جای دیگری مسیریابی کند. آن‌گاه دیوارهای آتش که وضعیت را پیگیری می‌کنند پاسخ نامتقارن را دور می‌ریزند، چون با جریان برقرارشده تطبیق ندارد و این دقیقاً مانند جهتی است که هرگز کار نکرده است. ترجمه نسخه دیگری می‌افزاید: مقصد یک مبدأ ترجمه‌شده می‌بیند و به آن پاسخ می‌دهد، پس قاعده‌ای که برای نشانی اصلی نوشته شده هرگز منطبق نمی‌شود.
نشانی‌ای را که مقصد پس از ترجمه واقعاً می‌بیند بررسی کنید و مسیر بازگشت را برای همان نشانی، نه برای زیرشبکه اصلی.
حالت دوم: خط‌مشی هرگز اجازه آن را نداده بود
حالت مقابل ساده‌تر و رایج‌تر از آن است که به نظر می‌رسد: یک دفتر باید سرویس مرکزی را مصرف کند و هرگز اتصالی به مرکز آغاز نکند. این نامتقارنی تصمیم دسترسی آگاهانه است و تونل همان‌گونه که طراحی شده کار می‌کند. پیش از تغییر هر تنظیم تونل، خط‌مشی دسترسی را بخوانید. سند، نه ضبط بسته‌ها، مشخص می‌کند کدام جهت مقصود بوده است. ضبط فقط می‌تواند نشان دهد چه رخ داده، نه چه چیزی مجاز بوده.
اگر آغاز دوطرفه واقعاً لازم است، مجوز سرویس مشخص را از طریق مجموعه قواعد پشتیبانی‌شده پلتفرم اضافه کنید. قابل‌اعتماد کردن متقابل همه زیرشبکه‌ها برای درست کردن یک برنامه، نیاز باریک را به مجوزی گسترده تبدیل می‌کند و این معاوضه به‌ندرت بعداً بازبینی می‌شود.
پیش و پس را روی همان میزبان‌ها مقایسه کنید
دو سر یک تلاش را ببینید، نه دو تلاش جداگانه. روی دروازه میزبان آغازکننده و روی مقصد ضبط کنید، سپس مقایسه کنید چه وارد شد، چه خارج شد و طرف دور کدام نشانی را دید.
tcpdump -ni any host 10.20.30.40 and port 445 conntrack -L | grep 10.20.30.40 ip route get 10.20.30.40 swanctl --list-sas
اگر ضبط در مقصد درخواست را با نشانی مبدأ غیرمنتظره نشان دهد، پاسخ در ترجمه یا مسیریابی است، نه در خط‌مشی امنیتی تونل. اگر مقصد هیچ درخواستی نشان ندهد، بسته هرگز از مسیر محافظت‌شده عبور نکرده است.
پس از اصلاح، همان آزمون را از همان میزبان تکرار کنید و تأیید کنید که دسترسی نامرتبط هنوز رد می‌شود. وضعیت تونل «established» به‌تنهایی هیچ‌یک از دو نتیجه را پشتیبانی نمی‌کند.