هوم‌لب و میزبانی شخصی

Lange wollte ich einen eigenen Server betreiben, hatte aber Respekt vor den Kosten und der Komplexität. Dann bin ich auf Proxmox VE gestoßen — und im Nachhinein frage ich mich, warum ich es nicht früher getan habe. Proxmox ist eine kostenlose, quelloffene Virtualisierungsplattform auf Debian-Basis: KVM für vollwertige VMs, LXC für schlanke Container und ein Web-Interface, das einem den Alltag wirklich erleichtert.

Das Schöne ist, dass man keinen teuren Server braucht. Mein Einstieg war ein gebrauchter Mini-PC (ein Dell OptiPlex Micro) mit aufgerüstetem RAM und einer NVMe-SSD — leise, stromsparend und für 10–15 Container plus ein paar VMs völlig ausreichend. Bei den Strompreisen hierzulande macht ein Mini-PC mit 10–15 Watt Idle einen riesigen Unterschied zu einem Rack-Server.

Nach der Installation habe ich als Erstes das Enterprise-Repository deaktiviert und die Community-Repos eingerichtet, SSH-Login per Key abgesichert und Fail2ban installiert. Dann kamen die ersten Services: Pi-hole als netzwerkweiter Werbeblocker, Nginx Proxy Manager und Portainer. Die Reihenfolge hat sich bewährt — klein anfangen, nicht gleich zwanzig Container auf einmal.

Mein wichtigster Rat, den ich selbst erst schmerzhaft lernen musste: Richte Backups ein, bevor du den ersten Service installierst. Nach der 3-2-1-Regel, und die eingebauten Snapshot-Backups von Proxmox machen das fast schon zu einfach. RAID ist übrigens kein Backup — das habe ich auch erst begreifen müssen.

Fang einfach an. Ein Container, ein Service, und du lernst mehr über Infrastruktur als in jedem Online-Kurs. Und wer erst nur ausprobieren will, kann zum Lernen auch einen günstigen Cloud-Server nehmen.

Quelle: Homelab Guide

به گزارش IT之家، NAS چهاربخشی QNAP با نام Qu405-N150-8G اکنون در JD.com به فروش می‌رسد. این دستگاه ۸ گیگابایت حافظه دارد و گارانتی استاندارد دو ساله همراه آن است. قیمت دستگاه به تنهایی ۲۵۹۹ یوان است و بسته‌ای که همراه هارد Seagate IronWolf ۴ ترابایتی عرضه می‌شود ۳۵۹۹ یوان قیمت دارد.

طراحی آن ساده است. ابعاد بدنه ۱۶۵ × ۱۶۸ × ۲۱۷ میلی‌متر و وزن خالص آن ۲.۱۵ کیلوگرم است. پردازنده، Intel N150 با ۴ هسته و ۴ رشته است. طبق اعلام سازنده، این دستگاه می‌تواند ویدیوی ۴K را تبدیل کند و ماشین‌های مجازی و کانتینرهای Docker را اجرا کند؛ این موضوع برای کسانی که با سرورهای خانگی کار می‌کنند امتیاز بزرگی است. حافظه‌ی ۸ گیگابایتی SODIMM DDR4 که همراه دستگاه است تا ۱۶ گیگابایت قابل ارتقاست.

برای ذخیره‌سازی چهار جای‌گاه برای دیسک‌های SATA سه‌ونیم یا دو‌ونیم اینچی وجود دارد. در داخل دستگاه هم دو اسلات M.2 2280 NVMe با رابط PCIe Gen 3 x1 تعبیه شده که می‌توان از آن‌ها برای کش یا نگهداری داده‌های سیستم و کانتینرها استفاده کرد. درگاه‌ها شامل دو پورت شبکه‌ی 2.5GbE، دو USB-A 3.2 Gen 2، یک USB-C 3.2 Gen 2 و یک HDMI 2.1 هستند.

