یک دستگاه از طریق VPN روتر به سه قانون نیاز دارد، نه یک کلید

در VPN روتر هیچ کلیدی برای هر دستگاه وجود ندارد؛ کلیدی که به دنبالش هستید میانبری است که قواعد مسیریابی سیاستی را بهجای شما مینویسد. همان لحظهای که یک لپتاپ، یک بازه پورت، یک فهرست نشانی یا یک بخش LAN باید از تونل استفاده کند در حالی که بقیه روی WAN میمانند، شما در حال ساختن یک مسیر سیاستی هستید، نه فعالکردن یک قابلیت. کار سه بخش متحرک دارد و هر یک به شکلی متفاوت شکست میخورد: جدول علامتخورده بدون مسیر مثل سکوت است، علامتی که در زنجیره اشتباه اعمال شود مثل این است که هیچچیز رخ نداده، و قاعده NAT گمشده مثل تونلی است که وصل میشود و چیزی حمل نمیکند. دو بخش دیگر هم گم میشوند چون هرگز در قاعده mangle ظاهر نمیشوند، و آنها DNS و IPv6 هستند.

افسانه: تونل یک تنظیم کلاینت است

کلاینت VPN در سمت روتر یک کار خشن را خوب انجام میدهد: 0.0.0.0/0 را در جدول مسیریابی اصلی میگذارد و آن را به سمت تونل نشانه میگیرد. WireGuard این را از AllowedIPs میگیرد، OpenVPN از redirect-gateway هلدادهشده، و هر دو مسیر را برای هر میزبان پشت روتر تغییر میدهند. باریککردن AllowedIPs یا افزودن route-nopull چیزی را تغییر میدهد که کلاینت نصب میکند. اما تغییر نمیدهد که نصب برای چه کسی اعمال میشود، زیرا کلاینت هرگز دستگاهها را نمیبیند. فقط بستهها را میبیند.

انتخاب بر پایه مبدأ یا مقصد یک تصمیم مسیریابی است، پس به لایه سیاست روتر تعلق دارد: یک قاعده mangle بههمراه جدول دوم در RouterOS، یک MARK بههمراه ip rule در OpenWrt یا DD-WRT، یا یک قاعده فایروال که دروازهاش تونل است در pfSense. دستورالعمل کلاینت WireGuard از Netgate همان چیزی است که باید پیش از حدسزدن بخوانید، زیرا در آن بستر دروازه قاعده، تخصیص رابط و ورودی NAT خروجی همه باید توافق داشته باشند تا یک کلاینت از تونل استفاده کند.

نیمه دوم افسانه، روتر دوم است. خرید جعبه دیگر یا انتقال دستگاه به SSID مهمان اغلب واقعاً کار میکند و دلیلش سختافزار نیست: دستگاه را روی زیرشبکه خودش میگذارد و همان انتخابگر مبدأ را به شما میدهد که فریمور از قبل میفهمد. اگر بتوانید آن بخش را روی روتری که دارید تعریف کنید، جعبه اضافی مشکلی را حل میکند که نداشتید.

بخش یک: تونلی که مسیر پیشفرض نیست

در RouterOS کلاینت را بدون مسیر پیشفرض اضافه کنید و به تونل جدول خودش را بدهید. مسیر اول پیشفرض علامتخورده است؛ دومی نیمه شکست.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

مسیر unreachable دلیل برتری جدول علامتخورده بر فهرست استثناها در جدول اصلی است. وقتی تونل قطع میشود، بستههای علامتخورده فوراً unreachable میگیرند بهجای آنکه بیصدا به WAN برگردند، پس شکست در پیام خطای برنامه دیده میشود، نه در صفحه مکان جغرافیایی که یک ساعت بعد بررسی میکنید.

RouterOS 7 چیزی را جدا میکند که 6.x کنار هم نگه میداشت: جدول را با /routing table add name=vpn fib اعلام میکنید، سپس در مسیر و در قاعده mangle با نام به آن ارجاع میدهید. قطعه 6.x که routing-mark را درونخطی میگذارد بدون تعریف جدول، تمیز بارگذاری میشود و با هیچچیز مطابقت ندارد. مورد کلاسیک دیگر دو نیمه 0.0.0.0/1 است، یا دو پیشفرض با فاصله یکسان در یک جدول: هسته یکی را انتخاب میکند و رفتار میتواند پس از راهاندازی مجدد تغییر کند.

بخش دو: علامتگذاری پیش از جستوجوی مسیر

انتخابگر تعیین میکند کدام بستهها وارد آن جدول شوند. RouterOS معمولاً با فهرست نشانی برای سیاست مقصد شروع میکند، یا با نشانی مبدأ برای سیاست دستگاه:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

فریمور لینوکس همان کار را با یک علامت netfilter و قاعدهای انجام میدهد که بستههای علامتخورده را به جدولی میفرستد که پر کردهاید:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

