رسیدن به کلاینت IKEv2 روی IP مجازی تخصیص‌یافته‌اش

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

تونل نشانی مبدأ را درست نمی‌کند

یک CHILD SA جفتی از انتخاب‌گرهای ترافیک را پوشش می‌دهد، یکی برای هر طرف، و ترافیک را در هر دو جهت آن جفت مجاز می‌کند. چیزی درباره این نمی‌گوید که کدام همتا اولین بار تبادل IKE را باز کرده است. دروازه‌ای که در ابتدا برای تونل گوش می‌داد هنوز می‌تواند نخستین بستهٔ برنامه را بفرستد، به شرطی که مبدأ و مقصد انتخاب‌شده داخل انتخاب‌گرهای نصب‌شده بیفتند. وقتی درخواست از رابط اشتباه خارج می‌شود، به‌سادگی برای تونل واجد شرایط نیست.

مسیریابی به سمت کلاینت لازم است و کافی نیست. سیاست باید مبدأیی را که واقعاً استفاده کردید بپذیرد.

سیاست نصب‌شده را بخوانید، نه پروندهٔ پیکربندی

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

ipsec statusall
ip xfrm policy

خروجی وضعیت اتصال، نشانی مجازی تخصیص‌یافته و انتخاب‌گرهایی را که اکنون برای آن همتا معتبرند نام می‌برد. تخلیهٔ سیاست همان انتخاب‌گرها را به‌عنوان وضعیت هسته نشان می‌دهد و انتخاب بسته در واقع همان را مشورت می‌کند. انتخاب‌گر سمت دروازه را با مبدأیی که برنامه شما استفاده خواهد کرد مقایسه کنید، زیرا ناسازگاری فوراً شکست را توضیح می‌دهد. نشانی فعلی کلاینت را بخوانید نه نشانی از یک نشست قبلی، زیرا VIP دوباره تخصیص‌یافته سیاست قدیمی را باطل می‌کند.

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

حتی سیاست بی‌نقص هم وقتی سرویس فقط به loopback مقید است به درگاه بسته می‌رسد. شنونده باید روی نشانی تخصیص‌یافته یا روی یک نشانی محلی عام باشد.

ss -ltnp 'sport = :9090'
iptables -S INPUT

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

جهت جدید را به‌تنهایی بیازمایید

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

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

جستجوی مسیر پاسخ می‌دهد که دروازه از کدام مبدأ و رابط استفاده می‌کرد و همان مقداری است که سیاست باید بپذیرد. ضبط باید نشان دهد که درخواست داخل ESP خارج می‌شود نه به‌صورت TCP ساده روی رابط عمومی. روی کلاینت، ترافیک رمزگشایی‌شده را ضبط کنید تا رسیدن و پاسخ سرویس را تأیید کنید. اگر درخواست بدون ESP روی سیم ناپدید شود، پیش از دیوار آتش کلاینت به نشانی مبدأ مشکوک شوید.

آزمون را پس از تجدید کلید یا اتصال دوباره تکرار کنید، زیرا VIP ممکن است تغییر کند. مسیری که فقط تا نشست بعدی کار می‌کند مسیر کاری نیست.