Lavorando su un progetto cloud in produzione, una delle difese base più comuni e necessarie è Fail2Ban (o meccanismi simili di firewall). Questa guida documenta un episodio reale: cosa succede quando tu (o uno script automatizzato) sbagli a connetterti in SSH per qualche volta di troppo, e vieni letteralmente "chiuso fuori" dal tuo stesso server.
1. L'Antefatto: Tentativi SSH e "Connection Refused"
Mentre un task automatizzato stava tentando di sincronizzare dei file in produzione (attraverso rsync via SSH), ha commesso un errore fatale: ha effettuato 3 tentativi consecutivi di login usando utenti standard (come root e ubuntu) senza specificare la chiave privata corretta, ricevendo l'errore:
Permission denied (publickey,password).Subito dopo aver tentato la connessione con la chiave corretta, il server ha smesso di rispondere, emettendo il temuto messaggio:
ssh: connect to host xxx.xxx.xxx.xxx port 22: Connection refused
Cosa è successo? Il passaggio istantaneo da "Permission denied" a "Connection refused" è la firma inconfondibile di Fail2Ban o di una regola iptables scattata per mitigare un potenziale attacco brute-force. Il demone di sicurezza ha letto i log di autorizzazione, ha individuato i tentativi falliti in pochi secondi e ha bloccato il traffico in entrata sulla porta 22 per l'IP di origine.
2. Il Problema della Rete Condivisa (Hotspot)
La situazione si è complicata perché l'ambiente di sviluppo locale condivideva la stessa connessione di rete dell'operatore umano (tramite un hotspot mobile).
Di conseguenza, quando Fail2Ban ha bannato l'indirizzo IP, ha bloccato l'intera rete locale di sviluppo. L'operatore si è ritrovato impossibilitato ad accedere alla propria VPS anche inserendo la chiave SSH perfetta.
3. La Soluzione: Il Trucco dell'IP Dinamico
Invece di attendere lo scadere del ban, esiste una scappatoia immediata se si utilizza una connessione cellulare.
È bastato attivare la Modalità Aereo sul telefono che faceva da Hotspot per circa 5 secondi, e poi disattivarla.
Perché funziona? Le reti cellulari usano indirizzi IP dinamici (spesso dietro un Carrier-Grade NAT). Riconnettendosi, l'ISP assegna un indirizzo IP pubblico diverso. Fail2Ban, basandosi esclusivamente sull'indirizzo IP, non riconoscerà più la connessione come minacciosa, permettendo al deploy di concludersi con successo.
Stai sviluppando un'App iOS Nativa o un'Architettura Cloud?
Hai bisogno di consulenza tecnica su Swift Concurrency, Docker backend, notifiche push APNs o pubblicazione su App Store? Parliamone direttamente.
Contattami su WhatsApp