Hai messo l’indirizzo VPN in whitelist e resta bloccato? Rintraccialo

Mettere in whitelist l’indirizzo mostrato da un’app VPN raramente risolve una porta bloccata, e il pacchetto spiega perché. Il firewall non ignora la tua regola; valuta un indirizzo di origine che nulla sullo schermo del client mostra. Finché la destinazione non riporta quel valore, ogni modifica della regola è un’ipotesi.

Parti dalla richiesta che arriva al servizio. L’indirizzo del tunnel, l’indirizzo di uscita e qualsiasi traduzione nel mezzo restano ipotesi finché la destinazione non ne conferma uno.

L’indirizzo nell’app non è quello che arriva

Una connessione VPN trasporta almeno quattro indirizzi che vale la pena nominare separatamente: l’endpoint del server, l’indirizzo interno del tunnel assegnato al tuo client, l’indirizzo locale Wi-Fi o Ethernet, e l’indirizzo pubblico che un sito vede dopo che il traffico ha lasciato il provider. La finestra del client potrebbe mostrare solo il secondo. Nomina tutti e quattro prima di nominare una regola. Con il tunnel diviso, le richieste verso una destinazione pubblica possono aggirare del tutto il tunnel, quindi la sessione che fallisce non è quella che l’utente crede di aver avviato.

Decidi quale di questi quattro la regola deve consentire, poi verificalo dall’altro lato. Se il requisito è davvero un indirizzo d’ufficio, la condizione è la rotta più la disposizione di uscita di quel sito, e una connessione etichettata Office VPN non fornisce né l’una né l’altra da sola.

Segui una richiesta fino al suo confine di filtraggio

Conferma l’indirizzo di destinazione e la porta usati dal client, poi verifica che questa destinazione segua il percorso che presupponi. Una porta di container pubblicata, un proxy inverso o un inoltro di porta possono spostare la decisione su un host che non hai mai modificato. Ognuno di questi salti può portare la propria politica. Stabilire prima il percorso ti risparmia di correggere una regola che nessun pacchetto raggiunge.

Su un host Linux autorizzato, leggi le regole attive in ordine prima di modificarle. I servizi inoltrati e quelli dei container saltano spesso nella propria catena, quindi esamina la destinazione del salto oltre al verdetto finale.

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

Cita il numero di regola corrispondente nel ticket. Senza di esso il lettore successivo non può sapere quale modifica ha cambiato l’esito. Un numero di regola senza marca temporale resta ambiguo.

Verifica il percorso con una cattura mirata

Una richiesta innocua e una cattura ristretta risolvono la domanda che continua a ripresentarsi. Filtra sulla porta di destinazione e sull’host in esame, limita il numero di pacchetti e interrompi la cattura appena la richiesta è completa.

tcpdump -ni any 'tcp dst port 9443' -c 20

Confronta tre valori fianco a fianco: l’origine nella cattura, l’origine indicata dalla regola corrispondente e il rifiuto registrato dall’applicazione. Possono essere tutti diversi, e solo il primo spiega una caduta decisa da una regola IP. Un’intestazione HTTP inoltrata appartiene al livello proxy, quindi un log che cita quell’intestazione non descrive l’origine valutata dal firewall.

Leggi l’ordine della catena, non solo la regola

Il riferimento di iptables documenta l’attraversamento ordinato, perciò un permesso che sta sotto un rifiuto terminale corrispondente non salva mai il pacchetto. Una connessione accettata prima può anche comportarsi diversamente da una nuova, quindi un vecchio successo non dice nulla sulla nuova regola. Trova il rifiuto o la caduta sopra il tuo permesso prima di supporre che il permesso sia sbagliato. I contatori per regola dicono anche quale regola ha visto il pacchetto.

Eliminare una regola per vedere cosa succede è una modifica, non un’osservazione. Leggi i contatori, annota il numero di regola e conserva la politica originale nel registro delle modifiche. Se un test è inevitabile, eseguilo su una copia della catena.

Modifica la regola che il suo proprietario controlla

Aggiorna solo la politica di origine e di servizio prevista, tramite chi la possiede. Un’uscita tradotta condivisa può rappresentare molti utenti contemporaneamente, quindi consentire quell’indirizzo non autentica nessuno, e i permessi applicativi dietro restano dove sono.

Quando l’indirizzo continua a spostarsi, la risposta duratura è un’uscita stabile o un canale autenticato, non un elenco di eccezioni più lungo. Annota l’origine osservata, la porta di destinazione e il numero di regola.