MikroTik ile Site Engelleme: HTTPS Çağında Gerçekten Çalışan Yöntemler

Özet: HTTPS çağında MikroTik ile site engellemenin gerçekçi üç yolu var: DNS static kayıtları (DNS zorlamasıyla birlikte), TLS-host firewall kuralı ve address-list ile IP engelleme. Layer7 artık çözüm değil; şifreli trafiği göremiyor ve CPU yakıyor. Bu yazıda üç yöntemin kurulumu, sınırları ve DoH/VPN kaçaklarının dürüst gerçeği var.

---

HTTPS Çağında Site Engelleme Neden Zorlaştı?

Kısa cevap: trafik şifreli, router URL’yi göremiyor. HTTP döneminde router her isteğin tam adresini okuyabiliyordu; bugün web’in neredeyse tamamı HTTPS ve router’ın görebildiği yalnız iki şey kaldı: istemcinin DNS sorgusu ve TLS el sıkışmasındaki SNI alanı (sunucu adı). Gerçekten çalışan her engelleme yöntemi bu iki görünür noktadan birine tutunur.

Eski usül “content” eşleştirici, web proxy URL filtresi ve Layer7 regex’leri şifreli pakette desen bulamaz. Sahada en sık gördüğüm hata, HTTP dönemine ait bir tarifin HTTPS trafiğine uygulanıp “MikroTik engellemiyor” sonucuna varılması.

---

Hangi Yöntem Hangi Senaryoda Çalışır?

Dört yöntemin dürüst karşılaştırması şöyle. Kısa özet: DNS static en ucuz ve en kapsamlı, TLS-host en isabetli, address-list IP bazlı işler için, Layer7 ise hiçbiri için.

Yöntem	Nasıl çalışır	Güçlü yönü	Zayıf yönü	CPU maliyeti
DNS static + zorlaması	Alan adına NXDOMAIN döner	Kurulumu kolay, tüm protokolleri kapsar	DoH ve sabit IP ile aşılır	Çok düşük
TLS-host firewall	SNI’daki sunucu adını eşler	DNS’ten bağımsız, isabetli	Yalnız TLS trafiği; ECH yaygınlaşırsa kör kalır	Düşük
Address-list	Çözümlenen IP’leri düşürür	Protokol bağımsız, hızlı eşleşme	CDN’lerde IP havuzu değişken	Çok düşük
Layer7 regex	İlk 10 paket/2KB’da desen arar	Yok (bu senaryoda)	Şifreli içeriği göremez, kaynak yer	Çok yüksek

En sağlam sonuç tek yöntemle değil, DNS static + TLS-host kombinasyonuyla gelir: biri sorguyu keser, diğeri DNS’i aşanı yakalar.

---

Yöntem 1: DNS Static ile Engelleme ve DNS Zorlaması

Mantık basit: istemciler DNS’i router’dan sorar, router engelli alan adına “böyle bir site yok” (NXDOMAIN) cevabı verir. Tek başına yetmez; kullanıcı cihazına 8.8.8.8 yazarsa devre dışı kalır. Bu yüzden ikinci parça, DNS zorlaması, olmazsa olmaz.

Önce router’ı DNS sunucusu yapın ve engel kaydını girin:

/ip dns
# Router istemcilere DNS servisi versin
set allow-remote-requests=yes servers=1.1.1.1,9.9.9.9

/ip dns static
# Alan adi + tum alt alan adlari icin "site yok" cevabi
add name=ornek-site.com type=NXDOMAIN match-subdomain=yes comment="Engel: ornek-site"

match-subdomain=yes RouterOS 7.6 ile geldi; www, cdn, m gibi tüm alt alan adlarını tek kayıtla kapsar. v6’da bu seçenek yok, aynı işi regexp kayıtlarıyla yapmak gerekiyordu. NXDOMAIN tipi A 0.0.0.0 döndürmekten daha temizdir: tarayıcı beklemeden hata verir.

