ping از طریق VPN: چرا قواعد پاسخ بازتاب مسیر برگشت را از دست می‌دهند
پاسخ بازتاب نوع ICMP را عوض می‌کند، نه پورت سرویس را. بسته درونی را از مسیر ارسال، NAT و فیلتر حالت‌دار دنبال کنید پیش از آنکه پورت‌ها را باز کنید.
یک میزبان را از طریق VPN پینگ کنید؛ درخواست با یک نوع ICMP خارج می‌شود و با نوع دیگری برمی‌گردد، و همین برای گیج کردن هر قاعده‌ای که بر پایه پورت نوشته شده باشد کافی است. در تبادل بازتاب هیچ پورت سرویس مقصدی وجود ندارد که در قاعده برگشت کپی شود، و فیلتری که انتظار تقارن دارد پاسخ را دور می‌ریزد در حالی که درخواست بی‌مانع عبور می‌کند. اصلاح با خواندن بسته آن‌گونه که واقعاً هست آغاز می‌شود و سپس با تعیین اینکه کدام مرز در مسیر تصمیم می‌گیرد. معمولاً دو لایه کار می‌کنند و لایه سوم بی‌صدا پاسخ را دور می‌ریزد. بخش‌های زیر آن‌ها را به ترتیبی که بسته با آن‌ها روبه‌رو می‌شود جدا می‌کنند.
بسته نوع را عوض می‌کند، نه پورت را
درخواست بازتاب از نوع 8 و کد 0 در ICMP است و یک شناسه و یک شماره ترتیب حمل می‌کند. پاسخ از نوع 0 و کد 0 است، با همان شناسه و ترتیب، و دو سر IP جابه‌جا شده‌اند. RFC 792 آن فیلدها را تعریف می‌کند و همین شناسه است که به فرستنده اجازه می‌دهد پاسخ‌ها را با درخواست‌های خودش جفت کند.
آنچه غایب است به همان اندازه مهم است: هیچ سرآیند TCP یا UDP وجود ندارد، پس هیچ پورتی برای اجازه دادن نیست. قاعده‌ای که برای پاسخ بازتاب پورتی را نام می‌برد، بسته‌ای را توصیف می‌کند که هرگز وجود نخواهد داشت. این رایج‌ترین خطا در تیکت‌های پینگ VPN است. قاعده مشخص به نظر می‌رسد، به هیچ چیز اعمال نمی‌شود و خرابی را دقیقاً همان‌جا که بود رها می‌کند.
سه زمینه درباره بسته تصمیم می‌گیرند
اگر پینگ میزبان موجود در LAN دوردست را هدف بگیرد، درخواست باید توسط دروازه ارسال شود. اگر نشانی را هدف بگیرد که متعلق به خود دروازه است، در مسیر ورودی محلی پایان می‌یابد. اگر دروازه خودش پینگ را آغاز کند، بسته در مسیر خروجی خودش شروع می‌شود و هرگز از تصمیم ارسال عبور نمی‌کند.
این سه زمینه زنجیره‌های قاعده و شمارنده‌های متفاوتی دارند، و یکی گرفتن آن‌ها دلیل آن است که «دیوار آتش ICMP را مجاز می‌کند» باز هم می‌تواند پینگ ناموفق بدهد. تونل بیرونی زمینه چهارم است: مجاز کردن شنونده VPN به‌طور خودکار درخواست درونی کپسول‌زدایی‌شده را مجاز نمی‌کند، و یک مجوز درونی هیچ چیزی درباره بالا بودن تونل بیرونی نمی‌گوید.
فیلترهای حالت‌دار و بی‌حالت پاسخ را متفاوت مدیریت می‌کنند
دیوار آتش حالت‌داری که درخواست را در حال خروج دیده است می‌تواند پاسخ را به همان جریان نسبت دهد و بدون قاعده دوم آن را بپذیرد. فیلتر بی‌حالت چنین حافظه‌ای ندارد، بنابراین جهت برگشت به مجوز صریح خودش نیاز دارد، با جابه‌جایی مبدأ و مقصد.
پیش از نوشتن هر چیزی بررسی کنید که محصول واقعاً کدام مدل را پیاده می‌کند. قاعده‌ای برای درخواست بازتاب لزوماً پاسخ بازتاب را پوشش نمی‌دهد، و محصولی که پرس‌وجوهای ICMP را ردیابی می‌کند ممکن است برای پاسخ‌هایی که از رابط دیگری می‌رسند سیاست دیگری اعمال کند.
دامنه آنچه مجاز می‌کنید را محدود کنید. مجاز دانستن هر پاسخ بازتاب از هر جا همان تکمیل یک پیوند حالت‌دار نیست، و شماره نوع هویت فرستنده را تأیید نمی‌کند.
ترجمه شناسه را هم عوض می‌کند
اگر ترجمه مبدأ عمدی باشد، چندتایی در انتهای دور با آنچه سرویس‌گیرنده فرستاده مطابقت ندارد. NAT می‌تواند شناسه پرس‌وجوی ICMP را همراه نشانی‌ها ترجمه کند، پس اصرار بر اینکه همان شماره در دو طرف دیده شود عدم تطابق کاذب می‌سازد.
به جای آن با نگاشتی که مترجم گزارش می‌کند هم‌بستگی برقرار کنید. مترجمی که شناسه را بازنویسی می‌کند شماره‌ای را که سرویس‌گیرنده شما ثبت کرده حفظ نخواهد کرد، پس نگاشت را هویت بدانید نه شماره را. سپس یک درخواست قابل شناسایی را در طول مسیر دنبال کنید: تأیید کنید که با مبدأ مورد انتظار به مقصد می‌رسد، تأیید کنید که مقصد پاسخی فرستاده است، مسیر بازگشت آن پاسخ را دنبال کنید، و تأیید کنید که سرویس‌گیرنده آن را دریافت کرده است، نه اینکه فقط بالا رفتن یک شمارنده دروازه را تماشا کنید.
خطاهای ICMP را در سیاست بازتاب ادغام نکنید
پیام «قطعه‌بندی لازم است» که کشف MTU مسیر از آن استفاده می‌کند پاسخ بازتاب نیست و بار مفید آن بسته‌ای را نقل می‌کند که آن را برانگیخته است. مجوزی که فقط بازتاب را می‌پذیرد و آن خطاها را بی‌صدا دور می‌ریزد، مشکل اندازه را به اتصال معلق تبدیل می‌کند که عکس کمک‌کننده بودن است.
همین احتیاط برای خانواده‌های نشانی هم صادق است. ICMPv6 از انواع پیام متفاوت استفاده می‌کند و کارکردهای ضروری‌ای دارد که IPv4 ندارد، پس کپی کردن این شماره‌ها در قاعده IPv6 به‌سادگی غلط است.
وقتی تبادل بازتاب کار کرد، برنامه واقعی را جداگانه بیازمایید. پینگ موفق رفت‌وبرگشت یک پروتکل را در یک اندازه به یک مقصد اثبات می‌کند، و مجوزی برای فرض اینکه HTTPS یا SMB یا هر جریان دیگری مجاز است نیست.