مقدمه

در دنیای دیجیتال امروز، مدیران شبکه اغلب نیاز دارند دسترسی به سایت‌ها یا دامنه‌های خاص را کنترل و محدود کنند. این کار ممکن است به دلایل مختلفی از جمله افزایش بهره‌وری، امنیت، مدیریت پهنای باند و رعایت سیاست‌های سازمانی انجام شود. MikroTik RouterOS ابزارهای قدرتمند و انعطاف‌پذیر فایروال ارائه می‌دهد که به مدیران امکان پیاده‌سازی راهکارهای جامع بلاک کردن سایت را می‌دهد.

چرا سایت‌ها را بلاک کنیم؟

  • افزایش بهره‌وری کارمندان
  • محافظت در برابر سایت‌های مخرب
  • مدیریت مصرف پهنای باند
  • رعایت سیاست‌های سازمانی

Table of Contents

1. Website Blocking Approaches in MikroTik

Modern RouterOS policies should use a method that matches the traffic actually visible to the router. For HTTPS, the useful hostname signal is TLS SNI via tls-host; DNS policy is effective only while clients use the router's DNS; IP address lists contain IP addresses and prefixes, not wildcard domain names. Layer7 is kept here only to explain why it should not be used as a general website-blocking method.

Important scope

No router-only rule can guarantee URL filtering for every modern application. QUIC uses UDP/443 and does not use the TCP TLS flow matched by tls-host. Encrypted DNS (DoH/DoT), VPNs, proxies, changing CDN addresses, and encrypted client hello can also bypass a simple policy.

2. پیاده‌سازی گام‌به‌گام

حالا بیایید به پیاده‌سازی عملی هر روش بپردازیم. ما دستورالعمل‌های گام‌به‌گام دقیق با دستورات واقعی MikroTik RouterOS ارائه می‌دهیم که می‌توانید مستقیماً کپی و استفاده کنید.

پیش‌نیازها

  • دسترسی به MikroTik RouterOS (WinBox یا SSH)
  • دسترسی مدیر روی روتر
  • دانش پایه MikroTik RouterOS
  • لیست سایت‌ها/دامنه‌های مورد نظر برای بلاک
01

Method 1: TLS SNI filtering

For HTTPS over TCP, match the hostname sent in the TLS SNI field with tls-host.

MikroTik RouterOS
/ip firewall filter add chain=forward protocol=tcp dst-port=443 \
  tls-host="*.example.com" action=drop \
  comment="Block example.com by TLS SNI"

Limits

  • tls-host matches the HTTPS SNI hostname and accepts glob wildcards.
  • It does not cover QUIC traffic on UDP/443, and it cannot match every fragmented or encrypted handshake.
02

Method 2: DNS policy

Use the router's DNS service to return NXDOMAIN for a domain and its subdomains.

MikroTik RouterOS
/ip dns set allow-remote-requests=yes
/ip dns static add name=example.com match-subdomain=yes \
  type=NXDOMAIN comment="Policy block"

Limits

  • Clients must use the router as their DNS resolver for this policy to take effect.
  • DoH, DoT, VPNs, and an external resolver can bypass a DNS-only policy; apply any DNS redirect or outbound restriction only to the intended client scope.
03

Method 3: IP address lists

Use an address list only when you intentionally want to block verified IP addresses or prefixes.

MikroTik RouterOS
/ip firewall address-list add list=blocked-ip \
  address=<verified-ip-or-prefix> comment="Review ownership first"
/ip firewall filter add chain=forward dst-address-list=blocked-ip \
  action=drop

Limits

  • Address lists contain IP addresses and prefixes; address=*.example.com is not a domain wildcard rule.
  • CDNs and shared hosting can change or share IPs, so verify ownership and review the list regularly.
04

Method 4: Layer7 — do not use for general web blocking

Layer7 pattern matching is resource-intensive and cannot inspect encrypted HTTPS payloads.

MikroTik RouterOS
# Do not add a generic Layer7 rule for website blocking.
# Prefer tls-host for visible TCP TLS SNI or a scoped DNS policy.

Why

  • RouterOS documents Layer7 as resource-intensive and advises against it for generic web-page blocking.
  • Keep it only for narrowly scoped, non-web traffic patterns that you have tested on the target hardware.

3. Management and policy limits

Operate safely

  • Scope rules to the intended users or VLANs before applying them network-wide.
  • Log and test a new rule with a small pilot group before enforcing it broadly.
  • Review DNS, address-list, and firewall entries whenever a provider changes domains, CDN addresses, or client applications.

4. Troubleshooting

A site is still reachable

  • Confirm that the traffic matches the method: TCP TLS for tls-host, router DNS for DNS policy, or the intended IP for an address list.
  • Place the rule before a broader accept rule that would otherwise match the traffic, then re-test with a new connection.

QUIC or encrypted DNS bypasses the policy

  • Identify whether the client uses UDP/443, DoH, DoT, VPN, or a proxy before changing firewall rules.
  • Apply a scoped policy appropriate to the organization; blindly blocking common VPN ports is neither complete nor a reliable control.

5. Security tips

  • Do not treat website blocking as a complete security boundary; maintain endpoint protection, access control, logging, and user education.
  • Keep management access to RouterOS restricted and export a configuration backup before changing firewall or DNS policy.

If you enable remote DNS requests on the router, permit DNS service only from trusted client networks; never leave it reachable from an untrusted WAN.

6. Frequently asked questions

Does tls-host block every HTTPS visit?

No. It relies on visible TCP TLS SNI, so it does not cover QUIC/UDP traffic and may not match every fragmented or encrypted handshake.

Can an address list contain *.example.com?

No. Firewall address lists are for IP addresses and prefixes. Use DNS policy or tls-host for hostname-oriented controls, with their stated limits.

Should Layer7 be used to block modern websites?

No. RouterOS describes it as resource-intensive and advises against using it for generic web-page blocking; encrypted HTTPS payloads are not suitable for this matcher.

Conclusion

For a current RouterOS deployment, prefer a narrowly scoped tls-host rule for visible TCP TLS SNI or a DNS policy for clients that use the router's resolver. Treat IP address lists as IP-only controls and avoid Layer7 for general web filtering. Test each policy against QUIC, encrypted DNS, VPN, and CDN behavior before relying on it.

Official RouterOS firewall matcher documentation

Official RouterOS DNS documentation

Share