iac-mikrotik

IAC do zarządzania routerami MikroTik przy użyciu OpenTofu.

• 1: Konfiguracja Interfaces
• 2: Serwery DHCP
• 3: Serwer DNS
• 4: Rekord DNS

router.rachuna-net.pl/
├── interfaces/         # ethernet, bonding, bridge, vlan (*.tf)
├── dhcp-servers/       # każdy serwer DHCP w osobnym pliku
├── dns-server/         # main.tf z konfiguracją resolvera
└── dns-records/        # mapa statycznych rekordów DNS

1 - Konfiguracja Interfaces

Konfiguracja Interfaces

Celem tej sekcji jest ujednolicenie oraz pełna automatyzacja konfiguracji interfejsów sieciowych w infrastrukturze RouterOS. Dokumentacja obejmuje:

• porty Ethernet,
• interfejsy Bonding (LACP),
• mosty logiczne Bridge,
• sieci wirtualne VLAN.

Każdy typ interfejsu:

• jest zarządzany przez dedykowany moduł OpenTofu,
• posiada własny katalog konfiguracyjny,
• może być wersjonowany i audytowany w systemie kontroli wersji.

1. Struktura katalogów

Konfiguracja interfejsów znajduje się w:

router.rachuna-net.pl/interfaces/
├── ethernet/
├── bonding/
├── bridge/
└── vlan/

Zasada organizacyjna:

✅ jeden plik = jedna logiczna konfiguracja ✅ brak konfiguracji w GUI ✅ pełna powtarzalność konfiguracji

2. Konfiguracja Ethernet

Pliki znajdują się w:

