همتای VPN به واسط‌های دیگر پینگ می‌زند چون محلی هستند
جدول مسیریابی محلی بسته‌ها را به هر نشانی که میزبان دارد می‌فرستد، فارغ از اینکه روی کدام واسط باشد. تنظیمات ارسال هرگز به آن مسیر وارد نمی‌شود.
یک کارخواه WireGuard وصل می‌شود و به نشانی‌ای روی یک واسط کاملاً متفاوت پینگ می‌زند، و پاسخ می‌رسد. ضبط‌ها نشان می‌دهند درخواست فقط روی تونل دیده می‌شود. هیچ چیز خراب نیست، و تنظیم ارسالی که با دقت غیرفعال شده بود هیچ ربطی به این موضوع ندارد. این مقایسه‌ای است میان دو مسیر که در یک نمودار شبیه به هم به نظر می‌رسند و در هسته کاملاً متفاوت‌اند.
یک مسیر بسته‌ها را به‌جای کسی دیگر ارسال می‌کند؛ مسیر دیگر آن‌ها را به خود میزبان تحویل می‌دهد.
بسته‌ای که به میزبان نشانی شده است در خود میزبان می‌ماند
کارخواه راه دور یک بسته IP به نشانی‌ای می‌فرستد که میزبان مالک آن است. مسیریابی یک پرسش درباره آن بسته می‌پرسد: آیا این مقصد محلی است؟ هر نشانی‌ای که میزبان در اختیار دارد در جدول مسیریابی محلی ظاهر می‌شود، و آن جدول پیش از جدول اصلی بررسی می‌شود، پس بسته به پشته خود میزبان می‌رود نه اینکه از واسط دیگری بیرون برود. پاسخ به‌صورت محلی تولید می‌شود و از تونل بازمی‌گردد، چون پرس‌وجو از همان‌جا آمده بود.
این تمام سازوکار است. هیچ ارسالی رخ نمی‌دهد، هیچ تغییر وضعیت واسطی درگیر نیست، و نشانی مورد بحث لازم نیست از هیچ جای دیگری قابل دسترس باشد.
چرا ip_forward اعمال نمی‌شود
ارسال بسته‌هایی را کنترل می‌کند که باید از واسطی متفاوت با واسطی که روی آن رسیده‌اند خارج شوند. پینگ به خود میزبان هرگز آن مسیر را نمی‌پیماید: بسته به‌صورت محلی مصرف می‌شود و پاسخ به‌صورت محلی تولید می‌شود. بنابراین تنظیم net.ipv4.ip_forward=0 اینجا چیزی را تغییر نمی‌دهد و قاعده‌ای در زنجیره ارسال هرگز آن ترافیک را نمی‌بیند. کنترل درست روی مسیر ورودی است، محدودشده با واسط ورودی یا منبع.
به همین دلیل، غیرفعال کردن ارسال و فرض اینکه میزبان منزوی است حس امنیت کاذب ایجاد می‌کند.
جدول محلی‌ای را که تصمیم گرفت بخوانید
ip rule show معمولاً قاعده‌ای با اولویت صفر گزارش می‌کند که همه جست‌وجوها را نخست به جدول محلی می‌فرستد، و ip route show table local نشانی‌های خود میزبان را با دامنه محلی فهرست می‌کند. آن جدول نشانی‌های روی واسط‌هایی را هم در بر می‌گیرد که به‌صورت مدیریتی خاموش‌اند ولی هنوز پیکربندی شده‌اند. نشانی‌های IPv4 که به‌صورت ایستا تخصیص یافته‌اند معمولاً از قطع پیوند جان سالم به در می‌برند، و همین‌طور است که پینگ به یک پل خاموش هنوز می‌تواند موفق شود و اپراتور را شگفت‌زده کند.
IPv6 دقیقاً در این نکته اختلاف دارد. نشانی‌های آن معمولاً وقتی پیوند قطع می‌شود پس گرفته می‌شوند، مگر اینکه keep_addr_on_down تنظیم شده باشد. خانواده‌ها را مقایسه کنید به‌جای آنکه فرض کنید یک قاعده هر دو را پوشش می‌دهد.
یک همتا در واقع به چه چیزی می‌رسد
پاسخی از نشانی خود مسیریاب روی یک بخش، هیچ چیزی درباره ماشین‌های پشت آن بخش نمی‌گوید. همتا از این مسیر نمی‌تواند به میزبانی پشت واسط دیگر برسد؛ فقط به نشانی‌هایی می‌رسد که خود مسیریاب مالک آن‌هاست. آزمودن یک خدمت روی میزبان LAN جداگانه، به‌جای پینگ به نشانی مسیریاب، همان چیزی است که روشن می‌کند آیا ارسال اصلاً مجاز است یا نه.
محدود کردن همتا به خدماتی که روی نشانی تونل مقید شده‌اند مسئله سیاست ورودی است. خدمت مورد نظر را روی واسط تونل مجاز کنید و منابعی را که می‌توانند از آن استفاده کنند محدود کنید، چون بسته واقعاً به آنجا می‌رسد.
نشانی‌هایی را هم که قصد بازنشسته کردنشان را داشتید بررسی کنید. حذف یک نشانی از یک واسط مطمئن‌تر از انباشتن قواعد دیوار آتش روی یک نشانی کهنه است.