Şimdi zorlama. LAN’dan dışarıya giden her DNS sorgusunu router’a çevirin:

/ip firewall nat
# LAN'dan cikan tum 53 portu sorgulari router'a doner
add chain=dstnat protocol=udp dst-port=53 in-interface-list=LAN \
    action=redirect to-ports=53 comment="DNS zorlamasi: UDP"
add chain=dstnat protocol=tcp dst-port=53 in-interface-list=LAN \
    action=redirect to-ports=53 comment="DNS zorlamasi: TCP"

Kritik uyarı: allow-remote-requests=yes açtıysanız WAN’dan 53 portunu firewall’da kapatmak zorundasınız; yoksa router’ınız internete açık resolver olur ve amplifikasyon saldırılarında araç haline gelir. Input chain düzeni için firewall kural seti yazısına bakın.

RouterOS 7.15 ile gelen Adlist özelliği de aynı altyapıyı kullanır: hazır engel listelerini (reklam, zararlı alan adları) URL’den içe aktarıp binlerce alan adını tek seferde filtreler. Elle liste yönetmek istemeyenler için iyi bir içerik filtreleme başlangıcı.

---

Yöntem 2: TLS-Host ile Firewall Engellemesi

TLS-host, HTTPS bağlantısının el sıkışmasındaki SNI alanını okur ve alan adına göre paketi düşürür. DNS’ten tamamen bağımsız çalışır: kullanıcı hangi DNS’i kullanırsa kullansın, bağlantı kurulurken yakalanır. RouterOS 6.41’den beri var, ROS7’de de aynı sözdizimi geçerli.

/ip firewall filter
# Apex domain (ornek-site.com)
add chain=forward protocol=tcp dst-port=443 tls-host=ornek-site.com \
    action=reject reject-with=tcp-reset comment="Engel: ornek-site TLS"
# Tum alt alan adlari (www, cdn, m...)
add chain=forward protocol=tcp dst-port=443 tls-host=*.ornek-site.com \
    action=reject reject-with=tcp-reset comment="Engel: ornek-site subdomain TLS"

Satır satır: tls-host GLOB deseni kabul eder, ama *.ornek-site.com apex’i (çıplak alan adını) kapsamaz; o yüzden iki kural. reject-with=tcp-reset tarayıcıya anında “bağlantı reddedildi” gösterir; drop kullanırsanız sayfa timeout’a kadar bekler, kullanıcı deneyimi kötüleşir ve destek telefonları artar.

Sınırları da bilin: resmi doküman, TLS el sıkışması birden fazla TCP segmentine bölünürse eşleştiricinin sunucu adını yakalayamayacağını söylüyor. Ayrıca ECH (Encrypted Client Hello) yaygınlaştıkça SNI da şifrelenecek; bu yöntem uzun vadede tek başına yeterli olmayabilir. Bugün için hâlâ en isabetli araç.

---

Yöntem 3: Address-List ile IP Bazlı Engelleme

Address-list, alan adı yerine IP’yi hedefler: listeye giren adreslere forward chain’de kapı kapanır. İki besleme yolu var ve ikincisi CDN’li sitelerde belirgin şekilde daha iyi çalışır.

Birinci yol, FQDN’i doğrudan listeye yazmak. Router adı kendisi çözümler ve dinamik girişler oluşturur:

/ip firewall address-list
# Router bu adi kendisi cozumler, IP'ler dinamik eklenir
add list=engelli-siteler address=ornek-site.com comment="FQDN girisi"

İkinci yol, DNS static kaydının address-list seçeneği: istemci alan adını router üzerinden her çözdüğünde, dönen IP’ler listeye otomatik düşer. İstemcinin gerçekten aldığı IP’yi yakaladığı için CDN’lerin değişken IP havuzunda bile isabetlidir:

/ip dns static
# Cozumlenen her IP dinamik olarak listeye eklenir
add name=ornek-site.com type=FWD forward-to=1.1.1.1 \
    match-subdomain=yes address-list=engelli-siteler comment="IP'leri listeye topla"

