“Cihaza SSH ile gir, komutu yaz, çık” döngüsü; 5 router olduğunda eğlencelidir, 50 router olduğunda işkenceye dönüşür. MikroTik ekosisteminde sahada karşılaştığım çoklu şubeli işletmelerin neredeyse tamamında ortak bir hikaye var: ilk üç şubede her şey manuel yapılır, dördüncü şubede yapılandırmalar farklılaşmaya başlar, beşincide ise tutarsızlık üretim arızasına dönüşür. Bu noktada konu artık RouterOS bilgisi değil; operasyonel olgunluk meselesidir. Yani DevOps.

Bu pillar rehber; MikroTik kullanan sistem yöneticilerini, SRE’leri ve DevOps mühendislerini “manuel yapılandırmadan” “kod ile yönetilen altyapıya” geçirmek için yazıldı. Konteyner üzerinde mesh VPN, CHR’nin VMware/Proxmox/AWS dağıtımı, scripting ile şube otomasyonu, sıfır güven mimarisi ve üretim ortamı için zorunlu firewall kuralları gibi başlıkları bir çerçeve içinde bütünleştiriyor.

Bu Rehber Kim İçin?

Bu rehber dört profili hedefliyor. SRE ve DevOps mühendisleri; bulut, container ve IaC dünyasından gelip MikroTik dünyasında kendini “şifresi farklı” hisseden okuyucular. NetDevOps uygulayıcıları; Ansible, Terraform, Git ile ağ yönetimini otomatize etmeye çalışan ağ mühendisleri. Çoklu şube IT yöneticileri; 5 ile 200 şube arası ağa sahip işletmelerin merkez IT sorumluları. Bilgi güvenliği uzmanları; zero trust, mikro segmentasyon ve adaptive defense konseptlerini MikroTik üzerinde uygulamak isteyenler.

Eğer henüz tek bir hAP cihazı ile evdeki ağı kuruyorsanız, bu rehber size çok ileri seviye gelebilir. 10+ MikroTik cihazını yöneten, scripting’e aşina ve otomasyon kültürü olan ekipler için tasarlandı.

DevOps Zihniyeti Neden MikroTik Dünyasında Önemli?

Geleneksel ağ yönetimi; cihaz başına manuel yapılandırma, değişiklik kayıtlarının e-postada saklanması, yedeğin “lazım olunca alırız” yaklaşımıyla ele alınması üzerine kuruludur. DevOps zihniyeti ise bu paradigmayı kökten değiştirir: yapılandırma kodu Git’te saklanır, değişiklik pull request ile yapılır, otomasyon test ortamında doğrulanır ve üretime push edilir. MikroTik tarafında bu felsefeyi uygulamak için ekosistemin sunduğu kanalları (REST API, NETCONF benzeri API, scripting, container’lar) anlamak gerekir.

Üç kritik faydayı sıralayalım. Tekrar edilebilirlik: yeni bir şube açtığınızda dakikalar içinde standart yapılandırma uygulanır. Denetlenebilirlik: kim, ne zaman, hangi değişikliği yaptı belgelidir (Git history). Geri alınabilirlik: kötü bir değişikliği “git revert” ile saniyeler içinde geri alabilirsiniz. Bu üç fayda, üretim ortamında yaşanan arızaların ortalama çözüm süresini (MTTR) dramatik biçimde azaltır.

Container’lar ve ZeroTier ile Modern VPN Mesh

RouterOS 7.4+ ile birlikte gelen container desteği, MikroTik’i sadece bir yönlendiriciden çok daha fazlasına dönüştürdü. Artık cihazınız üzerinde Docker benzeri konteynerler çalıştırarak; ZeroTier, WireGuard mesh, Pi-hole, MQTT broker, hatta küçük bir izleme ajanı barındırabilirsiniz. ZeroTier konteyneri ile çok şubeli bir mesh VPN kurulumunu konfigürasyon dosyaları, NAT-traversal davranışı ve performans karşılaştırması ile birlikte ele aldığımız ZeroTier ile MikroTik VPN mesh: Container üzerinden multi-site yazımız, klasik IPsec’in alternatiflerini arayan ekipler için iyi bir başlangıç noktası olacaktır.