به نظر من ترکیب دو پورت 2.5G با N150 در دو سال اخیر به پیکربندی رایج NASهای خانگی ورودی تبدیل شده است. این دستگاه بدون مصرف زیاد برق می‌تواند Docker اجرا کند و قیمتش هم منطقی است. با این حال، مقاله فقط مشخصات فنی را آورده و آزمایش واقعی ندارد؛ بنابراین اگر قصد خرید دارید، بهتر است پیش از آن نویز، مصرف برق و تجربه‌ی نرم‌افزاری را در بررسی‌های مستقل ببینید.

منبع: IT之家

Synology سری جدید neo+ را برای آلمان معرفی کرده است که از DS725neo+، DS925neo+، DS1525neo+ و DS1825neo+ تشکیل شده است. ComputerBase این مدل‌ها را نسخه‌های ارزان‌تر مدل‌های Plus توصیف می‌کند که فقط پیکربندی حافظه‌شان تغییر کرده است.

بر اساس این گزارش، «neo» به معنای «گزینه Non-ECC» است. این دستگاه‌ها از حافظه معمولی بدون ECC استفاده می‌کنند و همیشه فقط ۴ گیگابایت دارند. مدل‌های DS725+ و DS925+ دارای ۴ گیگابایت حافظه ECC هستند، در حالی که DS1525+ و DS1825+ دارای ۸ گیگابایت حافظه ECC هستند؛ بنابراین نسخه‌های neo+ حافظه کمتری دارند. در غیر این صورت، امکانات، قابلیت‌ها و امکان گسترش با مدل‌های Plus یکسان است و DSM با برنامه‌هایش نیز یکسان است.

در قیمت خرده‌فروشی پیشنهادی سازنده، اختلاف حدود ۲۰۰ یورو است: قیمت DS725neo+ بدون مالیات ۵۴۹ یورو و قیمت DS725+ بدون مالیات ۷۴۸ یورو اعلام شده است. اما در بازار، فاصله به این اندازه آشکار نیست: DS725+ هم‌اکنون از ۶۶۳ یورو و DS725neo+ از ۶۲۹ یورو عرضه می‌شود. حافظه را بعداً می‌توان به‌راحتی به ECC ارتقا داد.

Synology دلیل این کار را شرایط فعلی بازار حافظه، یعنی افزایش‌های قابل توجه قیمت که مدل‌های Plus را هم تحت تأثیر قرار داده، عنوان می‌کند.

برای سرور خانگی، این به نظر من یک مصالحه جالب است. کسی که NAS را بیشتر برای پشتیبان‌گیری، رسانه و چند کانتینر استفاده می‌کند، احتمالاً با ۴ گیگابایت بدون ECC کنار خواهد آمد. کسی که به یکپارچگی داده اهمیت می‌دهد، باید دقیقاً ببیند برای این اختلاف قیمت چه چیزی دریافت می‌کند.

منبع: ComputerBase

Hardware.com.br هوم‌لبی را معرفی می‌کند که با اندازه کوچکش توجه را جلب می‌کند. یک کاربر Reddit در r/HomeServer رک کوچک ۱۰ اینچی‌ای را منتشر کرده که شامل یک فایروال، سه مینی‌پی‌سی، یک NAS و تمام زیرساخت شبکه لازم برای اجرای ده‌ها سرویس در خانه است.

پردازش را سه مینی‌پی‌سی انجام می‌دهند که هرکدام پردازنده‌ای با ۸ هسته و ۱۶ رشته و ۳۲ گیگابایت RAM دارند؛ در مجموع ۲۴ هسته، ۴۸ رشته و ۹۶ گیگابایت برای مجازی‌سازی. او برای ساخت ماشین‌های مجازی و کانتینرهای LXC از Proxmox استفاده می‌کند. از جمله بارهای کاری، یک ماشین مجازی برای Jellyfin، پشته arr که روی Docker اجرا می‌شود، یک میزبان Docker دیگر با Portainer، Pi-hole و داشبوردهایی مانند Homer و Homepage، و همچنین سرورهای بازی مانند Terraria و Core Keeper وجود دارد.

