MikroTik
Κλιμακωση Site-to-Site (Hub-and-Spoke)

Η Cisco έχει DMVPN για WANs με πολλά branches. Το RouterOS δεν έχει — και το να προσποιείσαι αλλιώς σου χαλάει ένα απόγευμα. Αυτή είναι η ειλικρινής απάντηση του MikroTik: ένα WireGuard hub-and-spoke που κλιμακώνεται σε πολλά sites, κάνει route δυναμικά, και όπου κάθε branch είναι ένα copy-paste — συν μια ξεκάθαρη ματιά σε τι χάνεις έναντι του on-demand spoke-to-spoke του DMVPN.

MikroTik RouterOS WireGuard Hub-and-Spoke WAN VPN

Πρώτα, το ειλικρινές κομμάτι: το RouterOS δεν έχει DMVPN. Δεν υπάρχει mGRE, δεν υπάρχει NHRP, δεν υπάρχει δυναμική επίλυση tunnel spoke-to-spoke. Οπότε όταν κάποιος ζητάει "DMVPN σε MikroTik," η πραγματική ερώτηση είναι "πώς συνδέω πολλά branches χωρίς να κάνω mesh τα tunnels με το χέρι;" — και η καλύτερη σύγχρονη απάντηση είναι ένα WireGuard hub-and-spoke: κάθε spoke κρατά ένα μόνο tunnel προς το hub, το hub ξέρει όλα τα LANs, και ένα πρωτόκολλο routing πάνω από το overlay κάνει τα υπόλοιπα. Είναι απλό, γρήγορο, φιλικό προς NAT, και κάθε νέο site είναι ένα peer στο hub συν ένα config που δείχνει στο hub στο spoke.

Τι θυσιάζεις έναντι του Cisco DMVPN: δεν υπάρχει αυτόματο απευθείας path spoke-to-spoke. Η κίνηση branch-προς-branch κάνει hairpin μέσω του hub εκτός αν σκόπιμα προσθέσεις peers spoke (μερικό ή πλήρες mesh). Για τα περισσότερα estates αυτή είναι μια εντάξει ανταλλαγή — το hub είναι έτσι κι αλλιώς κεντρικό και καλά συνδεδεμένο. Αυτή είναι η καταχώρηση RouterOS στο pattern που χαρτογραφεί ο οδηγός μετάφρασης.

Προαπαιτουμενα

Τα βασικά δύο-sites — WireGuard VPN (κλειδιά, peers, λογική allowed-address)
Ένα hub με προσβάσιμη public IP· τα spokes μπορεί να είναι πίσω από dynamic IP / NAT
Ένα σχέδιο routing πάνω από το overlay — OSPF ή static routes

Το Hub — Ενα Interface, ενα Peer ανα Spoke

Ένα μοναδικό interface WireGuard στο hub, ένα subnet overlay, και μία καταχώρηση peer ανά branch. Το hub είναι η μόνη συσκευή που μεγαλώνει καθώς προσθέτεις sites — μία γραμμή η καθεμία.

RouterOS 7 (HUB) — interface wg + ενα peer ανα spoke

/interface wireguard add name=wg-hub listen-port=13231
/ip address add address=172.16.0.1/24 interface=wg-hub   # overlay

# Ένα peer ανά spoke. allowed-address = το /32 overlay του spoke + το LAN του,
# ώστε το hub να κάνει route σωστά προς εκείνο το spoke. Δεν χρειάζεται endpoint στο
# hub αν τα spokes έχουν dynamic IPs — συνδέονται αυτά προς τα μέσα.
/interface wireguard peers
add interface=wg-hub public-key="<spokeA-pub>" \
    allowed-address=172.16.0.11/32,10.10.0.0/24 comment="Branch-A"
add interface=wg-hub public-key="<spokeB-pub>" \
    allowed-address=172.16.0.12/32,10.20.0.0/24 comment="Branch-B"

⚠ Παγιδα — Το allowed-address Ειναι Routing, Οχι Filter

Η μεγαλύτερη σύγχυση του WireGuard, και δαγκώνει πιο σκληρά σε hub-and-spoke. Το allowed-address σε ένα peer κάνει δύο πράγματα: αποφασίζει ποιες source IPs γίνονται δεκτές από αυτό το peer, και — κρίσιμο — είναι ο πίνακας cryptokey routing που αποφασίζει ποιοι προορισμοί στέλνονται σε αυτό το peer. Στο hub, κάθε peer spoke πρέπει να λιστάρει το LAN εκείνου του spoke ώστε το hub να στέλνει κίνηση branch στο σωστό tunnel. Επικάλυψε τα allowed-addresses δύο peers και η κίνηση πάει σε όποιο διαλέξει το WireGuard — μια σιωπηλή μαύρη τρύπα. Κράτα τα ξεχωριστά και συγκεκριμένα.

Ενα Spoke — Δειξε προς το Hub

Κάθε spoke έχει ένα peer: το hub. Το allowed-address του καλύπτει το overlay και κάθε άλλο LAN που πρέπει να φτάσει — που, σε καθαρό hub-and-spoke, το φτάνει μέσω του hub.

RouterOS 7 (SPOKE-A) — ενα μοναδικο peer προς το hub

/interface wireguard add name=wg-spoke listen-port=13231
/ip address add address=172.16.0.11/24 interface=wg-spoke

# Ένα peer: το hub. allowed-address = overlay + όλα τα απομακρυσμένα LANs προσβάσιμα
# μέσω αυτού. Το persistent-keepalive τρυπάει το NAT του spoke.
/interface wireguard peers
add interface=wg-spoke public-key="<hub-pub>" \
    endpoint-address=203.0.113.1 endpoint-port=13231 \
    allowed-address=172.16.0.0/24,10.20.0.0/24,10.30.0.0/24 \
    persistent-keepalive=25s