ZeroTier’in en güçlü yanı, NAT arkasında kalan bütün şubelerin SD-WAN benzeri bir overlay üzerinden birbirini görmesi ve merkezi bir kontrolcü ile politika yönetimine olanak vermesidir. Klasik IPsec mesh yapısının O(n²) tünel patlamasını O(1) overlay’e indirir. Ölçeklenebilirlik açısından 50+ şubeli işletmelerde belirgin kazanç sağlar.

Container Çalıştırmak İçin Örnek RouterOS Komutları

/interface veth add address=172.20.0.2/24 gateway=172.20.0.1 name=veth-zt
/interface bridge add name=br-cont
/interface bridge port add bridge=br-cont interface=veth-zt
/ip address add address=172.20.0.1/24 interface=br-cont
/container envs add list=zt-env name=ZT_NETWORK_ID value=YOUR_NETWORK_ID
/container mounts add name=zt-data src=/zerotier-one dst=/var/lib/zerotier-one
/container add remote-image=zyclonite/zerotier:latest interface=veth-zt 
    root-dir=usb1/zt envlist=zt-env mounts=zt-data
/container start [find tag~"zerotier"]

Bu komut bloğunun kritik kısmı; envlist, mounts ve interface kombinasyonudur. ZeroTier konteyneri çalıştırıldığında bu üç bileşen olmadan ya başlamaz ya da merkezi kontrolcüden ağ bilgisini alamaz.

Veri merkezi içinde sunucular ve otomasyon altyapısı görünümü

Alpine Linux ile DIY Router: Alternatif mi, Tamamlayıcı mı?

MikroTik’i seven her DevOps mühendisinin aklında bir noktada şu soru belirir: “Alpine + nftables ile aynı işi yapabilir miyim?” Cevap evettir; ama bağlam önemlidir. Alpine, açık kaynak esnekliği ve dilediğiniz aracı kurma özgürlüğü sunarken, MikroTik denenmiş donanım ve tek elden destek sağlar. Bu iki dünyanın karşılaştırmasını performans testleri, yapılandırma derinliği ve operasyonel maliyet açısından incelediğimiz Alpine Linux ile DIY router: MikroTik alternatifi mi, tamamlayıcısı mı? başlıklı yazımız, “hangisi daha iyi” tartışmasının ötesine geçerek “hangisi hangi rol için doğru” çerçevesini sunuyor.

Sahadaki en sağlıklı yaklaşım, ikisinin de doğru rolde kullanıldığı hibrit mimaridir. Şube router’ı MikroTik, merkezi VPN konsantratörü Alpine + WireGuard, izleme/log toplama sunucusu Alpine + Prometheus + Loki olabilir. Her dünyanın güçlü yanı kullanılır.

MikroTik CHR: Bulutta ve Sanallaştırmada RouterOS

Cloud Hosted Router (CHR), RouterOS’un x86 sanal disk imajıdır. VMware, Proxmox, KVM, Hyper-V, AWS, Hetzner, DigitalOcean gibi platformlarda dakikalar içinde çalıştırılabilir. CHR sayesinde merkezi VPN konsantratörü, bulut güvenlik duvarı, hibrit ağ köprüsü gibi senaryolar fiziksel donanım almadan ölçeklenebilir. Farklı sanallaştırma platformlarında CHR dağıtımının adım adım nasıl yapıldığını, lisans modellerini (Free / P1 / P10 / P-Unlimited) ve performans karşılaştırmasını ele aldığımız MikroTik CHR: VMware, Proxmox, AWS, Hetzner üzerinde dağıtım yazımız bu konuda kapsamlı bir başlangıç sunuyor.

CHR’nin DevOps perspektifinden büyük avantajı; cloud-init benzeri başlangıç scriptleri ile sıfırdan tamamen yapılandırılmış bir router’a 60 saniyede ulaşılabilmesidir. Terraform ile AWS’de bir CHR örneği oluşturup, user-data alanına RouterOS başlangıç scripti gömerek tam otomatik provisioning yapabilirsiniz.

Cloud-Init Benzeri RouterOS Başlangıç Scripti Örneği

