Yıllardır ağ altyapısı dünyasında bir gerçek değişmedi: yönlendirici (router) deyince akla ilk gelen markalar arasında MikroTik, Cisco ve Juniper yer alıyor. Ancak DevOps kültürünün, container teknolojilerinin ve Infrastructure-as-Code yaklaşımının yükselişiyle birlikte yeni bir paradigma ortaya çıktı: kendi router’ını tamamen açık kaynak Linux dağıtımı üzerine inşa etmek. Bu yazıda, minimal ayak iziyle ünlü Alpine Linux’u bir router olarak nasıl kullanabileceğinizi, MikroTik ile karşılaştırıldığında nerede üstün nerede zayıf olduğunu ve en önemlisi hibrit bir mimaride bu ikisini birlikte nasıl konuşlandıracağınızı paylaşacağım.

Bir Linux sistem mühendisi olarak, son sekiz yılda hem MikroTik RouterOS hem de tamamen Linux tabanlı router’lar (VyOS, OpenWrt, pfSense, Alpine ve hatta plain Debian) konuşlandırdım. Vereceğim cevap kategoriktir: MikroTik bir router’ın ne olması gerektiği konusunda olgun ve harika bir üründür; ancak Alpine Linux bir router’ın nasıl programlanabileceği konusunda eşi benzeri olmayan bir oyun alanıdır. İkisi rakip değil, tamamlayıcıdır.

Alpine Linux Mimarisi: Neden Router Görevi İçin Doğuştan Uygun?

Alpine Linux’u diğer Linux dağıtımlarından ayıran üç temel özellik vardır ve bu üçü de bir router için âdeta el kitabından çıkmış gibidir:

• musl libc: Glibc yerine kullanılan, daha küçük ve daha güvenli C kütüphanesi. Bellek tüketimi düşük, exploit yüzeyi dar.
• BusyBox: Tek bir binary içinde Unix temel araçlarını barındırır. Coreutils + util-linux + procps yerine 1 MB’lık BusyBox iş görür.
• OpenRC: systemd’ye karşı sade, shell tabanlı init sistemi. Açılış 3 saniyenin altında.

Sonuç: alpine-virt ISO sadece 60 MB civarında, kurulu sistem RAM’de 30-50 MB tüketiyor. Bir router için tam olarak istediğimiz şey: minimum saldırı yüzeyi, deterministik davranış ve maximum öngörülebilirlik. MikroTik RouterOS de aslında benzer felsefeyi takip eder; ancak Alpine’da çekirdek dahil her şeyi siz seçer, siz derleyebilirsiniz.

diskless vs. sys mode

Alpine’ı kurarken iki temel mod vardır:

• sys mode: Klasik Linux gibi diske kurulur, paketler kalıcıdır. Klasik bir VPS veya bare-metal router için uygundur.
• diskless / data mode: Sistem her açılışta RAM’e yüklenir, sadece /etc/lbu ile işaretlenen yapılandırma dosyaları diskte kalır. Router için ideal: sistem yazılım katmanı immutable hale gelir, sadece konfigürasyon değişir.

Bu diskless model, tam olarak MikroTik’in backup/export dosyası mantığına denk düşer. Aradaki fark, Alpine’da yapılandırmanızı doğrudan Git’te tutabilmenizdir. /etc/network/interfaces, /etc/nftables.nft, /etc/dnsmasq.conf dosyaları sade metindir; PR review yapılabilir, history tutulabilir, rollback bir git revert uzaklıktadır.

Alpine’ı Router Olarak Kurmak: Adım Adım

Aşağıda 2 GB RAM, 8 GB disk ve 2 NIC’li bir sanal makinede (veya APU2/Protectli gibi bir küçük bare-metal cihazda) Alpine 3.19+ ile minimum yönlendirici kurulumunu özetliyorum.

1) Temel Kurulum ve Ağ Arayüzleri

setup-alpine
# Hostname: edge-router-01
# Interface eth0: WAN, dhcp
# Interface eth1: LAN, static 10.10.0.1/24
# Timezone: Europe/Istanbul
# SSHd: openssh, root login: prohibit-password
# Disk: sda, sys mode (veya none for diskless)

Ardından /etc/network/interfaces dosyası şuna benzer hale gelir:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet static
    address 10.10.0.1
    netmask 255.255.255.0