فضای ذخیره‌سازی روی یک HP ProLiant MicroServer با چهار دیسک سخت ۴ ترابایتی در RAIDZ1 مربوط به ZFS قرار دارد که اگر یک دیسک خراب شود همچنان امکان دسترسی به داده‌ها فراهم است. ظرفیت خام ۱۶ ترابایت است، اما به خاطر پریتی فضای قابل استفاده کمتر است. شبکه را یک Fortinet FortiGate کنترل می‌کند که مسیریابی، VLAN و SSL VPN را بر عهده دارد، و یک یو‌پی‌اس APC Back-UPS 850 از قطعی برق محافظت می‌کند.

به نظر من جالب‌ترین بخش بیرون از خانه است: مالک دو VPS با Debian در مراکز داده خارجی دارد که با یک شبکه WireGuard به صورت hub-and-spoke به هوم‌لب متصل‌اند. آنها لایه عمومی زیرساخت را تشکیل می‌دهند و Traefik به عنوان reverse proxy کار می‌کند.

این نمونه خوبی است که نشان می‌دهد هوم‌لب به رک بزرگ نیاز ندارد: با برنامه‌ریزی، دستگاه‌های کوچک و سازماندهی مناسب، می‌توان در فضای کم کارهای زیادی را اجرا کرد.

منبع: Hardware.com.br

اگر روی یک سرور بیش از یک پروژه اجرا شود، دیر یا زود به پورت‌های ۸۰ و ۴۴۳ برمی‌خورید که فقط یک فرایند می‌تواند روی آن‌ها گوش دهد. مقاله‌ای در Habr از وبلاگ Selectel، گام‌به‌گام نشان می‌دهد که چگونه با Nginx Proxy Manager این مشکل را حل کنیم.

نویسنده ابتدا مسئله را توضیح می‌دهد: پورت‌های ممتاز، قاعده «یک شنونده برای هر پورت»، مشکلات CORS وقتی فرانت‌اند و بک‌اند روی پورت‌های جدا قرار می‌گیرند، و نبود HTTPS. پروکسی معکوس به‌عنوان واسطه این مشکل را حل می‌کند و ترافیک را بر اساس دامنه و مسیر هدایت می‌کند. مزیت دیگر این است که فایروال فقط به پورت‌های ۲۲، ۸۰ و ۴۴۳ نیاز دارد.

محیط آزمایش یک VDS با ۲ vCPU، ۲ گیگابایت رم و ۴۰ گیگابایت NVMe با Ubuntu 24.04 و Docker از مخزن رسمی است. شبکه با docker network create proxy ساخته می‌شود و کانتینر jc21/nginx-proxy-manager با حجم‌هایی برای داده و گواهی راه‌اندازی می‌شود. خوشم آمد که پنل مدیریت روی پورت ۸۱ فقط به 127.0.0.1 متصل است و از طریق تونل SSH دسترسی پیدا می‌شود.

سپس یک میزبان پروکسی تنظیم می‌شود: در Forward Hostname نام کانتینر وارد می‌شود و گواهی SSL در برگه SSL متصل می‌شود. برای آزمایش از traefik/whoami استفاده شده است. حالتی که برنامه مستقیم روی میزبان اجرا می‌شود هم جداگانه بررسی شده: آدرس گیت‌وی شبکه داکر با docker network inspect به دست می‌آید و فایروال طوری تنظیم می‌شود که برنامه بدون عبور از پروکسی قابل دسترسی نباشد.

بعضی ایرادها هم دارد. مثال‌ها دامنه‌های مختلف را قاطی کرده‌اند و ایمیج با تگ latest آمده که ممکن است با گذشت زمان تکرارپذیری را کم کند. با این حال نقطه شروع خوبی است برای کسانی که می‌خواهند چند سرویس را در خانه یا روی VDS اجرا کنند بی‌آنکه پیکربندی nginx را دستی ویرایش کنند.

منبع: Habr (وبلاگ Selectel)

نشریه هفتگی Self-Host از selfh.st این هفته اخبار مفیدی را برای علاقه‌مندان به هوم‌لب گردآوری کرده است. من این‌جور مرورها را دوست دارم، چون وقت زیادی از خواندن تک‌تک فیدها را ذخیره می‌کنند.