# Για να φτάσει το Branch-B (10.20.0.0/24), η κίνηση ταξιδεύει σε αυτό το tunnel προς το hub,
# που το προωθεί κάτω στο tunnel του Branch-B. Hairpin — αλλά απλό και ανθεκτικό.

Κανε Route το Overlay — Το OSPF Νικα τις Static Λιστες

Το να λιστάρεις κάθε απομακρυσμένο LAN στο allowed-address κάθε spoke γίνεται γρήγορα δυσκίνητο. Τρέξε OSPF πάνω από το overlay και κάθε site μαθαίνει τα άλλα αυτόματα — πρόσθεσε ένα branch και το subnet του διαδίδεται χωρίς να επεξεργαστείς τα υπόλοιπα.

RouterOS 7 — OSPF πανω απο το overlay WireGuard

# Τρέξε OSPF στα interfaces wg ώστε τα LANs να μαθαίνονται, όχι να λιστάρονται με το χέρι.
# ΣΗΜΕΙΩΣΗ: ακόμα χρειάζεσαι allowed-address για να επιτρέψεις την κίνηση — χρησιμοποίησε ένα ευρύ
# overlay + summarised block LAN ανά spoke, και άσε το OSPF να διαλέξει paths μέσα σε αυτό.
/routing ospf instance add name=v7 router-id=172.16.0.11
/routing ospf area add name=backbone area-id=0.0.0.0 instance=v7
/routing ospf interface-template
add interfaces=wg-spoke area=backbone network-type=ptmp cost=10
# Το ptmp (point-to-multipoint) ταιριάζει σε ένα hub με πολλά spokes σε ένα subnet.

💡 Θες Απευθειας Spoke-to-Spoke; Προσθεσε τα Peers

Αν δύο branches ανταλλάσσουν βαριά κίνηση και το hairpin πονάει, το WireGuard κάνει ένα απευθείας path τετριμμένο — πρόσθεσε το ένα το άλλο σαν peer και στα δύο spokes (η overlay IP τους + το LAN, και ένα endpoint αν έχουν και τα δύο public IPs). Αυτό είναι μια χειροκίνητη ακμή mesh, όχι το αυτόματο on-demand tunnel του DMVPN, αλλά είναι μια διόρθωση δύο γραμμών για τα συγκεκριμένα ζευγάρια που το χρειάζονται. Για sites πίσω από NAT χωρίς public IP, το απευθείας spoke-to-spoke δεν είναι αξιόπιστα δυνατό χωρίς relay — και ακριβώς γι' αυτό το μοντέλο hub είναι το λογικό default. Σωστό εργαλείο, ειλικρινή όρια.

Επαληθευση Ασφαλες να Τρεξεις

Επιβεβαίωσε handshakes σε κάθε peer, τα routes overlay που μαθεύτηκαν, και end-to-end προσβασιμότητα με πηγή από ένα LAN.

RouterOS 7 — το περπατημα υγειας

/interface wireguard peers print   # last-handshake πρόσφατο σε κάθε peer
/routing ospf neighbor print       # spokes adjacent στο hub
/ip route print where ospf          # απομακρυσμένα LANs μαθευμένα μέσω του overlay
/ping 10.20.0.1 src-address=10.10.0.1  # LAN branch A -> LAN branch B

Συμπτωμα	Που να κοιταξεις
Χωρίς handshake	Λάθος public key / endpoint, ή μπλοκαρισμένο UDP 13231. Έλεγξε τα κλειδιά και των δύο peers.
Handshake up, χωρίς κίνηση	Το allowed-address δεν καλύπτει το LAN προορισμού (cryptokey routing).
Το branch-to-branch αποτυγχάνει	Το hub δεν κάνει forward — λείπει το LAN του spoke στο peer του hub, ή δεν υπάρχει route.
Το spoke πίσω από NAT πέφτει	Πρόσθεσε `persistent-keepalive` ώστε το mapping του NAT να μένει ανοιχτό.

Βασικα Συμπερασματα

Το RouterOS δεν έχει DMVPN — χωρίς mGRE/NHRP. Μην το κυνηγάς· χτίσε αντ' αυτού ένα WireGuard hub-and-spoke.
Το hub μεγαλώνει ένα peer ανά spoke· κάθε spoke έχει ένα peer (το hub). Η προσθήκη branch είναι copy-paste.
Το allowed-address είναι cryptokey routing, όχι filter — στο hub πρέπει να λιστάρει το LAN κάθε spoke, κρατημένο ξεχωριστό, αλλιώς η κίνηση χάνεται σε μαύρες τρύπες.
Τρέξε OSPF πάνω από το overlay ώστε τα LANs να μαθαίνονται, όχι να λιστάρονται με το χέρι σε κάθε config.
Το branch-to-branch κάνει hairpin μέσω του hub by default — η ανταλλαγή του DMVPN. Πρόσθεσε απευθείας peers για τα συγκεκριμένα ζευγάρια που το χρειάζονται.
Το persistent-keepalive κρατά τα spokes πίσω από NAT προσβάσιμα.

Συνδεεις δωδεκα sites και πνιγεσαι σε μεμονωμενα tunnels;

Χτίζω WANs hub-and-spoke με overlays WireGuard σε MikroTik και Cisco όπου το routing προσαρμόζεται δυναμικά, ένα νέο branch είναι κοντά σε μια προσθήκη δύο γραμμών, και το failover δεν χρειάζεται κανέναν να το παρακολουθεί.

Κλεισε μια Discovery Call →