دروازه VPN روی Raspberry Pi: یک کارت شبکه یا یک پورت اختصاصی کلاینت
یک پورت Pi می‌تواند به کلاینت‌های برگزیده خدمت کند، یا پورت دومی می‌تواند دستگاه‌ها را درون حصار کند. چیدمان را بر پایه جداسازی، سیاست بازگشت و این‌که DNS از آنِ کیست برگزینید.
شما یک Pi، یک پروفایل VPN خروجی کارکننده و دو دستگاهی دارید که باید از طریق آن به اینترنت برسند. پرسشی که کل ساخت را تعیین می‌کند این نیست که کدام راهنما را دنبال کنید، بلکه این است که چه مقدار جداسازی لازم دارید. یک پورت اجازه می‌دهد Pi در کنار آن دستگاه‌ها روی LAN روتر بایستد و به‌عنوان دروازه اضافی عمل کند؛ پورت دوم اجازه می‌دهد آن‌ها را در بخشی قرار دهید که Pi تنها راه خروج است. هر چیزی پس از این انتخاب — DHCP، دامنه فایروال، DNS، حالت قطع — از آن نتیجه می‌شود.
این دو چیدمان در واقع در چه چیزی تفاوت دارند
هر دو طرح مسیریابی می‌کنند. تفاوت در این است که چه کس دیگری روی سیم است و وقتی سیاست شما اشتباه باشد چه می‌شود.
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
جداسازی محور واقعی است. چیدمان A توصیه‌ای است: دستگاهی که دروازه داده‌شده توسط DHCP را نادیده بگیرد و روتر را انتخاب کند، هنوز کار می‌کند، اما بدون رمزگذاری. چیدمان B با توپولوژی اعمال می‌شود، چون هیچ گام بعدی دیگری برای انتخاب وجود ندارد.
چیدمان A: Pi به‌عنوان دروازه اضافی روی LAN موجود
فرض کنید روتر ISP همان 192.168.50.1 است، Pi همان 192.168.50.2 است و کلاینت‌های انتخابی به Pi اشاره می‌کنند. مهم این است که دو جریان بسته متفاوت یک کابل را سهیم می‌شوند. بسته درونی کلاینت به Pi می‌رسد و باید از تونل خارج شود؛ بسته رمزگذاری‌شده خود Pi به همتای VPN باید از همان کابل به سمت روتر خارج شود. آن‌ها در جهت‌های مخالف روی یک واسط حرکت می‌کنند و به رفتار متفاوتی نیاز دارند.
آدرس Pi را از طریق مدیر شبکه نصب‌شده بدهید، نه با یک دستور قدیمی فایل واسط که بر سر دستگاه با آن کشمکش می‌کند. سپس کلاینت‌ها را تنظیم کنید: یک دروازه ثابت روی یک دستگاه، یا یک رزرو DHCP که 192.168.50.2 را به‌عنوان روتر می‌دهد. کل دامنه DHCP روتر را برای دو دستگاه تغییر ندهید، و فرض نکنید که کلاینت این گزینه را رعایت می‌کند — آن را بررسی کنید.
ضعف ساختاری است، نه قابل‌رفع. هر کلاینتی در آن بخش می‌تواند به 192.168.50.1 اشاره کند و بدون رمزگذاری خارج شود، و دستگاهی با واسط دوم یا رادیوی سلولی کاملاً از مسیر اعمال شما بیرون می‌رود. اگر آن جمله برای دستگاه موردنظر پذیرفتنی نیست، پاسخ خود را دارید: از چیدمان B استفاده کنید.
چیدمان B: یک پورت اختصاصی دستگاه‌ها را درون حصار می‌کند
در اینجا Pi آدرس 192.168.50.2 را روی پیوند بالاسو با دروازه 192.168.50.1 نگه می‌دارد و 10.20.0.1/24 را روی واسط دوم برای دستگاه‌های متصل می‌گیرد. اکنون Pi روتری با دو شبکه است، و بخش متصل دقیقاً یک خروجی دارد.
محدوده را پیش از تعهد در برابر همه چیز دیگر بررسی کنید: زیرشبکه خود تونل، پیشوندهای دیگر میان سایت‌ها، و هر چیزی که از طریق VPN قابل دسترسی است. یک 10.20.0.0/24 که با یک LAN دوردست تصادم کند، همان نتیجه نیمه‌کاره‌ای را می‌دهد که یک شب کامل برای تشخیص می‌برد. اگر پورت دوم یک مبدل USB است، تأیید کنید که پشتیبانی می‌شود و نامش را در مدیر شبکه تثبیت کنید تا جابه‌جایی پس از راه‌اندازی مجدد آدرس LAN شما را جابه‌جا نکند.
شنونده DHCP را فقط روی همان واسط اجرا کنید. سروری که روی پیوند بالاسو پاسخ می‌دهد با روتر ISP رقابت می‌کند و آدرس‌های بخش شما را به بقیه خانه می‌دهد. آن را به واسط LAN ببندید، به محدوده اعلام‌شده محدود کنید و آدرس خود Pi را بیرون از استخر نگه دارید.
ارسال، ترجمه و قاعده بستن در هنگام شکست
چهار چیز اغلب یکی توصیف می‌شوند و یکی نیستند. فعال کردن ارسال (net.ipv4.ip_forward=1) فقط به هسته می‌گوید که می‌تواند بسته‌ها را میان واسط‌ها جابه‌جا کند؛ خودش چیزی را مجاز نمی‌کند و هیچ مسیری را تضمین نمی‌کند. انتخاب خروجی یک تصمیم مسیریابی است. مجاز دانستن بسته یک تصمیم سیاست در زنجیره forward است. بازنویسی مبدأ آن یک تصمیم postrouting است. ساختاری که فقط اولی را انجام می‌دهد، Piای می‌سازد که با خوشحالی ترافیک کلاینت را از پیوند بالاسو به بیرون ارسال می‌کند.
مجوز را به همان مبدأهایی که منظورتان بود و به واسطی که ترافیک باید استفاده کند محدود کنید، و مسیر بازگشت و مقصدهای لازم خود Pi را نیز شامل شوید. سپس اگر ارائه‌دهنده پیشوند LAN شما را به سمت شما بازمسیریابی نمی‌کند، روی خروجی تونل ترجمه کنید. راهنمای nftables ارسال، خروجی محلی و ترجمه مبدأ را عملیات‌های جداگانه می‌داند، که مدل ذهنی درست در اینجا است.
شکست رایج یک قاعده masquerade گسترده روی واسط فیزیکی است. آنگاه ترافیک از مسیر ISP به اینترنت می‌رسد، در حالی که از سمت کلاینت دقیقاً مانند یک VPN کارکننده به نظر می‌رسد. این هیچ چیزی را اثبات نمی‌کند. ترجمه را به خروجی اعلام‌شده بسته نگه دارید و قاعده‌های خود را در همان فایروالی نگه دارید که میزبان از قبل استفاده می‌کند، به‌جای افزودن یک مجموعه قاعده رقیب که یک زنجیره postrouting مشترک را خالی می‌کند.
سپس نبود تونل را مدیریت کنید. یک پروفایل کلاینت که مسیر پیش‌فرض گسترده‌ای نصب می‌کند یعنی همچنین وقتی تونل می‌افتد، پیش‌فرض معمولی می‌تواند برگردد و ترافیک کلاینت بی‌صدا به پیوند بالاسو بازمی‌گردد. جایی که بازگشت به متن آشکار پذیرفتنی نیست، سیاست forward باید ترافیک کلاینت به پیوند بالاسو را صراحتاً رد کند، در حالتی که مسیر VPN رفته است. آن را به‌عنوان قاعده رد بنویسید، نه به‌عنوان فرض. انتقال رمزگذاری‌شده خود Pi به همتای VPN یک جریان local-output جداست و باید مجاز بماند، وگرنه تونل هرگز نمی‌تواند برگردد.
DNS و IPv6 پاسخ خودشان را لازم دارند
اگر کلاینت‌ها از Pi به‌عنوان حل‌کننده استفاده کنند، به یک شنونده محلی می‌رسند و Pi یک پرس‌وجوی تازه آغاز می‌کند. آن پرس‌وجوی بالاسو مسیر خود Pi را دنبال می‌کند، نه قاعده forward که برای کلاینت‌ها نوشتید، پس مسیر کلاینت فقط از تونل به‌همراه حل‌کننده‌ای که مستقیم خارج می‌شود یک نشت بدون هیچ پیام خطاست. آگاهانه تصمیم بگیرید: حل‌کننده‌ای که از تونل به آن می‌رسید، یا یکی محلی که آن را مستقیم می‌پذیرید، و سیاست خروج خود Pi را با آن تصمیم هم‌خوان کنید.
IPv6 دوباره جداگانه است. یک قاعده forward برای IPv4 هیچ چیز را درباره IPv6 محدود نمی‌کند، و اعلام‌های روتر روی پیوند بالاسو می‌توانند به Pi و از طریق آن به بخش متصل، یک پیش‌فرض دوم بدهند که سیاست شما را دور می‌زند. یا به IPv6 بر همان اصل مسیر محافظت‌شده خودش را بدهید، یا آن را صراحتاً در بخش کلاینت محدود کنید و همان را بگویید.
مرز را پیش از اعتماد آزمایش کنید
طرح را تنها پس از چهار بررسی جداگانه بپذیرید، چون آزمون تک وسوسه‌انگیز — باز کردن یک مرورگر روی یک کلاینت — در چند حالت خراب هم موفق می‌شود.
تأیید کنید که یک کلاینت واقعی از طریق تونل به اینترنت می‌رسد، سپس تأیید کنید که همان کلاینت با افتادن تونل نمی‌تواند به اینترنت برسد. تأیید کنید که تفکیک DNS کار می‌کند و پرس‌وجو از جایی که منظورتان بود خارج می‌شود. تأیید کنید که انتقال خود Pi پس از راه‌اندازی مجدد تونل هنوز کار می‌کند، و بازیابی نیازی به راه‌اندازی مجدد ماشین ندارد. در پایان، دستگاهی را بررسی کنید که انتخاب نکرده‌اید: در چیدمان A باید به‌طور عادی کار کند، و در چیدمان B نباید اصلاً در آن بخش وجود داشته باشد.
- دو پورت و یک قاعده رد، اعمال را می‌دهند؛ یک پورت و یک گزینه DHCP، توصیه را.
- ترجمه روی واسط اشتباه مانند موفقیت به نظر می‌رسد و نیست.
- ترافیک خود Pi، DNS و IPv6 هر یک به تصمیم نیاز دارند، نه به استنتاج.