2) IP Forwarding ve NAT

Linux çekirdeği varsayılan olarak paketleri forward etmez. /etc/sysctl.d/99-router.conf:

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

Sonra sysctl -p /etc/sysctl.d/99-router.conf. NAT için nftables (iptables’ın selefi değil halefi):

apk add nftables
rc-update add nftables default

# /etc/nftables.nft
table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state {established, related} accept
        ct state invalid drop
        iif "lo" accept
        iif "eth1" tcp dport {22, 53} accept
        iif "eth1" udp dport {53, 67} accept
        icmp type echo-request limit rate 5/second accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state {established, related} accept
        iif "eth1" oif "eth0" accept
    }
    chain output { type filter hook output priority 0; policy accept; }
}

table ip nat {
    chain postrouting {
        type nat hook postrouting priority 100;
        oif "eth0" masquerade
    }
}

MikroTik RouterOS’ta aynı kuralları yazdığınızda /ip firewall filter add chain=forward ... ile satır satır eklersiniz; Alpine’da tek metin dosyası ile deklaratif olarak tanımlarsınız. Bu, Git versiyonlamak ve CI/CD pipeline’a dahil etmek için altın değerindedir.

3) DHCP ve DNS

Dnsmasq tek paket ile her ikisini de halleder:

apk add dnsmasq
# /etc/dnsmasq.d/lan.conf
interface=eth1
bind-interfaces
domain-needed
bogus-priv
no-resolv
server=1.1.1.1
server=9.9.9.9
dhcp-range=10.10.0.50,10.10.0.200,12h
dhcp-option=3,10.10.0.1
dhcp-option=6,10.10.0.1
log-queries

MikroTik’in DHCP Server + DNS Cache + DNS Static modülünün karşılığı tek bir 12 satırlık dosya. Modern ağ mühendisleri için: bu deklaratif, idempotent ve test edilebilirdir.

Karşılaştırma Tablosu: Alpine Router vs. MikroTik RouterOS

Şimdi gerçekçi bir kıyaslamaya geçelim. Burada amaç birinin diğerini “yenmesini” sağlamak değil; her bir senaryoda hangisinin doğal seçim olduğunu göstermek.

• Donanım entegrasyonu: MikroTik kazanır. RB5009, CCR2004 veya hAP ax gibi cihazlar Switch chip offload, hardware NAT, hardware queue desteği sunar. Alpine bir genel amaçlı PC’de software-only çalışır; donanımsal offload yoktur (yapabildiğinizden değil, distribütör sunmadığından).
• Konfigürasyon UI: MikroTik kazanır. WinBox grafik arayüzü öğrenmesi kolaydır, junior network mühendisleri için onboarding hızlıdır.
• Otomasyon / IaC: Alpine açık ara önde. /etc/ dizini Git’te yaşar, Ansible copy + template modülleri ile push tabanlı yönetim mümkündür, GitOps pipeline’larıyla entegre olur. MikroTik için RouterOS API veya SSH ile script gönderilir; bu çalışır ama doğal değildir.
• Container desteği: Alpine kazanır. Docker, Podman, K3s hepsi native çalışır. MikroTik 7.x da container desteği eklemiştir ancak ekosistem hâlâ kısıtlıdır.
• Routing protokolleri: Berabere. MikroTik OSPF/BGP/MPLS sunar. Alpine’da FRRouting (Quagga’nın halefi) ile aynı protokoller, hatta IS-IS, EIGRP, RIPng dahil tam set mevcuttur.
• Lisanslama ve maliyet: Alpine kazanır. Donanım sizin, yazılım GPL. MikroTik ise CHR’de P1/P10/PU lisanslarına bağlıdır.
• Destek ekosistemi: MikroTik kazanır. Forum, eğitim ve sertifikasyon (MTCNA, MTCRE) yapısı çok daha kurumsaldır.

Hibrit Mimari: Alpine + MikroTik Birlikte

Pratikte gördüğüm en güçlü deployment’lar ikisini birlikte kullananlardır. Tipik bir senaryo:

• Edge cihaz: MikroTik hAP ax² veya RB5009 — internete bakan, ISP ile pazarlık yapan, hardware NAT yapan, basit firewall katmanını uygulayan kutu.
• Service layer: Alpine Linux VM (Proxmox üzerinde) — VPN concentrator (WireGuard), Prometheus exporter, log aggregator, DNS recursor, web proxy, container host görevlerini üstlenir.
• Management plane: Ansible + Git deposu — hem MikroTik /export backup’larını hem de Alpine konfigürasyonlarını versiyonlar; bir CI runner her commit sonrası lint çalıştırır.

Bu yaklaşımın güzelliği şudur: MikroTik dataplane’i hızlandırır, Alpine controlplane’i programlanabilir hale getirir. İkisi BGP veya OSPF konuşur, route’lar iç ağda dinamik şekilde dağılır. Aşağıda Alpine üzerinde FRR ile MikroTik’e iBGP peer kurmanın temel snippet’i:

apk add frr frr-snmp
# /etc/frr/daemons
bgpd=yes

# /etc/frr/frr.conf
router bgp 65000
 bgp router-id 10.10.0.2
 neighbor 10.10.0.1 remote-as 65000
 neighbor 10.10.0.1 description mikrotik-edge
 address-family ipv4 unicast
  network 10.20.0.0/24
 exit-address-family
!
line vty

MikroTik tarafında karşılığı:

/routing bgp instance
add as=65000 router-id=10.10.0.1
/routing bgp peer
add name=alpine-svc remote-address=10.10.0.2 remote-as=65000

Docker ve Container Desteği: Alpine’ın Süper Gücü

Modern bir edge router sadece paket yönlendirmez. Genellikle yan tarafta birkaç hafif servis çalıştırır: Pi-hole tarzı DNS filtre, Prometheus node_exporter, Tailscale veya Headscale node’u, küçük bir Traefik reverse proxy. MikroTik 7.x container desteği eklemiş olsa da kaynaklar dar, imaj seçimi sınırlı. Alpine’da bu sıradan bir görevdir:

apk add docker docker-compose
rc-update add docker default
rc-service docker start

# /opt/edge/docker-compose.yml
services:
  pihole:
    image: pihole/pihole:latest
    network_mode: host
    environment:
      TZ: Europe/Istanbul
      WEBPASSWORD: "${PIHOLE_PASS}"
    volumes:
      - ./pihole:/etc/pihole
      - ./dnsmasq.d:/etc/dnsmasq.d
    restart: unless-stopped

  exporter:
    image: prom/node-exporter:latest
    network_mode: host
    pid: host
    volumes:
      - /:/host:ro,rslave
    command:
      - --path.rootfs=/host
    restart: unless-stopped

  headscale:
    image: headscale/headscale:0.23
    ports:
      - "8080:8080"
    volumes:
      - ./headscale/config:/etc/headscale
      - ./headscale/data:/var/lib/headscale
    command: serve
    restart: unless-stopped

Tek docker compose up -d ile router’ınız aynı zamanda mesh VPN koordinatörüne, DNS sinkholesine ve metriğe dönüşür. Bu kompozisyonu MikroTik üzerinde elde etmek mümkündür ama doğal değildir; Alpine’da bu temel iş akışıdır.

Infrastructure-as-Code: Ansible ile Yönetim

Bir router’ı tek seferlik kurmak hikâyenin sadece ilk perdesidir; gerçek soru “ikinciyi, beşinciyi, ellincisini nasıl kurarsınız?” sorusudur. İşte Alpine’ın asıl parladığı yer burasıdır. Şu örnek playbook, 50 şubedeki edge router’ı saniyeler içinde tutarlı hale getirir:

- hosts: edge_routers
  become: true
  vars:
    lan_subnet: "10.{{ branch_id }}.0.0/24"
    lan_gw: "10.{{ branch_id }}.0.1"
  tasks:
    - name: Install core packages
      community.general.apk:
        name: "{{ item }}"
        state: present
      loop: [nftables, dnsmasq, frr, wireguard-tools, openssh, prometheus-node-exporter]

    - name: Render network interfaces
      template:
        src: interfaces.j2
        dest: /etc/network/interfaces
        mode: '0644'
      notify: restart networking

    - name: Render nftables ruleset
      template:
        src: nftables.nft.j2
        dest: /etc/nftables.nft
        mode: '0640'
      notify: reload nftables

    - name: Enable services
      community.general.openrc:
        name: "{{ item }}"
        enabled: true
        state: started
      loop: [nftables, dnsmasq, sshd, node_exporter]

  handlers:
    - name: restart networking
      service: { name: networking, state: restarted }
    - name: reload nftables
      command: nft -f /etc/nftables.nft

