ufw allow 443 non ha fatto nulla per un servizio dietro la VPN

Il ping riesce da un client VPN, il servizio TCP va in timeout e ufw allow 443/tcp non cambia assolutamente nulla. Quando l'applicazione gira su un host dietro il gateway e non sul gateway stesso, quell'autorizzazione è stata scritta per il percorso di traffico sbagliato. Il pacchetto non è indirizzato al firewall e non viene consegnato a un processo locale, quindi le regole di ingresso non lo vedono mai. La correzione è una regola di rotta rivolta al flusso inoltrato, e la prova è già nel registro.

Decidi se la destinazione è locale o inoltrata

Leggi il pacchetto come lo vede il kernel. Il traffico consegnato a un servizio sul gateway è ingresso locale. Il traffico che il gateway instrada verso un altro host è inoltrato, e UFW tiene insiemi di regole separati per i due percorsi. La distinzione la decidono l'indirizzo di destinazione e la ricerca di rotta, non l'interfaccia da cui è arrivato il pacchetto.

Una riga di registro che mostra la stessa interfaccia nei campi IN e OUT può comunque descrivere un pacchetto instradato, perché un tunnel che porta i client dentro e fuori da un solo dispositivo appare esattamente così. L'indirizzo di destinazione risolve la questione più in fretta dei nomi delle interfacce. Vedere due volte lo stesso nome non dimostra una consegna locale, e inventare un'interfaccia di tunnel che la distribuzione non ha mai creato non aiuta.

Leggi il blocco prima di aggiungere qualsiasi regola

Riproduci un tentativo di connessione autorizzato e rileva l'origine, la destinazione, il protocollo e la porta di destinazione come li ha registrati il gateway. Confronta quei quattro valori con la voce di registro e con la posizione reale del servizio. Un ping riuscito in precedenza dimostra solo che il suo stesso scambio era permesso, e un firewall può trattare un TCP SYN verso un'applicazione in modo molto diverso.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

Il primo comando restituisce il verdetto con i suoi campi, il secondo mostra cosa è già caricato e in quale ordine. Leggi entrambi prima di modificare qualcosa, perché un rifiuto precedente sopra la tua regola spiega lo stesso sintomo senza alcuna regola mancante.

Scrivi la regola di rotta più stretta che si adatta

In questo esempio i client arrivano su tun0 da 172.20.8.0/24, il servizio ascolta su 10.30.0.15 alla porta 8443, e il gateway esce da ens5. Quei valori sono stati scelti per non somigliare affatto a un valore predefinito di VPC cloud di 10.0.0.0/16 né a una rete domestica di 192.168.0.0/16, e 8443 tiene l'esempio lontano dall'ascoltatore 443 del gateway stesso.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

L'esecuzione a secco stampa l'insieme di regole che ne deriverebbe, ed è il modo più economico per vedere se la tua regola finisce prima o dopo un rifiuto esistente. Verifica i nomi delle interfacce e gli indirizzi interni rispetto alla distribuzione e non all'esempio, e ricorda che quando il NAT di destinazione viene eseguito per primo il filtro vede la destinazione tradotta.

Mantieni il percorso di ritorno con stato

UFW tiene traccia delle connessioni consentite, quindi le risposte a un flusso inoltrato consentito sono ammesse senza una regola inversa esplicita. Aggiungere una regola senza restrizioni nella direzione opposta per far funzionare le cose allarga la politica ben oltre il singolo servizio e non è necessario per un normale scambio richiesta-risposta. Mantieni il percorso di ritorno implicito e l'insieme di regole leggibile.

Applica la regola solo quando l'esecuzione a secco corrisponde alla tua intenzione, poi conferma che l'elenco ordinato la mostri nella posizione attesa. Conserva l'ascoltatore VPN e le regole di gestione come questioni separate, perché cambiarli è una decisione diversa dall'ammettere un'applicazione. Annota la modifica dove è scritta la topologia, così l'ingegnere successivo non deve riscoprirla da una cattura di pacchetti.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Controlla ciò che UFW non può imporre al posto tuo

Una regola corretta ha comunque bisogno dell'inoltro del kernel e di una rotta che raggiunga il servizio. Conferma entrambi prima di dare la colpa al firewall una seconda volta.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Poi guarda fuori dall'host. Su un'istanza cloud la politica UFW del guest non sostituisce i gruppi di sicurezza, le ACL di sottorete né la configurazione di inoltro del provider, quindi un blocco locale è una prova su uno strato e non la prova che tutti gli altri strati consentano il servizio.

Termina provando una nuova connessione con il firewall attivo, da una fonte consentita e da una non correlata. Disattivare UFW elimina il sintomo e distrugge la prova nello stesso comando, per questo dovrebbe essere l'ultimo esperimento e non il primo.