| Prostředí | Elektro Uldrich – router KunDratka (RB3011UiAS) |
| Platnost | RouterOS 7.21 a novější (QR kód a client-allowed-address vyžadují 7.21+) |
| Ověřeno na | RouterOS 7.22.1 |
| Verze | 1.1 (2026-09-12) |
Tento článek popisuje jednorázové zřízení serverové části WireGuard Point-to-Site VPN: rozhraní, adresaci, firewall, routing, NAT a DNS.
Zakládání jednotlivých uživatelů (peerů) není součástí tohoto článku – viz KB-02. Serverová část se zřizuje jednou, peery se pak zakládají opakovaně podle KB-02.
Proč WireGuard místo L2TP/IPsec nebo SSTP:
| Předpoklad | Poznámka |
|---|---|
| RouterOS 7.21+ | Nižší verze fungují, ale nepodporují generování konfigurace pro uživatele a QR kódu na routeru |
| Veřejná IP nebo veřejné DNS jméno | Vyhrazená veřejná IP stačí i za NATem ISP. Za CGNAT WireGuard nefunguje bez portmapy |
| Volný UDP port | Před volbou portu ověřit obsazenost: /interface/wireguard/print |
| Vyhrazený /24 rozsah pro tunel | Viz adresní standard níže |
| Přístup na router přes WinBox/SSH | Doporučeno WinBox – má tlačítko pro QR kód |
Jednotný standard, aby byla konfigurace na routeru čitelná – KunDratka hostí několik WireGuard tunelů současně.
| Objekt | Konvence | Příklad |
|---|---|---|
| Interface | wg-<ZKRATKA> |
wg-EUL |
Peer (name) |
<prijmeni><inicialaJmena> nebo <hostname> bez diakritiky |
prokupkovaj, nb-jnovak |
| Comment na interface | P2S VPN <popis> |
P2S VPN ElektroUldrich |
| Address-list pro cíle | WG-<ZKRATKA>-allowed |
WG-EUL-allowed |
| DNS jméno endpointu | vpn.<domena> |
vpn.elnet-group.cz |
Do názvu rozhraní nepatří slovo „interface“ – RouterOS ho zobrazuje v kontextu rozhraní, takže je to jen šum navíc.
10.49.x.0/24 a zapsat ho do evidence rozsahů; nikdy nevolit náhodně..1 = router (server), zařízení uživatelů od .2 výše.192.168.0.0/24, 192.168.1.0/24 a 10.0.0.0/24./24, peerům přidělujeme /32.Rozsahy P2S tunelu:
| Interface | Rozsah | Port |
|---|---|---|
wg-EUL (uživatelé) |
10.49.222.0/24 |
13240 |
wg-EUL-admin (admini) |
10.49.223.0/24 |
13241 |
Dva interfacy nikdy nesmí poslouchat na stejném portu ani používat stejný adresní rozsah. Před zavedením dalšího tunelu ověřit, co je na routeru obsazené:
/interface/wireguard/print
/ip/address/print where interface~"wg"
Příklad používá wg-EUL: tunel 10.49.222.0/24, port 13240, cílové sítě 192.168.13.0/24 a 10.250.1.0/24.
/interface/wireguard
add name=wg-EUL listen-port=13240 mtu=1420 comment="P2S VPN ElektroUldrich"
private-key nevyplňujeme – RouterOS ho vygeneruje automaticky při vytvoření rozhraní.mtu=1420 je výchozí a v naprosté většině případů správná hodnota (1500 − 20 IPv4 − 8 UDP − 32 WG hlavička + Poly1305 tag). Snižujeme jen při prokázané fragmentaci – viz kapitola 8.Zobrazení veřejného klíče serveru (potřebný jen při ručním psaní konfigurace na zařízení uživatele):
/interface/wireguard/print detail where name="wg-EUL"
⚠️ Kritické pro zálohy. Privátní klíč rozhraní je v RouterOS 7 označen jako sensitive a
/exportho standardně nevypisuje. Obnova routeru z.rscexportu proto WireGuard rozbije – interface se vytvoří s novým klíčem a nikomu nenaváže handshake.
- Pro DR vždy držet binární
/system/backup, ne jen.rsc.- Pokud chceme klíče i v textovém exportu:
/export show-sensitive file=...– takový soubor pak patří výhradně do trezoru hesel, ne do Gitu ani na sdílený disk.
/ip/address
add address=10.49.222.1/24 interface=wg-EUL comment="P2S VPN ElektroUldrich"
WireGuard poslouchá na UDP portu. Pravidlo musí být nad případnými drop pravidly v řetězci input.
/ip/firewall/filter
add chain=input action=accept protocol=udp dst-port=13240 \
in-interface=ether1-WAN comment="WG EUL - accept VPN"
Umístění zkontrolovat a případně přesunout:
/ip/firewall/filter/print chain=input
/ip/firewall/filter/move [find comment="WG EUL - accept VPN"] destination=0
Nespoléhat na to, že „to funguje i bez pravidla". Řetězec
inputnaKunDratkanemá závěrečnýdrop– jsou v něm jen cílené dropy (DNS a SSH z WAN), takže VPN naběhne i bez explicitního accept pravidla. V okamžiku, kdy se firewall uklidí, VPN tiše spadne. Pravidlo zakládáme vždy.
Toto je bezpečnostně nejdůležitější krok. WireGuard sám o sobě žádnou autorizaci nedělá – allowed-address u peeru je kryptografické směrování, ne firewall.
Řídíme se dvěma pravidly:
| Uživatelská VPN | Admin VPN | |
|---|---|---|
| Interface | wg-EUL |
wg-EUL-admin |
| Port | 13240 | 13241 |
| Rozsah | 10.49.222.0/24 |
10.49.223.0/24 |
| Klíče peerů | Metoda A – generuje router (KB-02) | Metoda B – generuje klient (KB-02) |
| Typický přístup | SMB, aplikace, doménové služby | RDP, WinBox, SSH, WinRM |
Oddělení rozhraním, ne jen adresním rozsahem, protože in-interface= je v pravidlech jednoznačné a nespoléhá na to, že někdo peeru přidělí správnou adresu.
Pokud ISP neforwarduje druhý UDP port a nejde to zařídit, lze oddělit i v rámci jednoho rozhraní podle
src-address– uživatelé10.49.222.0/25, admini10.49.222.128/25. Bezpečnostně je to rovnocenné: WireGuard zahodí paket, jehož zdrojová adresa není vallowed-addressdaného peeru, takžesrc-addressna WG rozhraní nelze podvrhnout. Horší je to jen na čitelnost a na to, že tunely nelze vypnout nezávisle.
/ip/firewall/address-list
add list=EUL-dns address=192.168.13.11 comment="dc01.eu.local - DNS pro VPN"
add list=EUL-dc address=192.168.13.11 comment="dc01.eu.local"
add list=EUL-app address=192.168.13.12 comment="app01.eu.local"
add list=EUL-files address=10.250.1.10 comment="NAS01"
add list=EUL-servers address=192.168.13.11 comment="dc01.eu.local"
add list=EUL-servers address=192.168.13.12 comment="app01.eu.local"
add list=EUL-mgmt address=192.168.55.2 comment="admin.elnet-group.cz"
add list=EUL-mgmt address=192.168.19.10 comment="dohled.elnet-group.cz"
add list=EUL-mgmt address=192.168.19.11 comment="zabbix.elnet-group.cz"
Pokud je v doméně druhý DC, přidat ho do
EUL-dns– klient pak přežije výpadek jednoho.
⚠️ Na
Kundratkauž existuje address-listEUservers(192.168.13.9–13, 192.168.15.x, 192.168.21.x). Před založenímEUL-serverszvážit, zda nepoužít ten stávající – dva podobně pojmenované seznamy se pletou. Pro uživatelskou VPN je aleEUserverspříliš široký.
Pravidla nepíšeme přímo do forward, ale do vlastního chainu na tunel, do kterého se z forward skočí. Přínos:
/ip/firewall/filter/print chain=wg-eul-userforwarddrop je uvnitř chainu, takže nemůže omylem shodit provoz, který s VPN nesouvisíKunDratka je to konzistentní s tím, co už dělá ispadmin (ispadmin_basic_forward a spol.)⚠️ Chain musí končit explicitním
drop. Paket, který v uživatelském chainu na nic nesedne, se vrátí doforwarda pokračuje dál – dokumentace popisujereturnjako „passes control back to the chain from where the jump took place", implicitní chování na konci chainu ale nespecifikuje. Nespoléhej na něj: závěrečnýdropuvnitř chainu tuhle nejistotu odstraní.
Základ hlavního forward řetězce – jednou, nad vším ostatním:
/ip/firewall/filter
add chain=forward action=accept connection-state=established,related,untracked \
comment="Navazujici provoz"
add chain=forward action=drop connection-state=invalid \
comment="Invalid drop"
Díky tomu se do politických chainů dostanou jen nová spojení a pravidla v nich řeší jedinou otázku: smí tohle spojení vzniknout?
/ip/firewall/filter
add chain=wg-eul-user action=accept protocol=udp \
dst-address-list=EUL-dns dst-port=53 comment="DNS na DC"
add chain=wg-eul-user action=accept protocol=tcp \
dst-address-list=EUL-dns dst-port=53 comment="DNS na DC"
add chain=wg-eul-user action=accept protocol=tcp \
dst-address-list=EUL-files dst-port=445 comment="SMB na NAS01"
add chain=wg-eul-user action=accept protocol=tcp \
dst-address-list=EUL-app dst-port=443 comment="app01 HTTPS"
add chain=wg-eul-user action=drop comment="zbytek drop"
RDP (3389) tu záměrně není. Uživatel ho k ničemu nepotřebuje a na DC nemá co dělat vůbec.
Notebook v doméně, který má přes VPN aplikovat GPO a ověřit se proti DC, potřebuje víc než SMB. Pokud zařízení jen přistupuje na sdílené disky a aplikaci, tato pravidla nezakládej.
/ip/firewall/filter
add chain=wg-eul-user action=accept protocol=tcp \
dst-address-list=EUL-dc dst-port=88,135,389,445,464,636 \
comment="DC TCP: kerberos, epmap, ldap, smb, kpasswd, ldaps" \
place-before=[find chain=wg-eul-user action=drop]
add chain=wg-eul-user action=accept protocol=udp \
dst-address-list=EUL-dc dst-port=88,123,389,464 \
comment="DC UDP: kerberos, ntp, ldap, kpasswd" \
place-before=[find chain=wg-eul-user action=drop]
add chain=wg-eul-user action=accept protocol=tcp \
dst-address-list=EUL-dc dst-port=49152-65535 \
comment="DC dynamicke RPC" \
place-before=[find chain=wg-eul-user action=drop]
⚠️ Poslední pravidlo otevírá 16 384 portů – to je cena za dynamické RPC ve Windows. Čistší řešení je přibít RPC na pevné porty na DC (
NTDS\TCP/IP PortaNetlogon\DCTcpipPortv registru) a povolit jen ty dva. Vyžaduje restart DC, takže samostatný ticket.
/interface/wireguard
add name=wg-EUL-admin listen-port=13241 mtu=1420 comment="P2S VPN ElektroUldrich - admin"
/ip/address
add address=10.49.223.1/24 interface=wg-EUL-admin comment="P2S VPN ElektroUldrich - admin"
/ip/firewall/filter
add chain=wg-eul-admin action=accept protocol=udp \
dst-address-list=EUL-dns dst-port=53 comment="DNS na DC"
add chain=wg-eul-admin action=accept protocol=tcp \
dst-address-list=EUL-dns dst-port=53 comment="DNS na DC"
add chain=wg-eul-admin action=accept protocol=tcp \
dst-address-list=EUL-servers dst-port=445,3389,5985,5986 \
comment="Servery: SMB, RDP, WinRM"
add chain=wg-eul-admin action=accept protocol=tcp \
dst-address-list=EUL-mgmt dst-port=22,443,8291 \
comment="Mgmt: SSH, HTTPS, WinBox"
add chain=wg-eul-admin action=drop comment="zbytek drop"
forward – až nakonecJumpy zakládáme až když jsou chainy hotové, aby neexistovalo okno, kdy provoz skáče do polovičně nastavené politiky:
/ip/firewall/filter
add chain=forward action=jump jump-target=wg-eul-user \
in-interface=wg-EUL connection-state=new \
comment="WG EUL user -> politika"
add chain=forward action=jump jump-target=wg-eul-admin \
in-interface=wg-EUL-admin connection-state=new \
comment="WG EUL admin -> politika"
input – co smí VPN z routeru samotnéhoDNS chodí na DC, tedy do forward (viz 4.4). V input zbývá jen správa routeru z admin tunelu:
/ip/firewall/filter
add chain=wg-eul-in action=drop \
comment="Uzivatelska VPN nema na routeru co delat"
add chain=wg-eul-admin-in action=accept protocol=tcp dst-port=22,8291 \
comment="Sprava routeru"
add chain=wg-eul-admin-in action=drop comment="zbytek drop"
add chain=input action=jump jump-target=wg-eul-in \
in-interface=wg-EUL comment="WG EUL user -> politika input"
add chain=input action=jump jump-target=wg-eul-admin-in \
in-interface=wg-EUL-admin comment="WG EUL admin -> politika input"
Správa routeru (22, 8291) je povolená jen z admin tunelu, z uživatelského nikdy.
Chain
wg-eul-inobsahuje jendropschválně – je to explicitní záznam toho, že uživatelská VPN nemá na router přístup, a platí i kdyby někdo odstranil závěrečnýdropzinput.
Tohle je hlavní důvod, proč se vyplatí chainy. Nová služba se vloží před závěrečný drop daného chainu a nikde jinde se nic neřeší:
/ip/firewall/filter
add chain=wg-eul-user action=accept protocol=tcp \
dst-address-list=EUL-app dst-port=1433 comment="SQL na app01" \
place-before=[find chain=wg-eul-user action=drop]
Kontrola celé politiky jedním příkazem:
/ip/firewall/filter/print chain=wg-eul-user
/ip/firewall/filter/print stats chain=wg-eul-user
Při prvním nasazení se skoro vždy na nějaký port zapomene. Na dobu zavádění zapnout logování na závěrečných drop pravidlech:
/ip/firewall/filter/set [find chain~"^wg-eul" && action=drop] log=yes log-prefix="WG-DROP:"
/log/print where message~"WG-DROP"
Po odladění vypnout – na produkčním routeru to jinak zaplní log:
/ip/firewall/filter/set [find chain~"^wg-eul" && action=drop] log=no
⚠️ Na
KunDratkaje v řetězciforwardjako druhé pravidloadd action=accept chain=forwardbez jakýchkoli podmínek. Dokud tam je, jumpy se k němu nedostanou a celá politika je bez efektu.
Výchozí volba: žádný NAT. Router je default gateway pro 10.250.1.0/24, 192.168.13.0/24 i 172.20.1.0/24, takže návratový provoz do 10.49.222.0/24 se routuje sám. Bez NATu:
Kdy NAT přesto potřebujeme:
| Situace | Řešení |
|---|---|
| Cílová síť má jiný default gateway než MikroTik | masquerade omezený na out-interface dané sítě |
| Windows Firewall na serverech blokuje cizí subnet | Správně: přidat 10.49.222.0/24 do rozsahů pravidel GPO. Nouzově: NAT |
| Full-tunnel (veškerý provoz uživatele přes VPN) | masquerade s out-interface=ether1-WAN |
# Full-tunnel - NAT pouze pro provoz ven do internetu
/ip/firewall/nat
add chain=srcnat action=masquerade src-address=10.49.222.0/24 \
out-interface=ether1-WAN comment="WG EUL - full tunnel do internetu"
❌ Antipattern:
add chain=srcnat action=masquerade src-address=10.49.222.0/24bezout-interface– přesně to je dnes naKunDratkanasazené. Maskaruje i provoz do vnitřních sítí, takže nadc01aapp01se všichni VPN uživatelé jeví jako router. Ztrácí se auditovatelnost, nefunguje filtrace podle zdroje ani zpětná spojení.
DNS serverem pro VPN klienty jsou doménové řadiče, ne router. Klient tak dostane stejné rozlišování jmen jako v kanceláři, včetně SRV záznamů pro doménové služby a DNS integrovaného s AD. Na KunDratka je to zároveň konzistentní s LAN – DHCP pro 10.250.1.0/24 už dnes rozdává dns-server=192.168.13.11.
Přidělení se nastavuje per peer parametrem client-dns – viz KB-02. Na routeru stačí povolit provoz, což řeší politika z kroku 4:
/ip/firewall/filter/print chain=wg-eul-user
Tři důsledky, které se snadno přehlédnou:
1. Síť DC musí být v client-allowed-address. Bez 192.168.13.0/24 klient na DNS nedosáhne a nefunguje mu vůbec nic – i kdyby ostatní služby povolené měl.
2. Jména, která existují jen na routeru, přestanou fungovat. /ip/dns/static na KunDratka drží admin.elnet-group.cz, zabbix.elnet-group.cz a dohled.elnet-group.cz. To jsou záznamy v doméně elnet-group.cz, ne eu.local – DC je nezná. Před nasazením ověřit a založit odpovídající záznamy na DC:
/ip/dns/static/print
3. Router jako resolver už VPN klienti nepotřebují. Jestli allow-remote-requests=yes potřebuje ještě něco jiného, je samostatná otázka – DHCP pro 10.250.1.0/24 rozdává DC a pro 172.20.1.0/24 veřejné resolvery, takže je možné, že už ne. Ověřit dřív, než to někdo vypne.
Drop pravidla na port 53 z WAN platí bez ohledu na to:
⚠️
allow-remote-requests=yesna routeru s veřejnou IP znamená otevřený rekurzivní resolver, pokud není port 53 blokován z internetu. NaKunDratkadrop pravidla existují pro TCP i UDP – při změnách firewallu je nesmí nikdo odstranit:/ip/firewall/filter add chain=input action=drop protocol=udp dst-port=53 in-interface=ether1-WAN comment="BLOCK DNS udp" add chain=input action=drop protocol=tcp dst-port=53 in-interface=ether1-WAN comment="BLOCK DNS tcp"Externí kontrola:
dig @185.112.166.175 google.comz internetu nesmí vrátit odpověď.
Šablona pro zřízení dalšího WireGuard rozhraní na tomto routeru. Nahradit <> hodnotami podle evidence. Struktura odpovídá kroku 4 – politika ve vlastním chainu, povolené porty, DNS na doménovém řadiči.
# --- 1. Rozhrani ---
/interface/wireguard
add name=wg-<ZKRATKA> listen-port=<PORT> mtu=1420 comment="P2S VPN <popis>"
# --- 2. Adresa tunelu ---
/ip/address
add address=10.49.<X>.1/24 interface=wg-<ZKRATKA> comment="P2S VPN <popis>"
# --- 3. Dostupnost VPN zvenci ---
/ip/firewall/filter
add chain=input action=accept protocol=udp dst-port=<PORT> in-interface=ether1-WAN \
comment="WG <ZKRATKA> - accept VPN" place-before=0
# --- 4. Skupiny cilu ---
/ip/firewall/address-list
add list=<ZKRATKA>-dns address=<IP-DC> comment="DNS pro VPN"
add list=<ZKRATKA>-files address=<IP-cile> comment="<popis>"
# --- 5. Zaklad retezce forward (jen pokud jeste neexistuje) ---
/ip/firewall/filter
add chain=forward action=accept connection-state=established,related,untracked \
comment="Navazujici provoz"
add chain=forward action=drop connection-state=invalid comment="Invalid drop"
# --- 6. Politika tunelu ve vlastnim chainu ---
/ip/firewall/filter
add chain=wg-<zkratka>-user action=accept protocol=udp \
dst-address-list=<ZKRATKA>-dns dst-port=53 comment="DNS na DC"
add chain=wg-<zkratka>-user action=accept protocol=tcp \
dst-address-list=<ZKRATKA>-dns dst-port=53 comment="DNS na DC"
add chain=wg-<zkratka>-user action=accept protocol=tcp \
dst-address-list=<ZKRATKA>-files dst-port=445 comment="SMB"
add chain=wg-<zkratka>-user action=drop comment="zbytek drop"
# --- 7. Politika pro input ---
add chain=wg-<zkratka>-in action=drop \
comment="Uzivatelska VPN nema na routeru co delat"
# --- 8. Napojeni - az kdyz jsou chainy hotove ---
add chain=forward action=jump jump-target=wg-<zkratka>-user \
in-interface=wg-<ZKRATKA> connection-state=new \
comment="WG <ZKRATKA> user -> politika"
add chain=input action=jump jump-target=wg-<zkratka>-in \
in-interface=wg-<ZKRATKA> comment="WG <ZKRATKA> user -> politika input"
DNS pro klienty se na routeru nenastavuje – přiděluje se per peer parametrem client-dns, který ukazuje na doménový řadič. Viz KB-02 a krok 6.
Peer se zakládá podle KB-02.
# Rozhrani bezi a ma klic
/interface/wireguard/print detail
# Adresa je prirazena
/ip/address/print where interface=wg-EUL
# Port posloucha
/tool/sniffer/quick interface=ether1-WAN port=13240
# Firewall pravidlo se trefuje (po pokusu o pripojeni)
/ip/firewall/filter/print stats where comment~"WG EUL"
Po připojení prvního zařízení (viz KB-02):
/interface/wireguard/peers/print detail
Kontrolujeme:
last-handshake – musí být < 180 s, ideálně desítky sekundcurrent-endpoint-address – veřejná IP uživatelerx i tx rostou; jednostranný růst = problém s routingem nebo firewallem zpětpreshared-key=auto (viz KB-02) – dodatečná symetrická vrstva nad ChaCha20-Poly1305drop; v forward není žádné obecné accept nad jumpyEUL-dns (DC) a client-dns u peerů ukazuje na DC, ne na routeradmin.elnet-group.cz a spol.) mají odpovídající záznam na DCinput řetězec má explicitní accept na UDP port VPN a závěrečný dropmasquerade pro tunelový rozsah je odstraněn nebo omezen out-interface/system/backup pořízený po vytvoření WG rozhraní| Příznak | Pravděpodobná příčina | Řešení |
|---|---|---|
Žádný handshake, last-handshake prázdné |
Port není dostupný zvenčí | Test nc -vzu 185.112.166.175 13240 z internetu; ověřit accept pravidlo v input; ověřit, že ISP forwarduje UDP port na 10.32.39.71 |
Handshake OK, rx roste, tx ne |
Provoz se nevrací | Chybí routa zpět na cílovém serveru (jiný default gw) nebo Windows Firewall blokuje cizí subnet |
| Handshake OK, ale provoz je blokován | forward drop |
/ip/firewall/filter/print stats chain=forward – najít pravidlo, které počítá pakety |
| Funguje ping, nefunguje RDP/SMB/HTTPS | Fragmentace – MTU | Otestovat ping <cil> size=1400 do-not-fragment, snižovat po 20 B; při nálezu nastavit mtu na rozhraní a přidat MSS clamp (níže) |
| Tunel padá po pár minutách nečinnosti | Zařízení je za NATem bez keepalive | Nastavit client-keepalive=25s u peeru (KB-02) |
| Zařízení se připojí, ale nerozlišuje interní jména | Chybí client-dns, nebo klient nedosáhne na DC |
Ověřit client-dns u peeru, že 192.168.13.0/24 je v client-allowed-address a že politika pouští 53/udp i tcp na EUL-dns. Test z klienta: nslookup dc01.eu.local 192.168.13.11 |
Doménová jména jdou, ale admin.elnet-group.cz ne |
Záznam existuje jen ve statickém DNS na routeru | DC doménu elnet-group.cz nezná – založit záznam na DC |
| Rozlišování jmen je nespolehlivé (někdy ano, někdy ne) | Split tunnel na Windows – dotazy jdou i na DNS jiného adaptéru | Ověřit Get-DnsClientServerAddress a pořadí adaptérů; u zařízení v doméně zvážit NRPT pravidlo pro doménový suffix |
| Handshake funguje jen chvíli po restartu peeru | Peer nemá responder=yes |
Router se opakovaně pokouší sám iniciovat spojení k endpoint-address. U P2S peerů vždy responder=yes |
MSS clamp při prokázané fragmentaci:
/ip/firewall/mangle
add chain=forward action=change-mss new-mss=clamp-to-pmtu protocol=tcp \
tcp-flags=syn out-interface=wg-EUL comment="WG EUL - MSS clamp"
Logování handshaků pro diagnostiku (dočasně):
/system/logging/add topics=wireguard action=memory
/log/print where topics~"wireguard"