:global SITE_NAME "istanbul-merkez"
:global PRIVATE_KEY "..."
:global PEER_PUBLIC "..."
:global PEER_ENDPOINT "vpn.example.com:51820"

/interface wireguard add name=wg0 private-key=$PRIVATE_KEY listen-port=51820
/interface wireguard peers add interface=wg0 public-key=$PEER_PUBLIC 
    endpoint-address=[:pick $PEER_ENDPOINT 0 [:find $PEER_ENDPOINT ":"]] 
    endpoint-port=[:pick $PEER_ENDPOINT ([:find $PEER_ENDPOINT ":"]+1) [:len $PEER_ENDPOINT]] 
    allowed-address=10.0.0.0/8
/ip address add address=10.255.0.10/24 interface=wg0
/system identity set name=$SITE_NAME
:log info ("Bootstrap completed for site " . $SITE_NAME)

Bu script, yeni bir CHR örneği başlatıldığında otomatik olarak çalıştırılır; site adı, WireGuard anahtarları ve VPN endpoint’i değişken olarak verilir. Yüzlerce şube için aynı kalıp ile tutarlı yapılandırma garanti edilir.

Çoklu Şube Site-to-Site VPN Mesh ve Scripting

Çoklu şubeli işletmelerin en zorlandığı konu; şubeler arası VPN’in tutarlı, yönetilebilir ve izlenebilir biçimde kurulmasıdır. Klasik yaklaşımda her şube ile merkez arasında ayrı IPsec tüneli kurulur (hub-and-spoke). Bu, ölçek büyüdükçe yönetilemez hale gelir. Çoklu şube mesh VPN’in farklı topolojilerini (hub-spoke, full mesh, partial mesh), karşılaştırmayı ve hangi senaryoda hangisinin tercih edilmesi gerektiğini, ayrıca otomatik kurulum scriptleri ile birlikte ele aldığımız Çoklu şubeli MikroTik site-to-site VPN mesh: Otomasyon ve scripting yazımız, DevOps tarafında elinizin altında olması gereken bir saha rehberi sayılabilir.

Önemli not: 10+ şube olduğunda manuel IPsec konfigürasyonu sürdürülemez. Bu noktada Ansible playbook’ları ile RouterOS API üzerinden otomatik tünel oluşturma, anahtar dağıtımı ve sağlık kontrolü yapan bir CI/CD hattı kurmak zorunludur. RouterOS REST API (7.x ile geldi) bu otomasyonu kolaylaştırır.

Ansible ile MikroTik Yapılandırma Örneği

- name: Configure WireGuard peers for branch sites
  hosts: branch_routers
  gather_facts: no
  connection: ansible.netcommon.network_cli
  vars:
    ansible_network_os: community.routeros.routeros
  tasks:
    - name: Add WireGuard interface
      community.routeros.command:
        commands:
          - "/interface wireguard add name=wg-mesh listen-port=13231 private-key={{ branch_private_key }}"

    - name: Add peers from inventory
      community.routeros.command:
        commands:
          - "/interface wireguard peers add interface=wg-mesh public-key={{ item.pubkey }} endpoint-address={{ item.endpoint }} endpoint-port=13231 allowed-address={{ item.subnet }}"
      loop: "{{ mesh_peers }}"

Bu playbook ile 50 şubeli bir işletmenin tüm WireGuard mesh konfigürasyonu, envanter (inventory) dosyasında tanımlı verilerden saniyeler içinde tüm cihazlara push edilir. Bir şube eklendiğinde tek bir CI/CD pipeline tetiklemesi yeterlidir.

Zero Trust Mimarisi ve Adaptive Defense

2026 perspektifinde “perimetre güvenliği” kavramı miadını çoktan doldurdu. Zero trust yaklaşımı; her isteği, her cihazı, her oturumu açıkça doğrulamayı ve mümkün olan en az yetkiyi vermeyi öngörür. MikroTik’in firewall altyapısı (raw + filter + mangle + connection tracker + address list) bu yaklaşımı uygulamak için gerekli alt yapıyı sunar; ama bu mimarinin doğru kurulması çok katmanlı düşünmeyi gerektirir. Zero trust prensiplerinin MikroTik üzerinde nasıl somutlaştırıldığını, ayrıca dinamik tehdit listelerinin firewall’a nasıl bağlandığını adım adım gösteren MikroTik firewall stratejisi: Zero trust mimarisinden adaptive defense’e yazımız, kurumsal güvenlik perspektifiyle MikroTik’i ele alıyor.

