Alpine Linux ile DIY Router: MikroTik Alternatifi mi, Tamamlayıcısı mı?
Alpine Linux ile DIY router kurulumu, MikroTik ile karşılaştırma, hibrit kullanım ve container destekli edge mimarisi.
Devamını Oku →
MikroTik’in Cloud Hosted Router (CHR) ürünü, fiziksel donanım dünyasında uzun süredir lider olan RouterOS’u bulut çağına taşıyan ilginç bir adımdır. CHR’yi diğer “VPN appliance” türü ürünlerden ayıran şey, RouterOS’un tüm özelliklerini (BGP, OSPF, MPLS, queue, firewall, hotspot) hipervisor üzerinde bir x86_64 sanal makinesi olarak sunmasıdır. Bu yazıda CHR’yi DevOps perspektifinden ele alacağız: VMware, Proxmox, AWS, Hetzner ve Vultr üzerinde nasıl dağıtacağımızı, lisanslamanın inceliklerini ve en önemlisi Terraform ile bu altyapıyı nasıl kodla yöneteceğimizi inceleyeceğiz.
Sekiz yıllık DevOps deneyimimde, MikroTik’in bulut benimsemesi en yavaş ürün katmanlarından biri olarak kaldı. Genelde “edge cihaz” mantığıyla düşünüldüğü için, bulutta var olabileceği fikri network mühendislerine zor geliyor. Oysa modern multi-cloud topolojilerinde CHR, on-prem ile bulut arasında konuşan ideal bir bridge’tir; doğru otomasyonla 50 farklı bölgede 50 dakikada deploy edilebilir.
CHR; tam olarak x86_64 hipervisor üzerinde çalışacak şekilde paketlenmiş bir RouterOS imajıdır. RouterOS 6.x’ten beri sunulan ve şu özellikleri olan bir sanal makine olarak düşünebilirsiniz:
CHR’nin olmadığı şeyler de önemlidir:
CHR lisanslaması RouterOS’un genel “level” sisteminden farklıdır. Dört seviye vardır:
Perpetual lisanslar bir CHR instance’a bağlıdır; instance silinirse lisans serbest bırakılabilir ancak bunu MikroTik destek talebi ile yapmak gerekir. Bu nedenle, immutable infrastructure mantığıyla “her deploy yeni VM” yapısı kuran ekipler için P1/P10/PU yerine 60-günlük trial + Annual lisans (zayıf bir adoption olan ama mevcut) daha esnek olabilir. Üretimde sabit IP ve sabit instance kullanan ekipler için Perpetual hâlâ en mantıklı seçim.
Lisanslamayı otomatize etmek mümkündür. MikroTik account API’si üzerinden lisansı CLI ile alabilirsiniz:
# Account portal kimlik bilgileri ile lisansı çek
/system license renew [email protected] password=portalpass level=p1
Proxmox; KVM tabanlı, açık kaynak ve self-hosted bir hipervisor olarak DevOps ortamlarında giderek popüler. CHR’yi Proxmox’a deploy etmek için temel adımlar:
# Proxmox host üzerinde
cd /var/lib/vz/template/iso
wget https://download.mikrotik.com/routeros/7.13.4/chr-7.13.4.img.zip
unzip chr-7.13.4.img.zip
# Yeni VM oluştur (qm CLI)
qm create 200
--name chr-edge-01
--memory 1024
--cores 2
--net0 virtio,bridge=vmbr0
--net1 virtio,bridge=vmbr1
--ostype l26
--scsihw virtio-scsi-pci
# CHR raw disk'i import et
qm importdisk 200 chr-7.13.4.img local-lvm
# Disk'i SCSI olarak bağla
qm set 200 --scsi0 local-lvm:vm-200-disk-0
qm set 200 --boot order=scsi0
qm set 200 --serial0 socket --vga serial0
qm start 200
İlk açılışta serial console (qm terminal 200) ile bağlanırsınız. Varsayılan kullanıcı admin, şifre boş. Ardından klasik RouterOS yapılandırması başlar. Production’da daha mantıklı olan Cloud-init benzeri bir initial config injection mekanizmasıdır; ne yazık ki CHR cloud-init desteklemez. Bunun yerine second drive olarak FAT32 config disk mount edip autorun.scr ile script çalıştırabilirsiniz.
#!/usr/bin/env bash
# /usr/local/bin/spawn-chr.sh
set -euo pipefail
VMID=$1
NAME=$2
WAN_BRIDGE=${3:-vmbr0}
LAN_BRIDGE=${4:-vmbr1}
TEMPLATE_DISK="/var/lib/vz/template/iso/chr-7.13.4.img"
qm clone 100 $VMID --name $NAME --full true
qm set $VMID --net0 virtio,bridge=$WAN_BRIDGE
qm set $VMID --net1 virtio,bridge=$LAN_BRIDGE
qm set $VMID --memory 2048 --cores 2
# Inject config disk
CONFIG_IMG=/tmp/chr-config-$VMID.img
dd if=/dev/zero of=$CONFIG_IMG bs=1M count=4
mkfs.vfat $CONFIG_IMG
mkdir -p /mnt/chrcfg
mount -o loop $CONFIG_IMG /mnt/chrcfg
cat > /mnt/chrcfg/autorun.scr <
Bu basit wrapper, "yeni CHR" deploy etmeyi tek komuta indirir. 50 şubelik bir kurulum için for-loop yeterlidir.
MikroTik, AWS Marketplace'te resmi CHR AMI'si yayınlamıştır. AMI ID'leri bölgeye göre değişir (örneğin eu-central-1'de farklı, us-east-1'de farklı). En güncel listeyi aws ec2 describe-images --filters "Name=name,Values=*CHR*" --owners aws-marketplace ile alabilirsiniz.
Önemli noktalar:
c6i.large veya m6i.large önerilir; ENA (Elastic Network Adapter) sürücüsü desteği vardır.autorun.scr mekanizmasını taklit eder.# main.tf
terraform {
required_providers {
aws = { source = "hashicorp/aws", version = "~> 5.0" }
}
}
provider "aws" { region = "eu-central-1" }
data "aws_ami" "chr" {
most_recent = true
owners = ["aws-marketplace"]
filter {
name = "name"
values = ["mikrotik-CHR-*"]
}
}
resource "aws_security_group" "chr" {
name = "chr-edge-sg"
vpc_id = var.vpc_id
ingress { from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = [var.admin_cidr] }
ingress { from_port = 8291 to_port = 8291 protocol = "tcp" cidr_blocks = [var.admin_cidr] }
ingress { from_port = 51820 to_port = 51820 protocol = "udp" cidr_blocks = ["0.0.0.0/0"] }
egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] }
}
resource "aws_instance" "chr_edge" {
ami = data.aws_ami.chr.id
instance_type = "c6i.large"
subnet_id = var.public_subnet_id
vpc_security_group_ids = [aws_security_group.chr.id]
source_dest_check = false # Router için zorunlu!
key_name = var.ssh_key_name
user_data = <<-EOT
/user set admin password="${var.admin_pass}"
/ip dns set servers=1.1.1.1,9.9.9.9 allow-remote-requests=yes
/interface wireguard add name=wg-corp listen-port=51820 private-key="${var.wg_priv}"
/ip address add address=10.99.0.1/24 interface=wg-corp
/interface wireguard peers add interface=wg-corp public-key="${var.wg_peer_pub}" allowed-address=10.99.0.10/32
EOT
tags = { Name = "chr-edge", ManagedBy = "terraform" }
}
resource "aws_eip" "chr" {
instance = aws_instance.chr_edge.id
domain = "vpc"
}
Burada source_dest_check = false kritik bir noktadır. AWS VPC, varsayılan olarak EC2 instance'larından gelen paketin kaynak veya hedefinin instance'ın IP'si olmasını bekler. Router gibi davranan bir VM bu kontrolü disable etmek zorundadır.
CHR'yi VGW (Virtual Private Gateway) veya Transit Gateway BGP peer'i olarak kullanabilirsiniz. Bu sayede on-prem'inizden gelen prefix'ler dinamik olarak öğrenilir:
/routing bgp instance
add as=65100 router-id=10.0.0.10
/routing bgp peer
add name=aws-vgw remote-address=169.254.1.1 remote-as=64512
hold-time=30s keepalive-time=10s
Hetzner, fiyat/performans dengesinde çok iyi olduğu için DevOps ekiplerinin sevdiği bir platformdur. Resmi bir CHR imajı yoktur; ancak snapshot oluşturarak custom imaj sunabilirsiniz.
Adımlar:
wget ile CHR raw image'ı çekin.dd ile diske yazın: dd if=chr.img of=/dev/sda bs=4M# hcloud CLI ile snapshot'tan instance deploy
hcloud server create
--name chr-fra-01
--image $CHR_SNAPSHOT_ID
--type cx21
--location fsn1
--network corp-net
--ssh-key admin
Terraform tarafında karşılığı:
resource "hcloud_server" "chr" {
name = "chr-fra-01"
image = data.hcloud_image.chr_snapshot.id
server_type = "cx21"
location = "fsn1"
network {
network_id = hcloud_network.corp.id
ip = "10.0.1.5"
}
ssh_keys = [hcloud_ssh_key.admin.id]
labels = { managed_by = "terraform", role = "edge_router" }
}
Hetzner'in bir özelliği vSwitch ürünüdür; bu sayede Hetzner Cloud + dedicated server topolojinizi tek bir Layer 2 ağda toplayabilirsiniz. CHR bu vSwitch'in bridge'inde central router olarak görev yapabilir.
Vultr, özellikle "ISO upload" özelliği nedeniyle CHR için DevOps ekiplerinin gözdesidir. Adımlar şöyledir:
Vultr'un API'si Terraform provider'ı ile entegredir:
resource "vultr_iso_private" "chr" {
url = "https://download.mikrotik.com/routeros/7.13.4/chr-7.13.4.img.zip"
}
resource "vultr_instance" "chr_edge" {
plan = "vc2-1c-1gb"
region = "fra"
iso_id = vultr_iso_private.chr.id
label = "chr-fra-01"
hostname = "chr-fra-01"
enable_ipv6 = true
}
VMware ortamında CHR'nin OVA imajı resmi olarak dağıtılır. govc CLI ile import otomatize edilebilir:
# govc kurulumu (Go binary)
export GOVC_URL=https://vcenter.example.com
export [email protected]
export GOVC_PASSWORD=...
export GOVC_INSECURE=true
govc import.ova
-ds=datastore1
-pool=/DC/host/cluster1/Resources
chr-7.13.4.ova
govc vm.network.add -vm chr-edge -net "VLAN10-WAN"
govc vm.network.add -vm chr-edge -net "VLAN20-LAN"
govc vm.power -on chr-edge
vSphere üzerinde Terraform hashicorp/vsphere provider'ı ile aynı işlemi yapabilirsiniz; productionsa Pulumi tercih edenler için TypeScript ile de benzer kod yazılabilir. ESXi tarafında CHR için en kritik VMware ayarı "Promiscuous Mode" + "Forged Transmits" seçeneklerinin port grubunda etkinleştirilmesidir. Aksi halde CHR'den geçen paketler vSwitch tarafından düşürülür.
10 farklı bulutta 50 CHR çalıştırdığınızda artık tek tek WinBox açmak ölçeklenmez. Ansible'ın community.routeros koleksiyonu CHR ile mükemmel uyumludur:
# inventory.yml
all:
children:
chr_edge:
hosts:
chr-aws-fra: { ansible_host: 10.0.1.5 }
chr-aws-iad: { ansible_host: 10.0.2.5 }
chr-hetzner-fsn: { ansible_host: 10.1.1.5 }
chr-vultr-fra: { ansible_host: 10.2.1.5 }
vars:
ansible_connection: network_cli
ansible_network_os: community.routeros.routeros
ansible_user: ansible-bot
# playbook.yml
- hosts: chr_edge
gather_facts: false
tasks:
- name: Apply baseline firewall
community.routeros.command:
commands:
- /ip firewall filter add chain=input action=drop in-interface=ether1 connection-state=invalid
- /ip firewall filter add chain=input action=accept connection-state=established,related
- /ip firewall filter add chain=input action=drop in-interface=ether1
- name: Configure NTP
community.routeros.command:
commands:
- /system ntp client set enabled=yes
- /system ntp client servers add address=pool.ntp.org
Bu yapı tek bir ansible-playbook komutuyla 50 farklı bulut bölgesindeki tüm CHR'lerinizi tutarlı hale getirir.
CHR'nin SNMP modülü standart RouterOS ile aynıdır. SNMPv3 önerilir:
/snmp set enabled=yes
/snmp community add name=corp-ro security=private
/snmp set engine-id="chr-aws-fra"
Prometheus tarafında nshttpd/mikrotik-exporter (artık ksurl'in fork'u daha aktif) kullanılabilir:
# mikrotik-exporter.yml
devices:
- name: chr-aws-fra
address: 10.0.1.5
user: prometheus-bot
password: ${MTK_PASS}
- name: chr-hetzner-fsn
address: 10.1.1.5
user: prometheus-bot
password: ${MTK_PASS}
features:
bgp: true
routes: true
wireguard: true
optics: false
ipsec: true
Grafana dashboard'larında "CHR per-region throughput", "BGP session up/down", "WireGuard peer handshake age" panelleri standart hale gelir.
CHR ne kadar otomatize olursa olsun, native Kubernetes resource'u değildir. Bu nedenle ArgoCD ile doğrudan yönetilemez. Ancak Crossplane veya Pulumi Kubernetes Operator ile arada bir abstraction katmanı eklenebilir. Pratik yaklaşım: Git deposunda Terraform + Ansible kodu tutmak, GitHub Actions / GitLab CI ile değişikliklerde otomatik terraform plan ve ansible-playbook --check çalıştırmak, merge sonrası apply yapmaktır.
# .github/workflows/chr-deploy.yml
name: CHR Deploy
on:
push:
paths: ['terraform/chr/**', 'ansible/playbooks/chr_*.yml']
jobs:
plan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v3
- run: terraform -chdir=terraform/chr init
- run: terraform -chdir=terraform/chr plan -out=tfplan
- uses: actions/upload-artifact@v4
with: { name: tfplan, path: terraform/chr/tfplan }
apply:
needs: plan
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- uses: actions/download-artifact@v4
with: { name: tfplan, path: terraform/chr/ }
- run: terraform -chdir=terraform/chr apply -auto-approve tfplan
- run: ansible-playbook -i ansible/inventories/prod ansible/playbooks/chr_baseline.yml
cpu parametresini host yaparak AES-NI'nin guest'e geçmesini sağlayın. qm set 200 --cpu host.queues=N ile birden fazla TX/RX kuyruğu açın. 2-4 vCPU için 2 kuyruk yeterli./ipv6 dhcp-client add interface=ether1 eklemeyi unutmayın.Hipotetik bir senaryo: Avrupa'da 10 şube, hub Frankfurt'ta. Karşılaştırma:
Görüldüğü gibi hybrid yaklaşım çoğu zaman en mantıklı: edge'de bir MikroTik donanım kutusu (low-cost CapEx), bulutta bir-iki adet CHR (yüksek-bandwidth backbone). Bu kombinasyon, multi-region WireGuard mesh + BGP backbone için ideal.
Performans açısından çoğunlukla evet. Bir CCR2004 yaklaşık 4-5 Gbit/s yapar; benzer maliyetli bir c6i.xlarge CHR aynı seviyededir. Ancak fiziksel cihazların ASIC tabanlı switch offload, hardware NAT ve PoE port gibi özellikleri CHR'de yoktur.
Resmi olarak hayır; pratikte MikroTik destek talebi ile lisans key'i yeni instance'a transfer edilebilir. Süreç bir-iki iş günü sürebilir. Immutable infrastructure ile çalışıyorsanız bu sürtünme önemli olur; bu durumda Annual lisans daha uygun olabilir.
Düşük trafik (1 Gbps altı, sabit instance) için Marketplace daha kolaydır. Yüksek trafik veya 10+ instance fleet için BYOL + Perpetual Unlimited daha ucuza gelir. Marketplace EC2 fiyatı + RouterOS lisansını birleştirir; bunu kendiniz manuel yaparsanız genelde %30-40 tasarruf olur.
Doğrudan yok. Ancak KubeVirt ile CHR sanal makinesi Kubernetes cluster içinde çalıştırılabilir. Bu setup özellikle telco edge ve MEC (Multi-access Edge Computing) senaryolarında gündeme geliyor. Production'da hâlâ deneysel sayılır.
VRRP RouterOS'ta yerleşiktir; iki CHR aktif-pasif yapı kurabilir. Cloud-native HA için Floating IP + sağlayıcı API'si gerekir (örneğin AWS'de Elastic IP'yi failover ile bir Lambda fonksiyonuna bağlamak). Active-active için BGP ECMP en temiz çözüm.
Hayır; Terraform sadece sanal makine ve underlying altyapıyı (Security Group, VPC, EIP) yönetir. CHR'nin içindeki yapılandırma için Ansible veya custom REST API çağrıları (RouterOS API üzerinden) kullanılır. İki katmanlı bir yaklaşım çoğu ekip için en sürdürülebilir olmuştur.
RouterOS güvenli bir codebase'tir ancak default credentials ve açık servis listesi büyük tehlikelidir. Production CHR'ler için: SSH key tabanlı, WinBox portu disable veya IP-restricted, Web admin disable, API SSL only, MAC server disable şart. Cloud Security Group/Firewall katmanında da bu servisleri sıkılaştırın.
CHR; RouterOS'un olgun feature setini bulut çağına taşımanın MikroTik'in ilk ve hâlâ en başarılı denemesidir. Doğru otomasyon (Terraform + Ansible + GitHub Actions) ile multi-cloud topolojiler tek bir Git deposundan yönetilebilir hale gelir. Performans, lisanslama ve cloud-native uyum konularındaki tuzakları bilen bir DevOps ekibi için CHR; on-prem MikroTik fleet ile bulut workload'ları arasında en organik bridge'lerden biridir. Bir sonraki yazıda CHR + WireGuard ile multi-region mesh tasarımı ve adaptive firewall ile zero-trust katmanı eklemeyi inceleyeceğiz.
Konuyla bütünleşik olarak okumanızı önerdiğimiz içerikler:
Bu yazıdaki konuları derinleştirmek için aşağıdaki otoriter kaynaklara başvurabilirsiniz:
Mikrotik CHR kurulumu Proxmox'ta indirilen imajın VM diski olarak eklenmesiyle yapılır:
# CHR imajını indir ve aç
wget https://download.mikrotik.com/routeros/7.15/chr-7.15.img.zip
unzip chr-7.15.img.zip
# VM oluştur (id=200) ve diski import et
qm create 200 --name chr --memory 256 --cores 1 --net0 virtio,bridge=vmbr0
qm importdisk 200 chr-7.15.img local-lvm
qm set 200 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-200-disk-0
qm set 200 --boot order=scsi0 && qm start 200
ethernet0.virtualDev = "vmxnet3"
scsi0.virtualDev = "pvscsi"
sched.mem.pin = "TRUE"
Bulut router kurulum desteği için MikroTik Hizmetlerimize göz atın.