چرا NAT خانگی از رابط VPN شما محافظت نمی‌کند
روتر خانگی تونل را عبور می‌دهد، اما میزبان بستهٔ رمزگشایی‌شده را داوری می‌کند. شنونده، مسیر درونی و سیاست ورودی را جدا بخوانید.
لپ‌تاپ‌های پشت روتر خانگی بدون هدایت پورت همچنان اتصال‌های SSH را که از VPN می‌آیند می‌پذیرند. این تناقض نیست، چون دو دستگاه متفاوت دو بستهٔ متفاوت را داوری می‌کنند. روتر انتقال رمزگذاری‌شده را عبور می‌دهد و میزبان تصمیم می‌گیرد با بستهٔ رمزگشایی‌شده‌ای که به رابط تونلش می‌رسد چه شود. جدا نگه داشتن این دو تصمیم همان تمام تمرین است.
روتر تونل را عبور می‌دهد، میزبان بسته را داوری می‌کند
پیش از نگاه به حتی یک قاعده، مسیر را از منبع دور تا سرویس ترسیم کنید. بخش بیرونی انتقال VPN است که روتر و درگاه آن را اداره می‌کنند. بخش درونی وقتی آغاز می‌شود که نقطهٔ پایانی لایهٔ تونل را برمی‌دارد و میزبان بسته‌ای را دریافت می‌کند که به نشانی VPN آن نشانه رفته است.
این دو بخش را یکی کنید و روتر اعتبار تصمیمی را می‌گیرد که میزبان می‌گیرد. صفحهٔ هدایت پورت یا گزارش روتر فقط گفت‌وگوهای بیرونی را توصیف می‌کنند و هیچ‌یک نمی‌گوید میزبان کدام ترافیک رمزگشایی‌شده را می‌پذیرد. میزبان سیاست ورودی خودش را بر بستهٔ درونی اعمال می‌کند، همان‌گونه که بر هر بسته‌ای که به یک رابط می‌رسد اعمال می‌کند. در همان سیاست است که پرسش در معرض بودن واقعاً حل می‌شود.
شنوندهٔ عام نیست یک سرویس عمومی
در Linux، اتصال به INADDR_ANY یعنی هر نشانی محلی، بنابراین یک سرویس می‌تواند روی رابط تونلی پاسخ دهد که هرگز نامش را نبرده است. مرجع سوکت IP آن اتصال را توصیف می‌کند و پیش از نتیجه‌گیری از فهرست شنوندگان ارزش خواندن دارد. درآمد عام واقعیتی دربارهٔ سوکت است، نه ادعایی دربارهٔ دسترسی‌پذیری.
دو خط زیر همان سرویس در دو اتصال متفاوت است و تفاوت، تمام پاسخ به این پرسش است که آیا رابط اهمیت دارد. پیش از هر چیز بخوانید سوکت روی کدام نشانی نشسته است.
ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))چیدمانی را نام ببرید که می‌تواند به پورت برسد
سه چیدمان بسته‌ای را روی آن رابط می‌گذارند و صاحبان متفاوتی دارند. نام بردن چیدمان درست تعیین می‌کند چه کسی باید سیاستی را تغییر دهد.
| Arrangement | What reaches the port | Where the decision lives |
|---|---|---|
| Another permitted VPN peer | A packet from the same tunnel subnet | Gateway forwarding policy and host input rules |
| A deliberate public forward | Traffic the gateway publishes on purpose | Gateway service definition |
| A subnet routed behind the gateway | Client traffic from the far side | Gateway route and host input rules |
نتیجهٔ مرورگری که نشانی خروج عمومی نشان می‌دهد هیچ چیزی دربارهٔ هیچ‌یک از آن سه نمی‌گوید، چون توصیف می‌کند ترافیک خروجی چگونه بیرون می‌رود نه اینکه به ترافیک ورودی چه اجازه‌ای داده شده است. به‌جای آن از شنونده و نشانی منبع در گزارش سرویس عقب‌گرد کنید. اگر منبع همتای دیگری از تونل باشد، سیاست درگاه سند جالب است. اگر نشانی ترجمه‌شده باشد، پیش از تغییر قاعده ترجمه را پیدا کنید.
سرویس را به مسیری که در نظر داشتید محدود کنید
اگر SSH فقط از یک مسیر مدیریت لازم است، آن مسیر را به‌صورت بازهٔ منبع به‌همراه یک رابط بنویسید. سپس قواعد ورودی میزبان را بر پایهٔ رابط، مقصد و منبع محدود کنید نه بر پایهٔ نام شبکه، چون نامی که خصوصی به نظر می‌رسد می‌تواند نمایندهٔ هر نشانی باشد. برای کسی که مشکل بعدی را حل خواهد کرد یک مسیر باقی بگذارید.
nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter inputقاعده‌ای که رابط تونل و بازهٔ مدیریت را نام می‌برد قصد را در یک جا بیان می‌کند. آن را با قاعده‌ای که برای شبکهٔ Wi-Fi نوشته شده مقایسه کنید، که هیچ چیزی دربارهٔ ترافیک رمزگشایی‌شدهٔ تونل نمی‌گوید. وقتی دو لایه هم‌داستان نیستند، سیاست میزبان همان است که بسته با آن روبه‌رو می‌شود.
ورودها و وصله‌ها را دقیقاً همان‌جا که هستند بگذارید؛ رسیدن به یک پورت هرگز همانند اجازهٔ استفاده از آن نبوده است. خانوادهٔ نشانی و زمان را برای هر منبع ناشناس ثبت کنید و پیش از سرزنش یک ویژگی یا یک آسیب‌پذیری بررسی کنید. قاعده‌ای که هر همتای تونل را می‌پذیرد طراحی دیگری از قاعده‌ای است که یک زیرشبکهٔ مدیریت را می‌پذیرد، و هیچ خط گزارشی نخواهد گفت کدام در نظر بوده است.
اصلاح را با یک موفقیت و یک رد بپذیرید
هر دو نیمه را ثابت کنید: یک اتصال تأییدشده موفق می‌شود و یک مسیر مستثنا رد می‌شود. رد همان نیمه‌ای است که مردم از آن می‌گذرند و همان است که نشان می‌دهد قاعده کار می‌کند نه اینکه کنار یک مقدار پیش‌فرض سهل‌گیرانه ایستاده باشد. از سمت مستثنا آزمایش کنید نه اینکه دربارهٔ آن استدلال کنید.
این جفت را پس از اتصال دوباره تکرار کنید، چون تونلی که با نام رابط دیگری بازمی‌گردد می‌تواند قاعده‌ای را که به رابط قدیمی محدود شده بی‌صدا دور بزند. مرزی که اهمیت دارد همان است که میزبان بر بسته‌هایی که واقعاً دریافت می‌کند اعمال می‌کند.