50 router için 50 ayrı WinBox session açmak yerine, ansible-playbook -i inventories/prod edge.yml --limit branch_43 komutu yeterlidir. Yeni şube açılışı bir Git PR’a dönüşür. Disaster recovery terraform apply ile başlar, ansible-playbook ile biter. Bu, modern bir DevOps perspektifidir ve klasik network admin tarzının ötesindedir.

Performans Notları: Software Routing’in Sınırları

Modern Linux çekirdeği XDP (eXpress Data Path) ve eBPF sayesinde yazılım yönlendirmede inanılmaz hızlara ulaşıyor. 4 çekirdekli bir Xeon-D üzerinde Alpine + nftables 10 Gbps’i temiz şekilde forward edebilir. Ancak unutmamak gerekir:

• Donanım NAT yapan bir MikroTik RB5009 ile yarışmak için en azından AES-NI’li, çoklu kuyruklu NIC (Intel X550, Mellanox ConnectX-4) lazım.
• Wireguard, ChaCha20-Poly1305 ile zaten yazılımda çok hızlıdır; Alpine burada MikroTik’i geçer (özellikle çok-çekirdekli sistemde).
• QoS / HTB için tc disiplinleri (cake, fq_codel) Linux’ta daha gelişmiştir.

Güvenlik Yüzeyi: Hangisi Daha Güvenli?

Bu soruya tek bir cümleyle cevap vermek mümkün değil. Her ikisinin de avantajları farklıdır:

• Alpine: Saldırı yüzeyi siz nasıl tasarlarsanız öyle olur. Minimum paket = minimum CVE. apk-tools ile günlük güncelleme alabilirsiniz; SELinux yerine basit ama etkili olan dosya sistemi izinleri + nftables vardır. CVE’ler upstream Linux topluluğundan saatler içinde gelir.
• MikroTik: Closed source ama tek bir vendor’ın disipliniyle güncellenir. RouterOS 7.x yenilemeleri düzenlidir, ama public CVE veritabanı kapsamı daha sınırlıdır. Tarihsel olarak Winbox portu (8291) ve www-ssl ile ilgili sorunlar yaşanmıştır; güvenlik bültenlerini takip etmek şarttır.

Bir hibrit ortamda her iki cihaz tipini de aynı vulnerability scanner (Nessus, OpenVAS) altına almak, MikroTik’i Long-Term Stable kanalında tutmak ve Alpine’ı haftalık apk upgrade --available ile beslemek mantıklı bir politikadır.

Hangi Durumda Hangisini Seçmeliyim?

• 10 kişilik bir ofis, kablosuz dahil tek bir kutu yetecek: MikroTik hAP ax² al, üzerine WireGuard kur, gece uyu.
• 50+ şubeli bir restoran zinciri, merkezi yönetim şart, donanım uniformluğu önemli: MikroTik (RB5009 fleet) + merkezi monitoring (LibreNMS) + Ansible + RouterOS API.
• Bir SaaS şirketinin POP’unda BGP konuşan, Prometheus metriği veren, K3s pod’larıyla yan yana yaşayan bir router lazım: Alpine + FRR + cloud-init ile baremetal provisioning.
• Edge router ve service host birlikte; CI/CD pipeline’a entegre: Hibrit. MikroTik dataplane, Alpine controlplane.

Sık Sorulan Sorular

Alpine Linux router olarak gerçekten enterprise ortamlara uygun mu?

Evet, bilhassa hyper-scale operatörlerin (Cloudflare, Equinix Metal) edge’lerinde Linux tabanlı router yığınları yaygındır. Önemli olan deployment disiplini ve doğru tooling. Alpine + FRR + Ansible kombinasyonu enterprise için yeterince olgundur. Ancak destek sözleşmesi istiyorsanız (örneğin SLA garanti edilecek), ticari bir alternatif (Cumulus, VyOS Subscription veya Cisco) daha uygun olabilir.

MikroTik’i tamamen değiştirmek için Alpine yeterli mi?