/ip firewall filter
# Listedeki IP'lere giden trafik kesilir
add chain=forward dst-address-list=engelli-siteler \
    action=reject reject-with=icmp-network-unreachable comment="Engel: IP listesi"

Dikkat: ikinci yol, istemcilerin DNS’i router’dan sormasına bağlıdır; yani Yöntem 1’deki DNS zorlaması olmadan eksik kalır. Ayrıca büyük CDN’lerde (Cloudflare, Google) IP engellemek istemediğiniz siteleri de kapsayabilir; address-list’i tls-host’un yerine değil, yanına koyun.

---

Layer7 Neden Kötü Bir Fikir?

Layer7 site engelleme için üç nedenle yanlış araç. Bir: eşleştirici bağlantının yalnız ilk 10 paketini veya ilk 2KB’ını inceler, deseni orada bulamazsa vazgeçer. İki: HTTPS içeriği şifrelidir, regex’in arayacağı metin pakette yoktur; resmi doküman YouTube örneğinde bunu açıkça söyler. Üç: her bağlantı için desen taraması bellek ve CPU’yu hızla tüketir; MikroTik dokümanı genel web engelleme için L7 kullanmayı “neredeyse hiç doğru çalışmaz” diyerek reddeder.

Sahada L7 kural listesiyle gelen cihazlarda ilk yaptığım iş bu kuralları sökmek oluyor; çoğu zaman “router yavaş” şikâyetinin kökü de bu. CPU %100 vakalarının teşhisi için ayrı bir yazı var: MikroTik yavaş, CPU %100 teşhisi.

L7’nin meşru kullanımı hâlâ var: şifresiz, çok spesifik ve önceden port/protokol filtresiyle daraltılmış trafikte desen aramak. Site engelleme bu tarife girmiyor.

---

YouTube Engelleme: En Zor Senaryo

YouTube tek kuralla engellenmez çünkü üç ayrı kapıdan geçer: youtube.com alan adları, video içeriğini taşıyan googlevideo.com CDN’i ve QUIC protokolü (UDP 443). tls-host yalnız TCP üzerindeki TLS’e bakar; QUIC açıkken trafik oradan akar ve kurallarınız boşa düşer.

Çalışan reçete üç parça:

/ip firewall filter
# 1) QUIC'i kapat: tarayici TCP+TLS'e geri duser, tls-host gorebilir
add chain=forward protocol=udp dst-port=443 action=drop \
    comment="QUIC engel: TLS fallback"

# 2) YouTube alan adlari
add chain=forward protocol=tcp dst-port=443 tls-host=*.youtube.com \
    action=reject reject-with=tcp-reset comment="Engel: YouTube"
add chain=forward protocol=tcp dst-port=443 tls-host=youtube.com \
    action=reject reject-with=tcp-reset comment="Engel: YouTube apex"
add chain=forward protocol=tcp dst-port=443 tls-host=*.googlevideo.com \
    action=reject reject-with=tcp-reset comment="Engel: YouTube CDN"

Üçüncü parça DNS tarafı: youtube.com, youtu.be ve googlevideo.com için match-subdomain=yes NXDOMAIN kayıtları ekleyin (Yöntem 1). QUIC’i komple kapatmanın yan etkisi pratikte küçüktür; tarayıcılar TCP’ye sessizce geri düşer. Daha cerrahi isterseniz UDP 443 drop’unu yalnız Google IP address-list’ine uygulayabilirsiniz.

Mobil uygulama ve önbellek gerçeği: telefondaki YouTube uygulaması DNS cache’i ve bağlı oturumlar yüzünden engellemeden sonra bir süre çalışmaya devam edebilir. /ip firewall connection tablosundan mevcut bağlantıları temizleyin ve birkaç dakika bekleyip test edin.

---

DoH ve VPN Kaçakları: Dürüst Gerçek

