Firewall cloud contro firewall dell’host per un server VPN

Consenti la porta VPN nella politica cloud e la stretta di mano può comunque morire sull’istanza: l’ospite esegue il proprio filtro e il proprio binding del listener, e l’uno o l’altro può scartare ciò che il cloud ha approvato. Accade anche il contrario, quando una regola dell’host permette la porta e una politica più in alto la scarta prima. Due proprietari, due insiemi di regole, un solo percorso dei pacchetti. Percorrilo in ordine invece di indovinare sullo strato più sospetto.

Parti dal bordo e procedi verso l’interno

L’ordine è fisso: endpoint pubblico, interfaccia della risorsa, politica cloud associata, indirizzo dell’ospite, listener del processo, regole di input locali. Ogni fase lascia passare il pacchetto o chiude l’indagine, per questo iniziare dall’ospite fa perdere più tempo.

Il traffico del client inoltrato è una fase separata, esaminata dopo la decapsulazione del tunnel. Lo strato cloud vede solo il tunnel esterno, quindi può approvare una connessione e non avere comunque nulla a che fare con una richiesta di servizio interna. Un tunnel che si connette ma non raggiunge un host interno di solito indica l'inoltro, non una porta chiusa.

Leggi la politica cloud prima di toccare l’ospite

Conferma la regola in ingresso per la porta VPN, il suo protocollo e l’ambito di origine che corrisponde al client di prova. Controlla anche la lista di controllo degli accessi della sottorete: un secondo filtro con regole e valori predefiniti propri. Entrambi devono consentire il flusso prima che un pacchetto raggiunga l’istanza. Un permesso in uno e un rifiuto nell’altro è la forma abituale di questo difetto.

Restringi l’ambito finché non significa qualcosa. Aprire la porta VPN a tutto internet è facile da dimostrare e difficile da difendere, mentre una regola fissata a un indirizzo si rompe quando il client di prova cambia rete. Annota l’identificatore della regola e il proprietario della politica, così la modifica successiva è riconducibile a una persona.

Conferma il listener, poi la catena di input

Sull’istanza, verifica che il processo VPN sia legato all’indirizzo e alla porta attesi, per esempio con ss -lntp 'sport = :1194'. Un demone legato solo a 127.0.0.1 accetta client locali e nulla attraverso il tunnel, il che dall’esterno sembra esattamente una porta filtrata.

Poi leggi le regole locali nella sintassi che useresti per modificarle, come iptables -S INPUT o nft list chain inet filter input. Una regola scritta in un file ma mai caricata, o un drop predefinito senza alcun permesso corrispondente, scarta i pacchetti in silenzio. Per un gateway che inoltra, controlla anche le impostazioni di inoltro e di percorso inverso. Sono loro a decidere cosa succede ai pacchetti instradati attraverso l’istanza invece che indirizzati ad essa.

Con stato in uno strato, senza stato nel successivo

I gruppi di sicurezza ricordano i flussi che hanno permesso e lasciano rientrare le risposte. Le liste di controllo degli accessi delle sottoreti e molti firewall dell’host non tengono questo stato, quindi una regola che copre solo la direzione in uscita lascia passare la richiesta e scarta la risposta. Non portare mai un assunto sul traffico di ritorno tra strati senza leggere la regola del secondo strato.

I contatori lo risolvono più in fretta che leggere ogni regola dell’account. Un contatore che sale significa che il pacchetto è arrivato ed è stato scartato lì, mentre uno fermo a zero significa che non è mai arrivato così lontano; iptables -vnL INPUT e nft list ruleset mostrano quei numeri quando le regole sono state caricate con i contatori.

Prova con una sessione nuova, non con una attiva

Lascia intatti la rete di origine e il profilo di prova mentre confronti le viste, e apri una nuova connessione dopo ogni modifica. Raggiungere la console web sulla 443 non dice nulla sul fatto che il demone VPN sia legato alla 1194, quindi prova la porta che ti serve. Una sessione esistente è il peggior testimone qui. Continua a funzionare mentre ogni nuovo accesso viene rifiutato.

Prima di modificare una politica remota, assicurati una via di ritorno che non dipenda dal percorso che stai cambiando. Poi apri una seconda sessione di amministrazione accanto al test VPN: una stabilita prima può sopravvivere alla regola che blocca le nuove. Annota i due proprietari delle politiche perché nessuna ricostruzione ripristini metà del percorso; se entrambi gli strati concordano e il tunnel continua a fallire, cattura sull’interfaccia dell’ospite e controlla l’indirizzo e la porta che il client usa davvero.