English · Ελληνικά
Κράτα ένα απομακρυσμένο site online όταν το Starlink κάνει blip — recursive routing, connection marking, NAT, και netwatch failover σε RouterOS v7.
Το Starlink είναι η καλύτερη επιλογή συνδεσιμότητας για μια αγροτική βίλα, φάρμα, ή worksite που το σταθερό broadband ποτέ δεν έφτασε — αλλά δεν είναι αλάνθαστο. Εμπόδια, satellite hand-offs, συμφόρηση, και το περιστασιακό firmware reboot όλα παράγουν σύντομες διακοπές. Για έναν ξενώνα εν μέσω κράτησης ή μια επιχείρηση που δέχεται πληρωμές με κάρτα, ακόμα και δέκα δευτερόλεπτα offline είναι πρόβλημα. Η λύση είναι ένα δεύτερο WAN — 4G/LTE, DSL, ή ακόμα και δεύτερο Starlink — και ένα router που αλλάζει τη στιγμή που πεθαίνει το πρωτεύον μονοπάτι, και επανέρχεται όταν αυτό ανακάμψει.
Αυτό είναι ακριβώς το κομμάτι που ξεχωρίζει μια καθαρή εγκατάσταση MikroTik από ένα πιάτο βιδωμένο σε έναν τοίχο. Θα χτίσουμε distance-based recursive failover (που εντοπίζει ένα νεκρό μονοπάτι internet, όχι απλά ένα ζωντανό καλώδιο), connection marking και NAT ανά WAN ώστε η κίνηση να φεύγει από το σωστό interface, MSS clamping για το δευτερεύον link, και έναν έλεγχο υγείας netwatch που καταγράφει και μπορεί να κάνει alert σε κάθε αλλαγή.
01
Το πιάτο αναφέρει «online» ενώ το satellite path έχει ήδη φύγει — που είναι ακριβώς ο λόγος που το αφελές failover αποτυγχάνει.
Το Starlink παραδίδει μια ισχυρή σύνδεση, αλλά το προφίλ διαθεσιμότητάς του είναι διαφορετικό από μια σταθερή γραμμή. Σύντομες διακοπές συμβαίνουν κατά τα satellite hand-off, όταν ένα εμπόδιο κόβει το οπτικό πεδίο, κατά τη συμφόρηση, και σε firmware reboots. Το link Ethernet ανάμεσα στο πιάτο και το router σου παραμένει up στις περισσότερες από αυτές — το καλώδιο είναι εντάξει, το gateway ακόμα απαντάει σε ping — αλλά καμία κίνηση δεν φτάνει το ευρύτερο internet. Οποιοδήποτε σχήμα failover που παρακολουθεί μόνο την κατάσταση link ή κάνει ping το επόμενο hop θα κάθεται ευτυχώς πάνω σε μια νεκρή σύνδεση.
Το Starlink σε βάζει επίσης πίσω από CGNAT: παίρνεις μια διεύθυνση 100.64.0.0/10, όχι δημόσια IP. Αυτό σημαίνει καθόλου inbound port-forwarding και κανένα κλασικό VPN endpoint στην πλευρά του Starlink — ένας περιορισμός γύρω από τον οποίο σχεδιάζουμε, όχι εναντίον του.
02
Δύο WAN σε ένα router, και τα δύο μέσω DHCP, με τη διαχείριση default-route αφαιρεμένη από τον DHCP client ώστε να ελέγχουμε εμείς το failover.
Βάλε το Starlink στο ether1 και τη δευτερεύουσα γραμμή στο ether2. Ομαδοποίησέ τα σε μια λίστα interface WAN ώστε οι κανόνες firewall και mangle να μπορούν να αναφέρονται και στα δύο ταυτόχρονα. Το κρίσιμο, πες σε κάθε DHCP client να μην εγκαταστήσει τη δική του default route — προσθέτουμε recursive routes με το χέρι στην επόμενη ενότητα.
[admin@edge] > /interface ethernet set [find default-name=ether1] name=ether1-starlink /interface ethernet set [find default-name=ether2] name=ether2-lte /interface list add name=WAN /interface list member add list=WAN interface=ether1-starlink /interface list member add list=WAN interface=ether2-lte /ip dhcp-client add interface=ether1-starlink add-default-route=no use-peer-dns=no /ip dhcp-client add interface=ether2-lte add-default-route=no use-peer-dns=no # add-default-route=no είναι το κλειδί: διαχειριζόμαστε τις default routes # με το χέρι ώστε το recursive failover να αναλάβει την απόφαση.
03
Κάνε probe μια πραγματική δημόσια IP μέσα από κάθε WAN. Η default route κάνει recurse μέσα από αυτό το probe — χάσε το path, χάσε τη route.
Το κόλπο που κάνει το failover του Starlink αξιόπιστο είναι το recursive routing. Προσθέτουμε μια route /32 σε μια δημόσια διεύθυνση δοκιμής (ας πούμε 8.8.8.8) που είναι προσβάσιμη μόνο μέσω του gateway του Starlink, μετά προσθέτουμε μια default route της οποίας το gateway είναι το ίδιο το 8.8.8.8. Το RouterOS επιλύει τη default route recursively μέσα από το probe· αν το path του Starlink προς το 8.8.8.8 πεθάνει, η route του probe γίνεται inactive, η default route απενεργοποιείται, και η route χαμηλότερης προτεραιότητας μέσω του δευτερεύοντος WAN αναλαμβάνει. Επειδή το probe είναι πραγματικός internet host, αυτό πιάνει την περίπτωση «πιάτο up, internet down» που νικάει το check-gateway στο τοπικό gateway.
[admin@edge] > /ip route add dst-address=8.8.8.8/32 gateway=100.64.0.1 scope=10 \ comment="probe-starlink" /ip route add dst-address=1.1.1.1/32 gateway=192.168.8.1 scope=10 \ comment="probe-lte" /ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 target-scope=10 \ comment="primary: Starlink" /ip route add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=2 target-scope=10 \ comment="backup: LTE" # Το 100.64.0.1 είναι το συνηθισμένο gateway (CGNAT) του Starlink· το 192.168.8.1 είναι # τυπικό gateway modem LTE. Επιβεβαίωσε το δικό σου με: /ip dhcp-client print
Και τα δύο gateway WAN έρχονται μέσω DHCP και μπορούν να αλλάξουν. Το hard-coding τους όπως παραπάνω δουλεύει στην πράξη (το gateway CGNAT του Starlink είναι σταθερό), αλλά το ανθεκτικό pattern είναι να διαβάζεις το gateway από το DHCP lease σε ένα script και να ενημερώνεις τη route probe, ή να χρησιμοποιείς έναν μικρό scheduler που το καρφώνει ξανά σε κάθε lease renewal. Τουλάχιστον, έλεγξέ το ξανά μετά από κάθε αλλαγή ISP.
Δεν μπορείς να κάνεις port-forward μέσα σε ένα site Starlink. Για απομακρυσμένη διαχείριση (Winbox, SSH, ή αφύπνιση ενός server), τερμάτισε ένα tunnel WireGuard ή Tailscale από μέσα στο LAN προς τα έξω — τρυπάει μέσα από το CGNAT και σου δίνει μια σταθερή διεύθυνση ανεξάρτητα από ποιο WAN είναι ενεργό. Δες το συνοδευτικό Wake-on-LAN writeup για το pattern Tailscale-over-CGNAT.
04
Σημείωσε σε ποιο WAN ανήκει μια σύνδεση, και κάνε masquerade έξω από όποιο interface είναι αυτή τη στιγμή ενεργό.
Με δύο WAN χρειάζεσαι source NAT και στα δύο, και — για κάθε σύνδεση που ξεκινάει από έξω ή είναι καρφωμένη σε ένα WAN — ένα connection mark ώστε οι απαντήσεις να φεύγουν από το ίδιο interface που μπήκαν. Για ένα site Starlink με CGNAT η περισσότερη κίνηση είναι outbound, οπότε τα βασικά κομμάτια είναι ένας κανόνας masquerade ανά WAN συν ένα MSS clamp για να αποφευχθούν black-holed μεγάλα πακέτα στο path LTE/PPPoE.
[admin@edge] > /ip firewall nat add chain=srcnat out-interface=ether1-starlink action=masquerade /ip firewall nat add chain=srcnat out-interface=ether2-lte action=masquerade /ip firewall mangle add chain=prerouting in-interface-list=WAN \ connection-mark=no-mark action=mark-connection new-connection-mark=from-wan /ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn \ action=change-mss new-mss=clamp-to-pmtu out-interface-list=WAN # Το MSS clamping αποτρέπει κολλημένα sessions TCP σε links που δεν μπορούν να κουβαλήσουν # frames 1500-byte — συνηθισμένο σε backups LTE και PPPoE.
05
Το recursive routing χειρίζεται την αλλαγή σιωπηλά — το netwatch το κάνει ορατό και σου επιτρέπει να κάνεις alert σε κάθε μετάβαση.
Το failover παραπάνω είναι αυτόματο, αλλά θέλεις να ξέρεις πότε συμβαίνει — ένα site που ζει στο backup LTE του για τρεις μέρες καίει ένα data cap. Το /tool netwatch κάνει ενεργά probe έναν host και τρέχει scripts σε αλλαγή κατάστασης. Δείξ' το στην ίδια δημόσια IP που χρησιμοποιεί το πρωτεύον path σου και κατέγραψε και τις δύο κατευθύνσεις· συνδύασέ το με ειδοποίηση Telegram ή email για οτιδήποτε διαχειρίζεσαι από απόσταση.
[admin@edge] > /tool netwatch add host=8.8.8.8 type=icmp interval=10s timeout=1s \ up-script="/log info \"WAN: Starlink path UP\"" \ down-script="/log warning \"WAN: Starlink DOWN — τρέχει σε LTE backup\"" # Προώθησε logs σε έναν server syslog και κάνε alert στη γραμμή 'DOWN' ώστε ένα # σιωπηλό multi-day failover να μη σου κοστίσει ποτέ υπέρβαση LTE.
06
Το failover αποκαθιστά τη διαθεσιμότητα, όχι την ασφάλεια. Το backup WAN είναι μια δεύτερη μπροστινή πόρτα — αντιμετώπισέ το σαν τέτοια.
Είναι εύκολο να κάνεις hardening το interface του Starlink και να ξεχάσεις το modem LTE που κουβαλάει κίνηση μόνο λίγες ώρες τον μήνα. Εφάρμοσε input filtering σε ολόκληρη τη λίστα interface WAN, όχι σε ένα μεμονωμένο interface, ώστε ένα νέο ή backup WAN να κληρονομεί την πολιτική αυτόματα.
[admin@edge] > /ip firewall filter add chain=input connection-state=established,related action=accept /ip firewall filter add chain=input connection-state=invalid action=drop /ip firewall filter add chain=input in-interface-list=WAN action=drop \ comment="drop everything else sourced from any WAN" # Φτάσε το router για διαχείριση μέσα από το tunnel WireGuard/Tailscale σου # ή το LAN — ποτέ εκθέτοντας Winbox/SSH/API σε interface WAN.
Το να είσαι πίσω από το CGNAT του Starlink σε κρύβει από περιστασιακά inbound scans, αλλά τη στιγμή που κάνεις failover σε μια γραμμή LTE/DSL με δημόσια IP, αυτή η ασπίδα χάνεται. Το firewall παραπάνω πρέπει να στέκεται μόνο του — μην βασίζεσαι στο CGNAT για προστασία, γιατί το backup path σου μπορεί να μην το έχει.
Βασικα Συμπερασματα
8.8.8.8 εντοπίζει ένα νεκρό internet path· το check-gateway=ping στο τοπικό gateway δεν πιάνει την αποτυχία «πιάτο up, link down» του Starlink.add-default-route=no και στα δύο WAN αφήνει τις distance-based recursive routes να κατέχουν την απόφαση failover.WAN κρατάνε και τα δύο paths χρησιμοποιήσιμα χωρίς κολλημένα sessions σε LTE/PPPoE.WAN προστατεύει κάθε WAN· το firewall πρέπει να κρατάει μόνο του γιατί το backup με δημόσια IP δεν έχει ασπίδα CGNAT.Εγκαθιστώ Starlink και το καλωδιώνω σε ένα σωστό δίκτυο MikroTik από πίσω — multi-WAN failover, VLANs, VPN, απομακρυσμένο monitoring — ώστε μια απομακρυσμένη βίλα, φάρμα, ή επιχείρηση να μένει online, όχι απλά συνδεδεμένη σε ένα πιάτο στη στέγη.
Δες εγκατασταση Starlink & διαχειριζομενη συνδεσιμοτητα →