خبر اصلی ماجرایی درهم‌تنیده است: مجموعه تازه‌ای از جایگزین‌های متن‌باز Adobe به کپی‌برداری از پروژه‌های موجود متهم شد، به‌ویژه Photopea که در میان جامعه محبوب است و توسعه‌دهنده‌اش از نخستین کسانی بود که هشدار داد. دو پروژه‌ی محوری، PhotoSuite و PhotoCraft، ظاهراً به هم مرتبط‌اند و ترتیب رویدادها دنبال کردنش دشوار است. نشریه توصیه می‌کند تا وقتی ثابت نکرده‌اند بیش از یک اثر مشتق‌شده هستند، از آن‌ها دوری کنید.

چند نکته‌ی کوچک‌تر هم ارزش توجه دارد. Let's Encrypt اعلام کرده که از فوریه ۲۰۲۷ مدت اعتبار گواهی‌های SSL رایگان از ۹۰ روز به ۶۴ روز کاهش می‌یابد؛ این یعنی تمدید خودکار مطمئن برای کسانی که در خانه reverse proxy دارند اهمیت بیشتری پیدا می‌کند. Nabu Casa نام Home Assistant Cloud را به Home Assistant Link تغییر می‌دهد، زیرا واژه‌ی cloud امروز بار منفی دارد. پروژه‌ی اشتراک‌گذاری رمز رمزنگاری‌شده Hemmelig در GitHub بایگانی شده است. و NVIDIA Shield TV، جعبه‌ی استریمی هفت‌ساله که بین علاقه‌مندان هوم‌لب محبوب است، ۱۰۰ دلار گران شده و شرکت این افزایش را به تورم سخت‌افزار ناشی از هوش مصنوعی نسبت داده است.

نویسنده همچنین نظرسنجی کاربران Self-Host 2026 را با ۴۵ پرسش درباره‌ی سخت‌افزار، نرم‌افزار، سیستم‌عامل، ویژگی‌های جمعیتی و هوش مصنوعی آغاز کرده است. نظرسنجی سال گذشته بیش از ۴۰۰۰ پاسخ گرفت و امسال در دو روز به ۲۰۰۰ پاسخ رسیده است. این نظرسنجی تا ۳۱ اکتبر باز است و نتایج آن اوایل نوامبر منتشر می‌شود.

به نظر من کاربردی‌ترین خبر، تغییر در گواهی‌هاست. اگر راه‌اندازی تمدید شما کمی شکننده است، اکنون زمان خوبی برای آزمودنش است.

منبع: selfh.st

RedesZone به پرسشی پاسخ می‌دهد که بسیاری از کسانی که سرور خانگی می‌سازند با آن روبه‌رو می‌شوند: آیا NAS باید هر از گاهی دوباره راه‌اندازی شود یا می‌توان آن را همیشه روشن نگه داشت؟

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

با این حال مواردی وجود دارد که راه‌اندازی مجدد توصیه می‌شود: بعد از به‌روزرسانی سیستم‌عامل، فریم‌ور یا برخی بسته‌ها، حتی اگر دستگاه درخواست نکرده باشد؛ هنگام مشکلات نرم‌افزاری، مانند توقف یک برنامه، کند شدن یک سرویس، رفتار نامناسب رابط وب یا بروز خطا در بخشی از سیستم؛ پس از تعویض سخت‌افزار و بعد از هر تغییر مهم در نحوه کار. گاهی یک فرایند قفل می‌شود یا برنامه‌ای به درستی بسته نمی‌شود و راه‌اندازی مجدد همه‌چیز را به حالت عادی برمی‌گرداند.

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

منبع: RedesZone

وقتی اپلیکیشن‌های متن‌باز روی یک سرور خانگی اجرا می‌شوند، اغلب لازم است برای ثبت‌نام یا بازیابی رمز عبور ایمیل ارسال شود. اما ارسال مستقیم ایمیل از خانه نیازمند راه‌اندازی یک سرور SMTP و پیکربندی دامنه فرستنده است و کار بیشتر از آنچه به نظر می‌رسد می‌برد. این مقاله که در Qiita پیدا کردم، این مشکل را با Mailpit و Discord به شکلی ساده حل می‌کند.