Adaptive defense, firewall’ın statik bir kural setinden çıkıp; saldırı belirtilerine, davranış anomalilerine ve dış tehdit beslemelerine göre kendini dinamik güncellemesi anlamına gelir. MikroTik’te bu, Fetch ile threat intelligence beslemelerinin indirilmesi, address list olarak firewall’a yüklenmesi ve scheduler ile saatlik yenilenmesi yoluyla gerçekleştirilir.

Üretim Ortamı İçin Zorunlu 12 Firewall Kuralı

Çoğu MikroTik kurulumu, varsayılan firewall ile başlar ve “çalışıyor” diye olduğu gibi bırakılır. Oysa üretim ortamına çıkmadan önce mutlaka olması gereken 12 temel firewall kuralı vardır: invalid bağlantıların düşürülmesi, ICMP yanıt limiti, port scan tespiti, SSH brute-force koruması, address list ile dinamik blokaj, fasttrack istisnaları, IPv6 RA filtrelemesi, Bogon trafiği reddi, syn-flood koruması, recursive DNS abuse engeli, ICMP redirect engeli, ve son olarak default-drop politikası. Bu 12 kuralın açıklamalarını, RouterOS komutlarını ve scheduler ile otomatik bakım scriptlerini paylaştığımız MikroTik firewall: Üretim ortamında mutlaka olması gereken 12 kural ve otomasyonu yazımız, hem yeni kurulumlar hem de mevcut altyapıların güvenlik denetimi için pratik bir kontrol listesi sunuyor.

Bu kuralları sadece eklemek yetmez; her ay log analizi yapıp hangi kuralın kaç defa eşleştiğini görmek ve gerektiğinde optimize etmek de DevOps’un bir parçasıdır. Firewall counter’larını Prometheus exporter ile alıp Grafana dashboard’unda izlemek, üretim ortamı için kanonik kabul edilen pratiktir.

Gözlemlenebilirlik (Observability): Loglar, Metrikler ve İzler

“Çalışıyor” demek ile “ne kadar iyi çalıştığını ölçebiliyor” demek arasında uçurum vardır. MikroTik’i DevOps disiplini ile yönetiyorsanız, üç pillar’ı (loglar, metrikler, izler) eksiksiz toplamanız gerekir. Loglar için syslog → Loki + Grafana; metrikler için SNMP veya REST API → Prometheus + Grafana; izler için NetFlow/IPFIX → ntopng veya Elastic. Bu üç akış birleştiğinde, her sorunun kök nedenine 5 dakika içinde ulaşabilirsiniz.

Mikrotik için açık kaynak ekosisteminde olgun bir prometheus exporter (mikrotik-exporter) bulunur. Tek bir docker container ile dakikalar içinde devreye alınır ve tüm router’larınızdan CPU, bellek, arayüz, DHCP lease, firewall connection, wireless istemci ve sıcaklık verilerini toplar.

CI/CD ve GitOps ile RouterOS Yönetimi

GitOps prensibi; altyapının “kaynak kodu” Git’te tutulur, değişiklik pull request ile yapılır, otomasyon değişikliği test ortamında doğrular ve onaylanırsa üretime push eder. MikroTik için GitOps tipik olarak şu boru hattı ile uygulanır: yapılandırma şablonları (Jinja2) Git repo’da, envanter (host, IP, anahtar) yine Git’te, GitLab CI/GitHub Actions ile pipeline çalıştırılır, Ansible playbook RouterOS’a uygular. Bu disiplin sayesinde “kim, ne zaman, ne değiştirdi” sorusunun cevabı her zaman vardır.

Sıkça Sorulan Sorular

RouterOS scripting mi yoksa Ansible mı kullanmalıyım?