Donanım perspektifinden bakarsanız, MikroTik’in ASIC tabanlı switch + offload özelliklerini Alpine’lı bir generic PC üzerinde yakalamak zordur. Ancak yönetim ve programlanabilirlik perspektifinden bakarsanız, Alpine + FRR + nftables tam bir alternatiftir. Pratik tavsiye: edge’de MikroTik, içeride Linux.

Alpine yerine OpenWrt veya VyOS daha iyi değil mi?

Tamamen kullanım senaryosuna bağlıdır. OpenWrt embedded cihazlar için daha hazırdır (UCI sistemi). VyOS, klasik network mühendisine tanıdık gelen Cisco/Juniper benzeri CLI sunar. Alpine ise saf bir Linux deneyimi verir; container çalıştırmak, custom scripting yapmak, generic Python/Go binary deploy etmek istiyorsanız Alpine ön plana çıkar.

Diskless modda yapılandırma değişiklikleri kalıcı olur mu?

Evet. lbu commit komutu, lbu_include listesindeki tüm dosyaları sıkıştırıp apkovl olarak diske yazar. Yeniden başlatınca sistem RAM’e açılır, apkovl açılarak değişiklikleriniz uygulanır. Bu, MikroTik’in backup save + backup load mantığına benzer ama dosya tabanlı olduğu için Git’le doğal entegredir.

FRR yerine direkt Bird kullansam olur mu?

Olur, hatta küçük topolojilerde Bird daha hafiftir ve konfigürasyonu daha okunabilirdir. FRR ise Cisco-benzeri CLI sayesinde klasik network mühendisleri için tanıdık gelir. BGP’de Bird daha agresif şekilde RFC uyumludur; OSPF/IS-IS için FRR daha olgundur.

WireGuard’ı Alpine’da kurmak MikroTik’tekinden farklı mı?

Sözdizimi farklıdır ama protokol aynıdır. Alpine’da wg-quick betiği ile bir .conf dosyası yeterlidir; MikroTik’te /interface/wireguard + /interface/wireguard/peers kombinasyonu kullanılır. Ek olarak Alpine’da systemd-network-online benzeri bağımlılıkları OpenRC ile need net şeklinde tanımlamak gerekir.

Yönlendirici olarak Alpine kullanırsam destek bulurum mu?

Topluluk desteği güçlüdür (Alpine forum, IRC #alpine-linux, FRR Slack). Ticari destek için Alpine’ın kendisi sunmasa da, sistem entegrator firmaları (Calsoft, ScyllaDB tarzı) ve bazı butik DevOps şirketleri SLA verebilir. Network ekibinizde en az bir Linux uzmanı şart.

Sonuç

Alpine Linux ile DIY router inşa etmek, ağ altyapısının “platform” haline gelmesidir. MikroTik bir router’dır; Alpine ise programlayabileceğiniz bir router temelidir. Her ikisinin de kendine has gücü vardır ve modern DevOps perspektifinden bakıldığında, doğru cevap çoğu zaman “ikisini de” şeklindedir. Edge’de MikroTik’in olgun donanımı ile paket başına maliyeti düşürün, içeride Alpine’ın programlanabilirliği ile inovasyonu hızlandırın. Sonraki yazılarımda, bu hibrit mimariye Terraform ile bulut provisioning, Headscale ile mesh VPN ve adaptive firewall katmanlarını ekleyeceğiz.

İlgili Yazılar

Bu rehberi tamamlayan diğer içerikler şunlardır:

• MikroTik Cloud Hosted Router (CHR): VMware, Proxmox, AWS ve Hetzner Üzerinde Dağıtım
• Çoklu Şubeli MikroTik Site-to-Site VPN Mesh: Otomasyon ve Scripting ile Yönetim
• ZeroTier ile MikroTik VPN Mesh: Container Üzerinden Multi-Site Köprüleme
• MikroTik Firewall Stratejisi: Zero Trust Mimarisinden Adaptive Defense'e

Kaynaklar ve Daha Fazla Bilgi

Bu yazıdaki konuları derinleştirmek için aşağıdaki otoriter kaynaklara başvurabilirsiniz:

• Alpine Linux Resmi
• Linux Kernel Project
• Wikipedia: Network Address Translation
• Wikipedia: OSI Model