Reverse Proxy میکروتیک

اگه یه سرور یا چند تا سرویس پشت یه میکروتیک دارید و می‌خواید به همه‌شون با دامین و روی پورت 443 (HTTPS) دسترسی داشته باشید، حتماً یه جایی به این مشکل خوردید: یه IP پابلیک دارید، ولی چند تا سرویس مختلف می‌خواید پابلیش کنید. اینجا دقیقاً جایی هست که Reverse Proxy میکروتیک وارد میشه.

توی این پست از بخش آموزش میکروتیک، در مورد Reverse Proxy روی RouterOS صحبت می‌کنیم؛ از ماهیت و تفاوتش با NAT، تا کانفیگ کامل و عملیش روی روتر. پس در ادامه با من همراه باشین.

فهرست:

• Reverse Proxy چیست؟
• تفاوت Reverse Proxy با Forward Proxy
• چرا Port Forwarding (NAT) کافی نیست؟
• Reverse Proxy میکروتیک
• Reverse Proxy روی میکروتیک چطور کار می‌کنه؟
• کانفیگ Reverse Proxy میکروتیک
• پیش‌نیازهای کانفیگ ریورس پروکسی MikroTik
• آموزش گام‌به‌گام کانفیگ Reverse Proxy روی میکروتیک
• فایروال و یه نکته‌ی مهم که خیلیا فراموش می‌کنن
• یکپارچگی با Container و RouterOS Apps
• محدودیت‌های Reverse Proxy میکروتیک
• Reverse Proxy میکروتیک یا Nginx/Traefik روی Container؟
• عیب‌یابی (Troubleshooting)

Reverse Proxy چیست؟

ساده‌ترین تعریف: Reverse Proxy یه واسطه‌ست که بین کاربرهای اینترنت و سرورهای داخلی شما می‌نشینه، درخواست‌ها رو می‌گیره، و بر اساس یه قانون (معمولاً اسم دامین) تصمیم می‌گیره هر درخواست رو به کدوم سرور داخلی بفرسته.

یه مثال ملموس بزنیم: فرض کنید سه تا سرویس دارید که همه پشت یه میکروتیک و یه IP پابلیک هستن:

cloud.netadminhub.com: یه سرور Nextcloud
wiki.netadminhub.com: یه Wiki.js
panel.netadminhub.com: یه پنل مدیریتی

کاربر از بیرون فقط یه چیز می‌بینه: IP پابلیک میکروتیک، روی پورت 443. ولی Reverse Proxy، بر اساس اینکه کاربر داشته دنبال کدوم دامین می‌گشته، ترافیکش رو به سرور داخلی درست هدایت می‌کنه. خود کاربر اصلاً نمی‌دونه (و لازم نیست بدونه) که پشت صحنه چند تا سرور جدا داره باهاش صحبت می‌کنه.

تفاوت Reverse Proxy با Forward Proxy

این دوتا اسم شبیه‌ هم هستن ولی کارکردشون کاملاً برعکسه:

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

یه جور دیگه بخوایم بگیم: Forward Proxy از کلاینت محافظت می‌کنه و هویتش رو پنهان می‌کنه. Reverse Proxy از سرور محافظت می‌کنه و معماری داخلی شبکه رو پنهان می‌کنه.

چرا Port Forwarding (NAT) کافی نیست؟

اینجا سوالی پیش میاد که حتماً تو ذهنتون اومده: «خب من که می‌تونم با Dst NAT هم پورت 443 رو به یه سرور داخلی فوروارد کنم، این Reverse Proxy چه فرقی داره؟»

جواب کوتاه: NAT کور عمل می‌کنه. وقتی یه قانون Dst NAT می‌سازید، فقط می‌گید «هر چی روی پورت 443 اومد رو بفرست به IP فلان». NAT اصلاً سرش به محتوای بسته‌ها گرم نمی‌شه؛ نمی‌تونه به این سوال جواب بده که «کاربر داشت دنبال کدوم دامین می‌گشت؟»

نتیجه‌ش چیه؟ با NAT خام، فقط می‌تونید یک سرویس HTTPS رو روی پورت 443 پابلیش کنید. اگه بخواید سرویس دوم رو هم بیارید بیرون، باید پورت عوض کنید (مثلاً :8443) که هم زشته، هم خیلی جاها (پشت فایروال شرکتی، فیلترشکن‌های موبایل و…) بسته‌ست.

