Operare

Drill trimestrial de failover#

Întregul sens al unui setup HA dual-provider este ca failover-ul să funcționeze când uplinkul primar cade real. Singura cale de a te bizui pe asta este să-l testezi intenționat.

Cadență recomandată: trimestrial, într-o fereastră de trafic liniștit, cu operatorul la consolă.

Flux:

1. Anunță drillul pe canalul echipei — failoverul ar trebui să fie invizibil, dar dacă merge ceva prost, vrei să afli imediat.
2. Dezactivează uplinkul primar la nivel de interfață (nu de la modemul providerului — asta simulează cazul de eroare greșit).
3. În cinci secunde, monitorul de failover ar trebui să comute ruta default pe al doilea uplink.
4. Verifică accesibilitatea externă: o cerere dintr-o zonă ar trebui să rezolve, să descarce și să se întoarcă în continuare.
5. Reactivează uplinkul primar.
6. Monitorul ar trebui să mute ruta default înapoi pe primar în intervalul său configurat.
7. Notează drillul într-un jurnal: data, time-to-detect, time-to-recover, orice neobișnuit.

Dacă failover-ul ia mai mult decât așteptat, intervalul de check sau pragurile monitorului trebuie ajustate. Dacă failover-ul nu are loc deloc, configurația monitorului este stricată — repară-o înainte să pleci acasă. Un monitor de failover defect e mai rău decât niciun monitor; dă operatorului falsă siguranță.

Review de log#

Trei stream-uri de log sunt importante:

• Evenimente de firewall. Decizii de drop, extensii de tabel, NAT state. Zgomotos la scan-uri de recunoaștere, liniștit sub sarcină normală.
• Evenimente de SSL offloading. Erori de terminare, eșecuri de validare a certificatului, verdicte ale scannerului. Spike-uri înseamnă că ceva s-a schimbat — o rotație de certificat upstream, un client nou care nu are încredere în root-ul intern de CA sau un pattern de malware care a scăpat de un stadiu anterior de filtru.
• Evenimente ale monitorului de failover. Tranziții de link. Ar trebui să fie gol în cele mai multe săptămâni. Tranziții frecvente sugerează un uplink care pâlpâie — deschide subiect la carrier.

Rutină recomandată pentru operator: săptămânal cincisprezece minute de scroll prin aceste trei stream-uri. Marchează neobișnuitul, deschide tickete pentru următorul review trimestrial.

Verificarea granițelor de zonă#

Zonele sunt definite în setul de reguli. Setul de reguli poate fi greșit. Singura cale de a stabili care afirmație este adevărată este testarea.

Cadență recomandată: semestrial, sau după fiecare modificare semnificativă a setului de reguli.

Pentru fiecare pereche de zone (Clienți ↔ DMZ, Clienți ↔ VPN, Anonimizare ↔ tot ce e altceva etc.):

1. Dintr-un host în zona A, încearcă să ajungi la un serviciu în zona B care nu ar trebui să fie accesibil.
2. Confirmă că conexiunea eșuează — TCP RST, ICMP unreachable sau timeout, în funcție de tipul regulii.
3. Notează rezultatul în același jurnal.

Dacă o cale așteptată-blocată este accesibilă, e un bug de regulă. Repară chiar în aceeași zi.

Întreținerea blocklistei#

Tabelele de blocklistă cresc în timp. Două imagini frecvente de eroare:

• Intrări învechite. Un IP care era abuziv acum șase luni este astăzi o conexiune DSL cu un proprietar nou. Rotația periodică a fișierului de blocklistă (vezi documentația Configurare Abusive HTTP Watch) limitează asta.
• Drift de whitelist. Range-urile de IP-uri de birou și VPN se schimbă în timp. Intrările învechite de whitelist nu cauzează incidente imediate, dar reduc valoarea whitelistului ca instrument de control. Revizuiește fișierul de whitelist trimestrial.

Rotația certificatelor#

Stratul de terminare TLS folosește certificate de la Sovereign Certificate Authority. Rotația se face automat prin ACME, dar:

• Confirmă rotația cel puțin lunar — openssl s_client împotriva gateway-ului, verifică că notAfter al certificatului este în viitor, verifică că lanțul încă validează împotriva root-ului intern.
• Testează încrederea clientului după fiecare modificare pe partea CA — alege un client reprezentativ per zonă, apelează un serviciu HTTPS din rețea, verifică să nu apară o avertizare de certificat.

Imagine de eroare: o rotație trece pe partea CA, dar firewallul nu preia certificatul nou (lipsește reload-ul de configurare, permissions de fișier greșite). Certificatul vechi e încă valabil o vreme — bugul rămâne ascuns. Verificarea lunară prinde asta.

Întreținere de rutină#

• Patch-uri OS. Patch-urile relevante pentru securitate se aplică în fereastra recomandată de producător. Reboot — firewallul nu este o appliance cattle-style, dar uptime dincolo de nouă luni invită probleme.
• Review de dependențe. Daemonii Tor, I2P, Squid și Privoxy au fiecare propriile cicluri de patch. Urmărește release-urile upstream.
• Check de capacitate. Umplerea state-table-ului, CPU la vârf, headroom de memorie. Firewallul ar trebui să ruleze confortabil sub jumătate de capacitate. Dacă nu, planifică următoarea reînnoire de hardware.

Când se sparge ceva#

Obiceiul operațional cu cea mai mare valoare: notează ce s-a întâmplat.

O notă scurtă per incident — când, ce ai văzut, ce ai schimbat, ce a funcționat, ce nu — transformă un incident într-un câștig de cunoaștere permanent. La următoarea apariție a aceluiași pattern, fie aceeași persoană, fie succesorul ei, rezolvă în minute în loc de ore.

Dacă un incident depășește expertiza sau timpul echipei voastre, Operare este calea de escaladare.