Mailpit در اصل ابزاری برای آزمایش ارسال ایمیل بود. می‌توان از آن به‌عنوان سرور SMTP استفاده کرد و یک API آزمایشی هم دارد. با تنظیم یک webhook، می‌تواند به محض رسیدن پیام، یک اپلیکیشن خارجی را فراخوانی کند. مقاله از همین قابلیت استفاده کرده تا محتوای ایمیل‌های دریافتی به Discord ارسال شود.

ساختار آن ساده است: دو کانتینر با Docker Compose اجرا می‌شوند، یعنی Mailpit و یک webhook-handler. webhook-handler یک برنامه‌ی کوچک پایتونی با FastAPI است. این برنامه webhookهای Mailpit را دریافت می‌کند، فرستنده و گیرنده را قالب‌بندی می‌کند و به یک webhook دیسکورد می‌فرستد. اعلان می‌تواند شامل لینکی به رابط وب Mailpit هم باشد تا در صورت نیاز ایمیل را ببینید. تنظیماتی مانند آدرس webhook در یک فایل .env جدا نگه داشته می‌شوند.

حتی بدون ارسال هیچ ایمیلی به بیرون، دانستن فوری اینکه ایمیل بازیابی رمز عبور رسیده، کاربردی است. برای کسی که چند برنامه را در یک هوم‌لب اجرا می‌کند، جمع کردن همه‌ی ایمیل‌ها در یک نقطه احتمالاً مدیریت را خیلی ساده‌تر می‌کند. این مطلب مربوط به اوت ۲۰۲۶ است.

منبع: Qiita

داستانی کوچک، اما برای هر کسی که شبکه خانگی خودش را مدیریت می‌کند ارزش فکر کردن دارد. به گفته GenK، کاربری در X به نام @NomadsGalaxy در حال بررسی وای‌فای خانه‌ی پدر و مادرش بود و متوجه شد که یک قهوه‌ساز Keurig فقط در ۱۰ روز حدود ۱ ترابایت آپلود و نزدیک به ۱۰ گیگابایت دانلود تولید کرده است.

او این موضوع را هنگام بررسی سیستم شبکه UniFi در خانه‌ی والدینش کشف کرد. این حجم غیرعادی داده یکی از نقاط دسترسی وای‌فای را بیش از حد بار کرد. او به‌جای بررسی علت، دستگاه را از برق کشید و برای والدینش محصول دیگری خرید. طبق مقاله، بیشتر ترافیک به‌نظر می‌رسد در شبکه داخلی جریان داشته و به اینترنت نرفته، بنابراین هنوز مدرکی وجود ندارد که این دستگاه داده‌های خانواده را به سرورهای بیرونی فرستاده باشد. محتمل‌ترین علت خطای نرم‌افزاری یا اشکال در ارتباط شبکه است و راه‌اندازی مجدد ممکن است مشکل را حل کرده باشد.

این مقاله به تصویر بزرگ‌تر خانه‌ی هوشمند هم اشاره می‌کند: هرچه دستگاه‌های متصل به شبکه بیشتر باشند، احتمال خرابی، حفره‌های امنیتی یا قطعی سرویس بیشتر می‌شود. دستگاه‌های IoT اگر سازنده نرم‌افزارشان را مرتب به‌روز نکند، می‌توانند به دروازه‌ای برای حمله تبدیل شوند و برخی محصولات با بسته شدن سرورهای شرکت، بیشتر امکاناتشان را از دست می‌دهند.

برای من درس عملی این است که ابزاری داشته باشیم که ترافیک هر دستگاه را در شبکه‌ی خانگی نشان دهد و به جداسازی دستگاه‌های IoT در شبکه‌ای جداگانه فکر کنیم. بدون عدد، تشخیص اینکه یک قهوه‌ساز دقیقاً چه کاری انجام می‌دهد بسیار دشوار است.

منبع: GenK