Reverse Proxy این مشکل رو حل می‌کنه چون لایه‌ی بالاتری از NAT کار می‌کنه (لایه‌ی Application، یعنی L7). میکروتیک باز کردن هندشیک TLS رو می‌بینه، اسم دامینی که کاربر خواسته رو از توش بیرون می‌کشه، و طبق جدول قوانینی که خودتون ساختید، تصمیم می‌گیره ترافیک رو کجا بفرسته. این یعنی با یک IP و یک پورت (443)، می‌تونید هر چقدر سرویس که بخواید پابلیش کنید.

Reverse Proxy میکروتیک

قبل از RouterOS 7.22، اگه می‌خواستید این کار رو روی میکروتیک انجام بدید، باید یه Reverse Proxy جداگانه (Nginx، HAProxy، Caddy، Traefik) می‌انداختید روی یه سرور دیگه، یا اگه سخت‌افزار میکروتیکتون قوی بود، به‌عنوان Container داخل خود روتر بالا می‌آوردیدش.

با عرضه‌ی RouterOS 7.22 میکروتیک یه Reverse Proxy بومی و درون‌ساختی (Native) اضافه کرد. این ابزار جایگزین کامل Nginx یا HAProxy نیست (بعداً در بخش محدودیت‌ها می‌گیم چرا)، ولی برای پابلیش کردن چند سرویس HTTPS ساده پشت یه IP، دقیقاً همون چیزیه که لازم دارید؛ بدون نصب هیچ Container یا سرور اضافه.

Reverse Proxy روی میکروتیک چطور کار می‌کنه؟

نکته‌ی فنی جالبی که اینجا هست: ترافیک HTTPS رمزنگاری‌شده. پس میکروتیک چطور می‌فهمه کاربر دنبال کدوم دامین می‌گرده، وقتی که هنوز نتونسته هدر Host رو بخونه؟

جواب: SNI (Server Name Indication). توی همون قدم اول هندشیک TLS (که به اسم TLS ClientHello شناخته می‌شه)، کلاینت قبل از اینکه هرگونه رمزنگاری شروع بشه، اسم دامینی که می‌خواد به‌اش متصل بشه رو به‌صورت متن ساده (plaintext) می‌فرسته. میکروتیک همین فیلد رو می‌خونه، با جدول قوانینش مطابقت می‌ده، و می‌فهمه این درخواست باید کجا بره.

جریان ترافیک این شکلیه:

کلاینت از اینترنت
        |
        | HTTPS (پورت 443)
        v
میکروتیک RouterOS (سرویس reverse-proxy)
        |
        | بررسی SNI از TLS ClientHello
        v
سرویس داخلی در LAN (یا کانتینر لوکال)

کانفیگ Reverse Proxy میکروتیک

کانفیگ Reverse Proxy روی میکروتیک توی دو قسمت انجام میشه:

1. سرویس سراسری: /ip/service/reverse-proxy

این یه سرویس سیستمی هست، دقیقاً مثل winbox، ssh یا www-ssl. اینجاست که موتور پراکسی رو روشن می‌کنید، پورت رو تنظیم می‌کنید (پیش‌فرض 443)، و گواهی SSL پیش‌فرض رو معرفی می‌کنید.

2. جدول قوانین: /ip/reverse-proxy

اینجا نقشه‌ی مسیریابی واقعی رو می‌سازید: کدوم دامین (SNI) باید به کدوم IP و پورت داخلی فوروارد بشه. جدول پراپرتی‌هاش این‌جوریه:

یه نکته‌ مهم اینجا: به‌صورت پیش‌فرض، سرویس reverse-proxy از همون پورت 443 استفاده می‌کنه که سرویس www-ssl (یعنی همون پنل وب میکروتیک روی HTTPS) هم ازش استفاده می‌کنه. اگه این دوتا رو با هم فعال کنید، یکیشون بالا نمیاد. پس باید یا www-ssl رو خاموش کنید، یا پورتش رو عوض کنید.

پیش‌نیازهای کانفیگ ریورس پروکسی MikroTik

قبل از شروع کانفیگ، این دوتا کار رو باید انجام بدید:

۱. آزاد کردن پورت 443: چون reverse-proxy و www-ssl هر دو می‌خوان از پورت 443 TCP استفاده کنن، باید یکیشون رو جابجا کنید. ساده‌ترین راه این هست که پنل وب رو روی یه پورت دیگه (مثلاً 8443) ببرید و دسترسیش رو فقط به شبکه‌ی داخلی محدود کنید.

۲. گواهی SSL: برای اینکه مرورگر کاربرها هشدار امنیتی ندن، نیاز به گواهی معتبر دارید. دو راه دارید:

• اگه دامین شخصی دارید، می‌تونید از کلاینت ACME خود میکروتیک برای گرفتن گواهی رایگان Let’s Encrypt استفاده کنید.
• اگه دامین ندارید، می‌تونید از سرویس DDNS رایگان میکروتیک (به فرمت xxxxx.sn.mynetname.net) استفاده کنید.

آموزش گام‌به‌گام کانفیگ Reverse Proxy روی میکروتیک

بیا فرض کنیم می‌خوایم دو سرویس داخلی رو پابلیش کنیم:

• cloud.netadminhub.com → سرور Nextcloud روی 192.168.88.10:80
• wiki.netadminhub.com → سرور Wiki.js روی 192.168.88.20:80

گام ۱: بکاپ بگیرید

قبل از هر تغییری در سرویس‌های شبکه و فایروال، همیشه بکاپ بگیرید:

/system/backup/save name=before-reverse-proxy<br>/export file=before-reverse-proxy

گام ۲: پورت 443 رو آزاد کنید

پنل وب رو روی پورت دیگه ببرید و فقط به LAN محدودش کنید:

/ip/service/set www-ssl port=8443 address=192.168.88.0/24

گام ۳: گواهی SSL بگیرید

اگه دامین شخصی دارید:

/certificate/add-acme directory-url=https://acme-v02.api.letsencrypt.org/directory domain-names=cloud.netadminhub.com,wiki.netadminhub.com

میکروتیک خودش گواهی رو می‌سازه و قبل از انقضا (در 80٪ عمرش) خودکار رنویش می‌کنه.

گام ۴: سرویس Reverse Proxy رو فعال کنید

اسم گواهی رو با /certificate/print چک کنید، بعد سرویس رو فعال کنید:

/ip/service/set reverse-proxy port=443 certificate=letsencrypt_cloud.netadminhub.com disabled=no

گام ۵: قوانین پراکسی رو بسازید

/ip/reverse-proxy/add sni=cloud.netadminhub.com ip-address=192.168.88.10 port=80 comment="Nextcloud"
/ip/reverse-proxy/add sni=wiki.netadminhub.com ip-address=192.168.88.20 port=80 comment="Wiki.js"

اگه پراپرتی certificate رو خالی (none) بگذارید، میکروتیک خودش از همون گواهی سراسری گام ۴ استفاده می‌کنه.

فایروال و یه نکته‌ی مهم که خیلیا فراموش می‌کنن

چون Reverse Proxy روی خود روتر اجرا می‌شه (نه روی یه سرور پشت روتر)، ترافیک ورودی مستقیماً به خود روتر آدرس‌دهی شده. این یعنی قانون فایروالی که باید بنویسید، باید توی چین input باشه، نه چین forward که همیشه برای ترافیک عبوری از NAT استفاده می‌کردیم:

/ip/firewall/filter/add chain=input action=accept protocol=tcp dst-port=443 in-interface-list=WAN comment="Allow HTTPS reverse-proxy"

اگه از Let’s Encrypt با چالش HTTP استفاده می‌کنید، پورت 80 هم باید باز باشه که سرور صادرکننده‌ی گواهی بتونه دامینتون رو تایید کنه:

/ip/firewall/filter/add chain=input action=accept protocol=tcp dst-port=80 in-interface-list=WAN comment="Allow HTTP for ACME challenge"

⚠️ این قوانین رو حتماً بالای قوانین Drop خودتون بگذارید، وگرنه هیچ‌وقت اجرا نمی‌شن.

یه نکته‌ی دیگه که خیلیا گیر می‌کنن: اگه از داخل همون شبکه‌ای که میکروتیک مدیریتش می‌کنه بخواید cloud.netadminhub.com رو باز کنید، احتمالاً خطا می‌گیرید. چون کلاینت داخلی می‌خواد به IP پابلیک روتر وصل بشه، که این معمولاً به یه مشکل NAT Loopback می‌خوره. راه‌حلش Split-Brain DNS هست؛ یعنی یه رکورد استاتیک توی DNS خود میکروتیک می‌سازید که همون دامین‌ها رو مستقیم به IP داخلی روتر resolve کنه:

/ip/dns/static/add name=cloud.netadminhub.com address=192.168.88.1
/ip/dns/static/add name=wiki.netadminhub.com address=192.168.88.1

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

یکپارچگی با Container و RouterOS Apps

از RouterOS 7.22 به بعد، میکروتیک یه منوی جدید به اسم /app معرفی کرده که سعی می‌کنه کار با Container رو ساده‌تر کنه. نکته‌ی جذابش اینه که این لایه کاملاً با Reverse Proxy یکپارچه شده.