زنجیره یک انتخاب سلیقه نیست. زمانی که بسته به FORWARD میرسد، جستوجوی مسیر قبلاً انجام شده، پس MARK یا DROP در آنجا فقط میتواند بازنویسی یا دورانداختن کند. علامت باید در PREROUTING برای ترافیک ارسالی و در OUTPUT برای ترافیکی که خود روتر میسازد قرار بگیرد، همانجا که DNS و NTP و بررسیهای بهروزرسانی روتر زندگی میکنند. همین مسیر خروجی دلیل معمول آن است که یک راهاندازی کاملاً تونلشده در آزمون نشت هنوز از resolver ISP پاسخ میدهد.

سیاست دستگاه به تطبیقی نیاز دارد که جابهجا نشود. نشانی را در DHCP رزرو کنید، یا برای یک بخش اختصاصی یک رابط را تطبیق دهید؛ نشانیای که بعداً به دستگاه دیگری منتقل شود، تونل را بیصدا روی کلاینت اشتباه اعمال میکند. پل بهازای هر SSID با زیرشبکه خودش نسخه بادوامتر همان ایده است و به قواعد IPv6 هم جایی برای زندگی میدهد.

بخش سه: NAT، DNS و استثنای LAN

ترافیکی که از تونل خارج میشود به نشانی مبدأیی نیاز دارد که طرف دور به آن پاسخ دهد. ترجمه را به رابط تونل محدود کنید: out-interface=VPN_NAME در RouterOS، و -o tun0 در لینوکس، و ورودی NAT خروجی متناظر در pfSense. قاعده masquerade بدون این محدودیت ترافیکی را بازنویسی میکند که میخواستید رهایش کنید، و نشانه آن است که دستگاه تونلنشده نشانی عمومیاش را از دست میدهد.

استثنای LAN رشتههای پشتیبانی بیشتری از خود تونل ایجاد میکند. اگر جدول علامتخورده فقط یک مسیر پیشفرض داشته باشد، مقصد چاپگر یا NAS از دستگاه انتخابشده با همان پیشفرض مطابقت میکند و در تونل ناپدید میشود. مسیر LAN را به همان جدول اضافه کنید، یا زیرشبکه محلی را در انتخابگر مستثنی کنید؛ هر دو کار میکنند و وقتی بعداً VLAN اضافه کنید نگهداشتن استثنا درست آسانتر است.

DNS مسیر جداگانهای میگیرد. پرسوجوهایی که روتر ارسال میکند از خود روتر میآیند و از OUTPUT پیروی میکنند، نه از علامت ارسال، پس یک لپتاپ کاملاً تونلشده میتواند هنوز از طریق ISP تفکیک شود. کلاینتها را به resolverی که از طریق تونل قابل دسترسی است اشاره دهید، یا ترافیک پورت 53 خود روتر را علامت بزنید، سپس نشانی تفکیکشده را بررسی کنید بهجای آنکه فرض کنید پاسخ همراه درخواست وب سفر کرده است.

وقتی قاعده مطابقت دارد اما برنامه هنوز از WAN استفاده میکند

فهرستهای مقصد بد فرسوده میشوند. یک نام به نشانیای تفکیک میشود که در فهرست نیست، پس درخواست WAN را میگیرد در حالی که هر آزمونی که روی نشانی فهرستشده انجام دادید کار میکرد. فهرست را از همان resolverی بهروز کنید که کلاینت استفاده میکند، و وقتی واقعاً همه ترافیک یک دستگاه را میخواهید انتخابگر مبتنی بر مبدأ را ترجیح دهید.

IPv6 همان دورزدن آرام است. دستگاه خانواده نشانی دومی با مسیر پیشفرض و مجموعه قواعد خودش دارد، و تطبیق فقط نشانی IPv4 نیمی از سیاست است. همان انتخابگر را روی ip6tables یا معادل nftables اعمال کنید، یا IPv6 را در آن بخش آگاهانه غیرفعال کنید، نه تصادفی.

اتصالات برقرارشده هم مهماند. ورودی conntrackی که پیش از تغییر ساخته شده مسیر قدیمی را تا انقضا دنبال میکند، پس مرورگری که در طول ویرایش باز مانده دقیقاً مثل قاعدهای به نظر میرسد که هرگز اعمال نشده است. پیش از داوری درباره سیاست، اتصال تازه باز کنید یا وضعیت را پاک کنید.

با دو دستگاه و یک راهاندازی مجدد بررسی کنید

دستگاهی که باید تونل شود و دستگاهی که نباید را بیازمایید و پرش دوم را مقایسه کنید، نه یک عدد سرعت. traceroute از هر یک در پرش دوم یا دروازه تونل را نشان میدهد یا دروازه ISP را؛ اگر هر دو یکسان به نظر برسند، علامت یا جدول آن کاری را که قاعده میگوید انجام نمیدهد. برای آزمون از اتصالهای تازه استفاده کنید.

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

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