Hiçbir router tabanlı engelleme kararlı bir kullanıcıya karşı yüzde yüz değildir; bunu baştan kabul etmek gerekir. İki büyük kaçak yolu var: DoH (DNS over HTTPS) ve VPN. İkisine karşı da yapılabilecekler var, ama sınırlarını bilerek.

DoH: Tarayıcı DNS sorgusunu 53 portundan değil, HTTPS içinde dns.google veya cloudflare-dns.com’a gönderir; DNS zorlamanız hiç devreye girmez. Karşı hamle, bilinen DoH sunucularını TLS-host ile kesmek:

/ip firewall filter
add chain=forward protocol=tcp dst-port=443 tls-host=dns.google \
    action=reject reject-with=tcp-reset comment="DoH engel: Google"
add chain=forward protocol=tcp dst-port=443 tls-host=*.cloudflare-dns.com \
    action=reject reject-with=tcp-reset comment="DoH engel: Cloudflare"

/ip dns static
# Firefox canary domain: NXDOMAIN gorunce varsayilan DoH'u kapatir
add name=use-application-dns.net type=NXDOMAIN comment="Firefox DoH kapat"

Firefox, use-application-dns.net için NXDOMAIN alırsa varsayılan DoH’u kendiliğinden devre dışı bırakır; bu tek satır çok kaçağı sessizce kapatır. Yine de yüzlerce genel DoH sunucusu var, liste hep eksik kalır.

VPN: WireGuard istediği porttan çalışır, trafiği herhangi bir UDP akışından ayırt edilemez. Bilinen ticari VPN sunucu IP’lerini listelemek kedi fare oyunudur ve kaybedersiniz. Benim önerim çabayı teknikte değil kapsamda harcamak: misafir ve personel ağlarını VLAN ile izole edin, engellemeyi yazılı kullanım politikasıyla destekleyin, teknik engeli “kararlı saldırgana duvar” değil “sürtünme” olarak konumlandırın. Okul, yurt, KOBİ gibi ortamlarda kullanıcıların büyük çoğunluğu ilk sürtünmede vazgeçer; kalan azınlık teknik değil idari bir konudur.

---

Karar Kutusu: Hangi Senaryoda Hangisi?

Hızlı seçim rehberi:

• Ev / küçük ofis, birkaç site: DNS static (NXDOMAIN + match-subdomain) + DNS zorlaması. On dakikalık iş.
• KOBİ, ciddi içerik filtreleme: DNS static + TLS-host birlikte; Adlist ile hazır listeler; WAN’dan 53 kapalı.
• YouTube / sosyal medya engelleme: TLS-host + QUIC drop + DNS kaydı üçlüsü; tek yöntem tutmaz.
• Belirli sunuculara erişim kesme (IP belli): Address-list, en hızlı ve en ucuz yol.
• Misafir ağı: Engelleme + VLAN izolasyonu birlikte; misafir trafiği iç ağa hiç değmesin.
• Her senaryoda: Layer7’den uzak durun; DoH karşı hamlelerini ekleyin; kuralları test edip connection tablosunu temizleyin.

Engelleme kuralları firewall’ınızın geneliyle uyumlu olmalı: sıralama, established/related istisnaları ve yönetim erişimi düzgün kurulmamışsa engelleme kuralı ya çalışmaz ya da yanlış şeyi keser. Temel kural seti için brute force koruması ve production-ready firewall yazısı iyi bir başlangıç.

Ağınızda içerik filtreleme, erişim politikası veya firewall düzeni kurmak istiyor ama nereden başlayacağınızdan emin değilseniz, MikroTik danışmanlık hizmetime göz atabilirsiniz; mevcut konfigürasyonu birlikte gözden geçirip senaryonuza uygun katmanlı bir yapı kurarız.

---

Referanslar: MikroTik Docs: Layer7, MikroTik Docs: Common Firewall Matchers and Actions, MikroTik Docs: DNS, MikroTik Docs: Address-lists