Τριμηνιαίο drill failover

Ολόκληρος ο λόγος ύπαρξης ενός dual-provider HA setup είναι ότι το failover λειτουργεί όταν η κύρια uplink πέφτει στα αλήθεια. Ο μόνος τρόπος να έχεις εμπιστοσύνη σε αυτό είναι να το δοκιμάσεις σκόπιμα.

Προτεινόμενη συχνότητα: κάθε τρίμηνο, σε χαμηλή χρονική παράθυρο, με τον operator στην κονσόλα.

Διαδικασία:

  1. Ανακοίνωση του drill στο κανάλι ομάδας — το failover πρέπει να είναι αόρατο, αλλά αν κάτι πάει στραβά, θέλεις να το μάθεις αμέσως.
  2. Απενεργοποίηση της κύριας uplink σε επίπεδο interface (όχι στο modem του παρόχου — αυτό προσομοιώνει λάθος failure mode).
  3. Μέσα σε πέντε δευτερόλεπτα, ο monitor failover πρέπει να στρέψει τη default route στη δευτερεύουσα uplink.
  4. Επαλήθευση εξωτερικής προσβασιμότητας: ένα αίτημα από εσωτερική ζώνη πρέπει ακόμα να αναλύεται, να φέρνει και να επιστρέφει.
  5. Επανενεργοποίηση της κύριας uplink.
  6. Ο monitor πρέπει να επαναφέρει τη default route πίσω στην κύρια εντός του διαμορφωμένου intervals.
  7. Καταγραφή του drill σε logbook: ημερομηνία, time-to-detect, time-to-recover, οτιδήποτε ασυνήθιστο.

Αν το failover πάρει περισσότερο χρόνο από το αναμενόμενο, το check interval ή τα κατώφλια του monitor χρειάζονται tuning. Αν το failover δεν συμβεί καθόλου, η config του monitor είναι χαλασμένη — διόρθωσέ την πριν πας σπίτι. Ένας μη λειτουργικός monitor failover είναι χειρότερος από κανέναν monitor· δίνει στον operator ψεύτικη σιγουριά.

Αναθεώρηση logs

Τρία ρεύματα logs μετράνε:

  • Firewall events. Αποφάσεις drop, προσθήκες σε πίνακες, NAT state. Θορυβώδη κατά τα scan reconnaissance, ήσυχα σε κανονικό φόρτο.
  • SSL offloading events. Σφάλματα termination, αποτυχίες validation πιστοποιητικών, ετυμηγορίες scanner. Spikes εδώ σημαίνουν ότι κάτι άλλαξε — rotation πιστοποιητικού upstream, νέος client που δεν εμπιστεύεται το εσωτερικό CA root, ή ένα pattern malware που γλίστρησε από φίλτρο.
  • Failover-monitor events. Μεταβάσεις link. Πρέπει να είναι άδεια τις περισσότερες εβδομάδες. Συχνές μεταβάσεις δείχνουν uplink που τραντάζεται — ανέφερέ το στον carrier.

Προτεινόμενη συνήθεια operator: ένα εβδομαδιαίο σκανάρισμα δεκαπέντε λεπτών σε αυτά τα τρία ρεύματα. Σήμαινε οτιδήποτε ασυνήθιστο, άνοιξε follow-up tickets για το επόμενο τριμηνιαίο review.

Επαλήθευση ορίων ζωνών

Οι ζώνες ορίζονται στο ruleset. Το ruleset μπορεί να είναι λάθος. Ο μόνος τρόπος να ξέρεις ποιο ισχύει είναι να δοκιμάσεις.

Προτεινόμενη συχνότητα: κάθε έξι μήνες, ή μετά από οποιαδήποτε σημαντική αλλαγή ruleset.

Για κάθε ζευγάρι ζωνών (Clients ↔ DMZ, Clients ↔ VPN, Ανωνυμοποίηση ↔ όλα τα άλλα, κλπ.):

  1. Από έναν host στη ζώνη Α, προσπάθησε να προσεγγίσεις μια υπηρεσία στη ζώνη Β που δεν υποτίθεται να είναι προσβάσιμη.
  2. Επιβεβαίωσε ότι η σύνδεση αποτυγχάνει — TCP RST, ICMP unreachable ή timeout, ανάλογα με τον τύπο κανόνα.
  3. Καταγραφή του αποτελέσματος στο ίδιο logbook.