Tek cihazda çalışacak küçük otomasyonlar için RouterOS scripting yeterlidir; ama 5+ cihazı yönetiyorsanız Ansible’a geçmelisiniz. Ansible, envanter yönetimi, idempotency ve versiyonlamayı tek başına çözer. RouterOS scripting’i Ansible playbook’ları içinden tetiklemek de mümkündür; yani ikisi rakip değil, tamamlayıcıdır.

CHR’nin Free sürümü üretimde kullanılabilir mi?

CHR Free sürümü, arayüz başına 1 Mbit/sn ile sınırlıdır; bu nedenle üretimde sadece test, lab ve düşük trafikli senaryolarda anlamlıdır. Gerçek üretim için P1 (1 Gbit/sn, 45 USD) veya P10 (10 Gbit/sn, 95 USD) lisansı önerilir. P-Unlimited (250 USD) sınırsızdır ve büyük operatörler için tasarlanmıştır.

WireGuard mı IPsec mi tercih etmeliyim?

2026 itibarıyla WireGuard, IPsec’e kıyasla çok daha basit yapılandırma, daha düşük gecikme ve modern kriptografi sunuyor. RouterOS 7.x WireGuard desteği olgun. Yeni kurulan tüm site-to-site VPN’leri WireGuard üzerine inşa etmenizi öneririm. Mevcut IPsec yapısını dönüştürmek mecburi değil; ama yeni şubeler kesinlikle WireGuard ile bağlanmalı.

RouterOS 6 ve 7 farkı operasyonel açıdan nedir?

RouterOS 7, container desteği, WireGuard, REST API, daha modern Wi-Fi yığını (wifiwave2) gibi DevOps perspektifinden kritik özellikleri getirdi. Yeni cihazlarda her zaman 7.x kullanmanızı öneririm. Eski cihazları (RB951, RB2011 gibi) yükseltirken donanım uyumluluğuna dikkat etmek gerekir; tüm cihazlar 7.x’i destekleyemiyor.

Üretim ortamında bir yapılandırma değişikliği nasıl güvenle uygulanır?

Üç katmanlı güvenlik önerilir. Birinci katman: safe-mode ile değişiklik yapın (bağlantı koparsa otomatik geri alır). İkinci katman: scheduler ile 5 dakika sonra otomatik system reset-configuration komutu tanımlayın, bağlantı tekrar kurulduysa scheduler’ı silin. Üçüncü katman: tüm değişiklikleri Ansible playbook olarak yazın, önce staging ortamında test edin, sonra üretime push edin.

Sonuç ve İlgili Rehberler

MikroTik’i DevOps disiplini ile yönetmek; başlangıçta yük gibi görünür, ama 6 ay içinde geri dönüşü ekibinizin uykusuzluğunu çözer. Yapılandırma artık tek bir kişinin kafasında değil, Git’te yaşar. Yeni bir mühendis ekibe katıldığında “şu router’a şu kuralı sen mi yazdın” diye sormak yerine, Git history’sine bakar. Bir şube açıldığında 3 saat yerine 5 dakika içinde devreye girer. Bir saldırıdan etkilendiğinizde, geri dönüşü saniyeler içinde yaparsınız.

Üç temel pratik öneriyle bitirelim: Git’i ağ yapılandırmasının tek doğru kaynağı (single source of truth) yapın. Her şubeyi cloud-init benzeri bir bootstrap scripti ile devreye alın. Observability’yi (loglar/metrikler/izler) operasyonun temel bileşeni olarak ele alın. Bu üç ilke, sahada gördüğüm en olgun MikroTik operasyonlarının ortak DNA’sıdır.

İşletme ölçeğinde KOBİ tasarımına ve karar matrislerine bakmak isterseniz, diğer pillar rehberimizi inceleyebilirsiniz: KOBİ ve Saha Çözümleri Rehberi, 5651 uyumu, sektör bazlı ağ mimarisi, 5 yıllık TCO hesabı ve doğru danışman seçimi gibi konuları işletme perspektifinden ele alıyor. İki rehber birlikte okunduğunda; “mimari karar” ve “operasyonel uygulama” arasındaki bütünlüğü görmüş olursunuz.