هر کسی که شبکه خانگی یا یک هوم‌لب کوچک را اداره می‌کند، پسوند .lan را خوب می‌شناسد: در پنل روترها، سرورهای DNS داخلی و نشانی‌هایی که برای رسیدن به دستگاه‌ها بدون دامنه ثبت‌شده استفاده می‌کنیم، دیده می‌شود. IlSoftware.it گزارش می‌دهد که درخواستی که به ICANN ارائه شده ممکن است آن را به یک دامنه اینترنتی تبدیل کند که در سراسر جهان قابل دسترس است.

درخواست مربوط به دامنه سطح بالای .lan توسط شرکت آمریکایی Coffee Danger ارائه شده و هنوز در مرحله Pre-Evaluation Processing است. یعنی این دامنه تأیید نشده و فعلاً نمی‌توان از آن برای ثبت نشانی‌های عمومی استفاده کرد. این درخواست بخشی از دور جدید واگذاری دامنه‌های سطح بالای ICANN است که در سال ۲۰۲۶ آغاز شد و صدها شرکت در آن شرکت دارند: از جمله متقاضیان، گوگل با .browser، OpenAI با .openai و .chatgpt، متا با .facebook و شرکت ایتالیایی Aruba با دامنه‌هایی مانند .pec، .vps، .lab، .roma و .ciao هستند. همه درخواست‌ها هنوز در معرض ارزیابی‌اند.

نکته حساس این است که .lan یک نام معمولی نیست. بسیاری از متخصصان مدت‌هاست از آن استفاده می‌کنند، مثلاً nas.lan، router.lan یا camera.lan. اگر نامی که داخلی تلقی می‌شد وارد DNS عمومی شود، خطر خرابی، پرس‌وجوهای DNS که از شبکه خارج می‌شوند و ارتباطاتی که به مقصدهای دیگر می‌رسند وجود دارد.

به عنوان علاقه‌مند به شبکه‌های خانگی، این خبر را یادآوری خوبی می‌دانم: برای نام‌های داخلی بهتر است از پسوندهایی استفاده کنیم که برای همین منظور طراحی شده‌اند، نه اینکه به قراردادهای عملی تکیه کنیم. فعلاً تصمیمی گرفته نشده، اما ارزش پیگیری دارد.

منبع: IlSoftware.it

Korben دوباره به یک دستور Cloudflare می‌پردازد که بسیاری از توسعه‌دهندگان از قبل استفاده می‌کنند: cloudflared tunnel --url. این دستور سروری را که روی رایانه‌ی شما اجرا می‌شود با نشانی trycloudflare.com منتشر می‌کند، بدون حساب کاربری، بدون نام دامنه و از همه مهم‌تر بدون اینکه پورتی روی مودم باز شود. برای کسی که سرویس‌هایش را در خانه اجرا می‌کند، این روشی ساده برای نشان دادن یک پروژه به کسی در یک آزمایش کوتاه است.

تازه‌ترین افزودنی گزینه‌ی --allowed-mail است. پیش‌تر هر کسی که پیوند را داشت می‌توانست به سرویس وصل شود. اکنون می‌توان دسترسی را به چند نشانی ایمیل دلخواه محدود کرد و یک کد یک‌بارمصرف از طریق Cloudflare Access فرستاده می‌شود.

آموزش با یک وب‌سرور محلی کوچک روی پورت ۸۰۸۰ شروع می‌شود که یک صفحه‌ی آزمایشی را با Python نمایش می‌دهد. cloudflared رابط متن‌بازی است که اتصال خروجی به شبکه‌ی Cloudflare را برقرار می‌کند. در Mac نصب آن از طریق Homebrew انجام می‌شود. در Debian یا Ubuntu باید از مخزن رسمی Cloudflare استفاده کرد که کلید امضای آن اخیراً تغییر کرده است، بنابراین نویسنده توصیه می‌کند دستورهای روز را دنبال کنید، نه دستورهای آموزش‌های قدیمی را.

یک نکته توجه مرا جلب کرد: اگر عامل‌های هوش مصنوعی را با این ابزار به کار می‌گیرید، Cloudflare یک hook از نوع PreToolUse پیشنهاد می‌کند که هر دستوری را بدون --allowed-mail مسدود کند تا یک عامل به‌اشتباه تونل عمومی باز نکند.

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

منبع: Korben