router.rachuna-net.pl/interfaces/ethernet/*.tf

Przykładowa konfiguracja

module "ethernet_ether1" {
  source = "git@gitlab.rachuna-net.pl:pl.rachuna-net/infrastructure/opentofu/modules/routeros-ethernet.git?ref=v1.0.0"

  name         = "ether1"
  mtu          = 1500
  arp          = "enabled"
  poe_out      = "off"
  disabled     = false
  dhcp_client  = false
  addresses    = ["192.0.2.1/24"]  # lub puste, jeśli tylko do bridge/bonding
}

Znaczenie parametrów

3. Bonding – agregacja łączy (LACP)

Pliki znajdują się w:

interfaces/bonding/*.tf

Przykład (tryb LACP – 802.3ad):

module "bonding_storage" {
  source = "git@gitlab.rachuna-net.pl:pl.rachuna-net/infrastructure/opentofu/modules/routeros-bonding.git?ref=v1.0.0"

  name      = "bond-storage"
  mode      = "802.3ad"
  slaves    = ["ether2", "ether3"]
  lacp_rate = "1sec"
  arp       = "enabled"
  comment   = "storage uplink"
}

Znaczenie parametrów

4. Bridge

Pliki znajdują się w:

interfaces/bridge/*.tf

Przykład:

module "bridge_clients" {
  source = "git@gitlab.rachuna-net.pl:pl.rachuna-net/infrastructure/opentofu/modules/routeros-bridge.git?ref=v1.0.0"

  name     = "br-clients"
  comment  = "bridge klientów"
  ageing   = 300
  protocol_mode = "rstp"
  ports = [
    { interface = "ether4", pvid = 10 },
    { interface = "ether5", pvid = 10 }
  ]
}

Znaczenie parametrów

4. VLAN – sieci logiczne

Pliki znajdują się w:

interfaces/vlan/*.tf

Przykład:

module "vlan_vms_internal" {
  source = "git@gitlab.rachuna-net.pl:pl.rachuna-net/infrastructure/opentofu/modules/routeros-vlan.git?ref=v1.0.0"

  name        = "vlan-vms-int"
  interface   = "bond-storage"   # trunk/bond/ether/bridge
  vlan_id     = 20
  arp         = "enabled"
  mtu         = 1500
  loop_protect = false
  comment     = "VLAN VMs internal"
}

Znaczenie parametrów

5. Kolejność wdrażania konfiguracji

Zalecana kolejność:

1. Ethernet
2. Bonding
3. Bridge
4. VLAN

Zapobiega to błędom zależności i brakującym interfejsom

2 - Serwery DHCP

Konfiguracja Serwerów DHCP

Architektura serwera DHCP w projekcie iac-mikrotik

Konfiguracja DHCP składa się z kilku warstw logicznych:

1. Interfejs L3, na którym działa DHCP (np. BRIDGE-PROXMOX lub interfejs VLAN)

2. Sieć DHCP (dhcp_network) definiuje:

   • adresację,
   • bramę,
   • serwery DNS,
   • domenę.

3. Pula adresowa (address_pools) zakresy IP do automatycznego przydziału.

4. Serwer DHCP (dhcp-server) instancja działająca na wybranym interfejsie.

5. Leases (dhcp_leases) statyczne rezerwacje IP na podstawie MAC.

Struktura plików

Konfiguracja DHCP znajduje się w katalogu:

router.rachuna-net.pl/dhcp-servers/*.tf

Każdy serwer DHCP powinien być definiowany w osobnym pliku.

Zalety:

• wersjonowanie każdej podsieci,
• audyt zmian,
• możliwość rollback,
• czysta i modularna struktura projektu.

Przykład konfiguracji serwera DHCP

Poniżej pełen przykład wdrożenia serwera DHCP dla sieci Proxmox:

module "dhcp-proxmox" {
  source = "git@gitlab.rachuna-net.pl:pl.rachuna-net/infrastructure/opentofu/modules/routeros-dhcp-server.git?ref=v1.0.0"

  name         = "DHCP-PROXMOX"
  comment      = "DHCP server for PROXMOX"
  address_pool = "PROXMOX-POOLS"
  interface    = "BRIDGE-PROXMOX"
  lease_time   = "12h"

  dhcp_network = {
    address    = "10.3.0.0/24"
    gateway    = "10.3.0.1"
    dns_server = ["10.3.0.1"]
    domain     = "rachuna-net.pl"
    comment    = "proxmox network"
  }

  address_pools = {
    "PROXMOX-POOLS" = {
      ranges  = ["10.3.0.11-10.3.0.14"]
      comment = "proxmox pool"
    }
  }

  dhcp_leases = {
    "10.3.0.11" = {
      hostname    = "pve-s1.rachuna-net.pl"
      comment     = "pve-s1.rachuna-net.pl"
      mac_address = "38:05:25:33:B8:49"
      server      = "DHCP-PROXMOX"
      disabled    = false
    }
    "10.3.0.12" = {
      hostname    = "pve-s2.rachuna-net.pl"
      comment     = "pve-s2.rachuna-net.pl"
      mac_address = "D8:5E:D3:6B:3F:0C"
      server      = "DHCP-PROXMOX"
      disabled    = false
    }
    "10.3.0.13" = {
      hostname    = "pve-s3.rachuna-net.pl"
      comment     = "pve-s3.rachuna-net.pl"
      mac_address = "18:C0:4D:8C:4F:5E"
      server      = "DHCP-PROXMOX"
      disabled    = false
    }
  }
}

Omówienie parametrów technicznych

5.1. Parametry serwera DHCP

5.2. Sieć DHCP

Sekcja dhcp_network jest kluczowa – definiuje parametry, które klient otrzyma w komunikacie DHCP OFFER:

5.3. Pula adresowa (dynamiczne przydzielanie IP)

Każda pula posiada nazwę klucza — np.:

"PROXMOX-POOLS"

5.4. Leases (statyczne przypisania)

Zalecane w serwerowniach, hypervisorach, NAS, firewallach.

Zasady projektowe i dobre praktyki

1. Ogólne zasady

• Każda podsieć = osobny moduł DHCP
• DHCP musi działać tylko na interfejsach L3
• Nigdy nie mieszaj DHCP z adresacją statyczną w tej samej puli
• Węzły Proxmox, Routery, Nas’y – zawsze na statycznych lease

2. Bezpieczeństwo

• DHCP powinien działać tylko w zaufanych segmentach sieci.

• Zalecane filtrowanie:

  • DHCP snooping na switchach,
  • blokada rogue DHCP serwerów.

3. Integracja z DNS

W RouterOS serwer DHCP może dynamicznie rejestrować hosty w DNS. Pole hostname w lease jest automatycznie używane do:

• zapisu rekordów A,
• aktualizacji rekordów PTR.

Typowe błędy i jak ich unikać

Podsumowanie

Serwer DHCP w iac-mikrotik zapewnia:

• deklaratywne, w pełni automatyczne zarządzanie adresacją,
• wersjonowanie zmian w Git,
• spójność konfiguracji RouterOS,
• łatwe wdrażanie i modyfikowanie pul IP,
• centralne rezerwacje dla serwerów i hostów krytycznych.

3 - Serwer DNS

Konfiguracja Serwera DNS

Struktura plików

Konfiguracja DNS znajduje się w katalogu:

router.rachuna-net.pl/dns-server/main.tf

Zalety takiego podejścia:

• centralne zarządzanie resolverem,
• wersjonowanie konfiguracji,
• szybki rollback,
• spójność dla całego środowiska.

Przykład konfiguracji serwera DNS

module "dns_server" {
  source = "git@gitlab.rachuna-net.pl:pl.rachuna-net/infrastructure/opentofu/modules/routeros-dns.git?ref=v1.0.0"

  allow_remote_requests   = true
  cache_max_ttl           = "1d"
  max_concurrent_queries  = 1000
  servers                 = ["1.1.1.1", "8.8.8.8"]
  dynamic_servers         = []
  comment                 = "DNS resolver/router"
}

Omówienie parametrów technicznych

1. Parametry instancji serwera DNS

2. Rola cache DNS

Mechanizm cache:

• znacząco redukuje liczbę zapytań wychodzących,
• poprawia wydajność sieci,
• zwiększa odporność na chwilowe awarie upstream.

W konfiguracji:

cache_max_ttl = "1d"

oznacza, że odpowiedzi mogą być przechowywane przez maksymalnie 24 godziny.

3. Serwery upstream

servers = ["1.1.1.1", "8.8.8.8"]

Oznacza to wykorzystanie:

• **Cloudflare DNS – 1.1.1.1,
• **Google DNS – 8.8.8.8.

Zastosowanie co najmniej dwóch niezależnych operatorów DNS zwiększa odporność na awarie.

Integracja DNS z DHCP

W projekcie iac-mikrotik DNS jest bezpośrednio powiązany z DHCP:

• każdy lease z hostname,

• automatycznie tworzy:

  • rekord A,
  • rekord PTR,

• umożliwia rozwiązywanie nazw lokalnych:

pve-s1.rachuna-net.pl → 10.3.0.11
10.3.0.11 → pve-s1.rachuna-net.pl

Dzięki temu:

• hosty są widoczne po nazwach,
• działa poprawnie Kerberos, LDAP, TLS, monitoring, HA Proxmox.

Zasady projektowe i dobre praktyki

1. Ogólne zasady

• Jeden centralny resolver DNS dla całej infrastruktury
• DNS zawsze wskazywany przez DHCP
• DNS zawsze działa na routerze brzegowym
• Brak konfiguracji DNS bezpośrednio na hostach

2. Bezpieczeństwo

• allow_remote_requests powinien być:

  • włączony tylko dla sieci zaufanych,

• brak otwartego DNS do Internetu,

• firewall powinien blokować:

  • zapytania DNS spoza infrastruktury.

3. Spójność DNS i TLS

• Każdy host produkcyjny powinien posiadać:

  • rekord A,
  • rekord PTR,

• Brak PTR = problemy z:

  • pocztą,
  • certyfikatami,
  • monitoringiem,
  • logami.

Typowe błędy i jak ich unikać

Podsumowanie

Serwer DNS w iac-mikrotik zapewnia:

• centralny, cache’ujący resolver,
• dynamiczne rekordy A i PTR z DHCP,
• wysoką wydajność dzięki cache,
• pełną deklaratywność w IaC,
• brak ręcznej konfiguracji RouterOS,
• spójność nazw w całym środowisku IT.

Jeżeli chcesz, mogę dodatkowo przygotować:

• dokumentację rekordów statycznych DNS (A, CNAME, TXT),
• integrację DNS z Vault PKI,
• model DNS dla Proxmox + Kubernetes + Wi-Fi + DMZ,
• checklistę audytową DNS pod bezpieczeństwo.

4 - Rekord DNS

Konfiguracja Rekordów DNS

Oprócz działania jako resolver i cache, serwer DNS w RouterOS może również pełnić rolę lokalnego, autorytatywnego serwera rekordów statycznych dla domeny wewnętrznej. W projekcie iac-mikrotik realizowane jest to poprzez mapę dns_records w module routeros-dns.

Rekordy te są:

• w pełni zarządzane przez IaC,
• wersjonowane w Git,
• niezależne od DHCP,
• odporne na restart routera,
• wykorzystywane przez TLS, monitoring, reverse proxy, klastry i routing.

Struktura dns_records

Rekordy DNS definiowane są jako mapa rekordów, gdzie:

• klucz mapy = identyfikator rekordu,
• wartość = pełna definicja wpisu DNS.

Przykład konfiguracji:

dns_records = {
  "router.rachuna-net.pl" = {
    name    = "router.rachuna-net.pl"
    address = "10.0.0.1"
    type    = "A"
    ttl     = "1w"
    comment = "Router IP address"
  }
}

Omówienie parametrów rekordu DNS

Obsługiwane typy rekordów (praktyczne zastosowanie)

Przykład rekordu aliasu:

"dns.rachuna-net.pl" = {
  name    = "dns.rachuna-net.pl"
  address = "router.rachuna-net.pl"
  type    = "CNAME"
  ttl     = "1d"
  comment = "Alias for router DNS"
}

Rola rekordów statycznych vs DHCP

✅ Zasada infrastrukturalna:

Każdy element krytyczny infrastruktury powinien posiadać rekord statyczny, a nie tylko dynamiczny z DHCP.

TTL – znaczenie w praktyce

U Ciebie:

ttl = "1w"

oznacza, że:

• cache DNS będzie przechowywał wpis nawet przez 7 dni,
• zmiany IP wymagają ręcznego odświeżenia cache,
• idealne dla infrastruktury stałej (router, core).

Powiązanie z TLS, monitoringiem i reverse proxy

Statyczne rekordy DNS są wykorzystywane bezpośrednio przez:

• certyfikaty TLS (Vault PKI, ACME),
• monitoring (Prometheus, Zabbix, Grafana),
• reverse proxy (Nginx, Traefik),
• klastry (Proxmox, Kubernetes).

Brak statycznego DNS powoduje:

• niestabilność certyfikatów,
• błędy monitoringu,
• problemy z HA i load balancingiem.

Typowe błędy i jak ich unikać

Podsumowanie sekcji dns_records

Sekcja dns_records w iac-mikrotik zapewnia:

• centralne, statyczne wpisy DNS,
• pełną kontrolę nad infrastrukturą nazw,
• powtarzalność wdrożeń,
• brak ręcznej edycji RouterOS,
• kompatybilność z TLS, DHCP, monitoringiem i proxy,
• spójność nazw w całym ekosystemie IT.