Αν οποιαδήποτε αναμενόμενα μπλοκαρισμένη διαδρομή είναι προσβάσιμη, αυτό είναι rule bug. Διόρθωσέ το την ίδια μέρα.

Συντήρηση blocklist

Οι πίνακες blocklist μεγαλώνουν με τον χρόνο. Δύο συνηθισμένα modes αποτυχίας:

  • Παλιές εγγραφές. Μια IP που ήταν abusive πριν έξι μήνες σήμερα είναι μια οικιακή γραμμή DSL με νέο ιδιοκτήτη. Η περιοδική περιστροφή του αρχείου blocklist (βλ. docs διαμόρφωση Abusive HTTP Watch) περιορίζει αυτό.
  • Drift whitelist. Τα IP ranges γραφείου και VPN αλλάζουν με τον χρόνο. Παλιές εγγραφές whitelist δεν προκαλούν incidents άμεσα, αλλά μειώνουν την αξία της whitelist ως control. Αναθεώρησε το αρχείο whitelist κάθε τρίμηνο.

Rotation πιστοποιητικών

Το επίπεδο τερματισμού TLS χρησιμοποιεί πιστοποιητικά εκδοθέντα από τη Sovereign Certificate Authority. Το rotation είναι αυτόματο μέσω ACME, αλλά:

  • Επιβεβαίωσε το rotation τουλάχιστον μηνιαία — openssl s_client ενάντια στο gateway, επαλήθευσε ότι το notAfter του πιστοποιητικού είναι στο μέλλον, επαλήθευσε ότι η αλυσίδα εξακολουθεί να επαληθεύεται έναντι του εσωτερικού root.
  • Δοκίμασε client trust μετά από οποιαδήποτε CA αλλαγή — διάλεξε έναν αντιπροσωπευτικό client από κάθε ζώνη, πλοηγήσου σε μια HTTPS υπηρεσία εντός του δικτύου, επιβεβαίωσε ότι δεν εμφανίζεται προειδοποίηση πιστοποιητικού.

Mode αποτυχίας: ένα rotation πετυχαίνει στη CA πλευρά αλλά το firewall δεν παίρνει το νέο πιστοποιητικό (configuration reload λείπει, file permissions λάθος). Το προηγούμενο cert παραμένει έγκυρο για ένα διάστημα, καλύπτοντας το bug. Η μηνιαία επαλήθευση το πιάνει.

Ρουτίνα συντήρησης

  • OS patches. Εφάρμοσε σχετικά με ασφάλεια patches εντός του παραθύρου που συνιστά ο vendor. Reboot — το firewall δεν είναι cattle-style appliance, αλλά uptime πέρα από εννέα μήνες προκαλεί προβλήματα.
  • Αναθεώρηση εξαρτήσεων. Οι daemons Tor, I2P, Squid και Privoxy έχουν τον δικό τους κύκλο patch. Παρακολούθησε upstream releases.
  • Έλεγχος χωρητικότητας. Πλήρωση state table, CPU σε peak, memory headroom. Το firewall πρέπει να τρέχει άνετα κάτω από τη μισή χωρητικότητα. Αν όχι, σχεδίασε την επόμενη ανανέωση hardware.

Όταν κάτι σπάζει

Η operator συνήθεια με τη μεγαλύτερη αξία: γράψε τι συνέβη.

Μια σύντομη σημείωση ανά incident — πότε, τι είδες, τι άλλαξες, τι λειτούργησε, τι όχι — μετατρέπει ένα γεγονός σε μόνιμο κέρδος. Την επόμενη φορά που το ίδιο μοτίβο εμφανιστεί, είτε το ίδιο άτομο είτε ο διάδοχός του το λύνει σε λεπτά αντί για ώρες.

Αν το incident ξεπερνά την εξειδίκευση ή τον διαθέσιμο χρόνο της ομάδας σου, η υπηρεσία Λειτουργία είναι η διαδρομή κλιμάκωσης.