اگه یه اپ از طریق همین منوی app بالا بیارید، کافیه پارامتر use-https=yes رو فعال کنید. میکروتیک خودش یه قانون دینامیک توی /ip/reverse-proxy می‌سازه، به گواهی Cloud DDNS وصلش می‌کنه، و یه URL امن و آماده برای اون کانتینر تولید می‌کنه. یعنی دیگه لازم نیست دستی NAT و SSL کانفیگ کنید.

محدودیت‌های Reverse Proxy میکروتیک

این ابزار سبک و کاربردیه، ولی جای Nginx یا HAProxy واقعی رو برای پروژه‌های بزرگ نمی‌گیره. این محدودیت‌ها رو حتماً در نظر بگیرید:

1. فقط IPv4 برای مقصد: پراپرتی ip-address فقط IPv4 قبول می‌کنه. فعلاً امکان پراکسی کردن به سمت بک‌اند روی IPv6 وجود نداره.
2. بار روی CPU: رمزگشایی و رمزنگاری TLS روی خود CPU روتر انجام می‌شه. روی سخت‌افزارهای ضعیف‌تر (مثل hEX یا hAP) زیر بار زیاد ممکنه CPU به 100٪ برسه. چیپ‌های ARM/ARM64 جدیدتر (hAP ax، RB5009، CCR) و خود CHR از HTTP/2 شتاب‌دهی‌شده با سخت‌افزار بهره می‌برن.
3. قابلیت‌های وب محدود: میکروتیک هیچ مدیریت پیشرفته‌ای روی هدرها، لاگ‌گیری حرفه‌ای، فایروال اپلیکیشن وب (WAF)، احراز هویت در سطح پراکسی، یا Load Balancing پیچیده نداره. اگه نیاز به WebSocket، gRPC، Sticky Session یا قوانین پیشرفته‌ی توزیع ترافیک دارید، همچنان باید سراغ یه Nginx یا Caddy واقعی بروید.

Reverse Proxy میکروتیک یا Nginx/Traefik روی Container؟

این سوالی هست که حتماً برایتان پیش می‌آد، پس بریم رو جوابش:

از Reverse Proxy خود میکروتیک استفاده کنید اگه:

• چند سرویس ساده‌ی HTTP/HTTPS دارید که فقط باید پشت یه دامین جدا منتشر بشن
• نمی‌خواید منابع روتر رو با اجرای یه Container اضافه اشغال کنید
• سخت‌افزارتون محدوده و دنبال ساده‌ترین راه‌حل ممکن هستید

سراغ Nginx Proxy Manager، Traefik یا HAProxy (روی Container یا سرور جدا) بروید اگه:

• نیاز به مدیریت پیشرفته‌ی هدر، Rewrite، یا Redirect دارید
• WebSocket یا gRPC پشت پراکسی باید رد بشه
• می‌خواید Load Balancing واقعی بین چند بک‌اند داشته باشید
• یه پنل گرافیکی کامل برای مدیریت قوانین می‌خواید

برای خیلی از سناریوهای خونگی و کسب‌وکارهای کوچیک که چند سرویس داخلی دارن، همین ابزار بومی میکروتیک کاملاً کافیه و حتی از نگه‌داشتن یه Container اضافه روی منابع محدود روتر بهتره.

عیب‌یابی (Troubleshooting)

اگه کانفیگتون کار نکرد، این مراحل رو یکی‌یکی چک کنید:

۱. وضعیت سرویس رو ببینید:

/ip/service/print where name=reverse-proxy

۲. از بیرون تست کنید:

curl -vk https://cloud.netadminhub.com

۳. زنجیره‌ی گواهی رو چک کنید:

openssl s_client -connect cloud.netadminhub.com:443 -servername cloud.netadminhub.com

۴. دسترسی به بک‌اند رو تست کنید:

/ping 192.168.88.10

اگه ترافیک به سرور می‌رسه ولی جواب برنمی‌گرده، معمولاً مشکل از همون فایروال (Input Chain به‌جای forward) یا نبود قانون NAT برگشتیه؛ پس اول این دوتا رو دوباره چک کنید.

Reverse Proxy میکروتیک یه ابزار سبک ولی فوق‌العاده کاربردیه که از RouterOS 7.22 به این بعد، مشکل قدیمی «یه IP، چند سرویس» رو بدون نیاز به نصب هیچ Container یا سرور جدا حل می‌کنه. برای کاربردهای خونگی و حتی خیلی از سناریوهای کسب‌وکار کوچیک، دقیقاً همون چیزیه که لازم دارید.

برای یادگیری اصولی میکروتیک دوره‌های آموزش میکروتیک من رو ببینید.