Perché la risposta DNS fallisce su un firewall perimetrale VPN senza stato

Il tunnel è attivo, i client raggiungono l'host VPN e l'host non riesce a risolvere nulla. Le sue stesse query in uscita lasciano l'interfaccia in modo pulito, quindi il guasto è sulla via del ritorno: su un perimetro a monte che filtra il traffico in ingresso senza memoria di ciò che l'host ha appena inviato. Consentire la porta del tunnel non descrive affatto quello scambio. La risposta a una query DNS è un flusso separato, e se il perimetro è senza stato, nulla l'ha autorizzata a tornare.

I due scambi non sono lo stesso scambio

Scrivi le tuple e l'errore diventa evidente. La porta di destinazione della richiesta diventa la porta di origine della risposta, cioè l'opposto di ciò che la maggior parte delle persone immagina quando aggiunge una regola in ingresso per la porta 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Una regola in ingresso che richiede la porta di destinazione 53 descrive traffico indirizzato a un listener DNS in esecuzione sull'host, che è un servizio del tutto diverso. Quegli indirizzi sono esempi di documentazione, e la porta di origine è scelta dal client per ogni query, quindi non è un valore che puoi copiare in una regola e aspettarti che continui a funzionare.

Perimetro senza stato contro firewall dell'host con stato

Un filtro perimetrale senza stato valuta ogni pacchetto in ingresso rispetto alla sua lista di regole senza alcuna tabella delle connessioni alle spalle. Una query in uscita partita correttamente non crea alcun permesso per la sua risposta in ingresso, perché il dispositivo non ha alcun registro che una query sia mai avvenuta. Un firewall dell'host con stato è l'opposto: il suo tracciamento delle connessioni riconosce il traffico di ritorno di uno scambio consentito e lo lascia passare senza una regola per la risposta. Entrambi i confini esistono in un percorso tipico, ed entrambi devono consentire il pacchetto previsto.

Il confronto conta perché i due dispositivi falliscono in modo diverso. Un firewall con stato che nega la risposta registra un drop; un perimetro senza stato la nega in silenzio, ed è per questo che l'host semplicemente va in timeout.

Costruisci il permesso attorno al protocollo, non a un numero di porta

Limita la regola agli indirizzi reali del resolver, all'host di destinazione e alla politica della porta di ricezione supportata dal prodotto. Tieni presente anche il percorso TCP del DNS, perché una risposta grande o un ripiego per troncamento sposta lo scambio su TCP e una regola solo per UDP non lo coprirà. Se il perimetro supporta l'ispezione con stato per un flusso definito, preferiscila a una regola di risposta scritta a mano, perché il percorso con stato segue automaticamente le porte scelte dal client.

Poi verifica quale prodotto nel percorso filtra davvero il traffico. Un ambito perimetrale IPv4 documentato non stabilisce una politica IPv6, e il traffico interno del provider potrebbe non attraversare mai quello stesso filtro.

Perché consentire qualsiasi porta di origine 53 non è una correzione

Una regola che accetta tutto ciò che dichiara la porta di origine 53 è una regola che accetta ciò che un mittente scrive in un campo di intestazione. Il numero di porta non autentica il mittente e non prova che il payload sia una risposta valida, quindi la regola amplia l'esposizione dell'host senza rendere la risoluzione più affidabile. Mantieni le restrizioni di origine e i controlli di risposta del client stesso, inclusa la randomizzazione della porta di origine, invece di disattivarli per semplificare una lista di accesso.

Se il resolver è un servizio che controlli, limitarlo ai suoi indirizzi è sufficiente. Se è un resolver pubblico, limita agli indirizzi che hai approvato e annotali nel commento della regola.

Verifica al confine giusto, nella direzione giusta

Cattura sull'host e sul perimetro per la stessa query, e confronta le tuple invece dei conteggi dei pacchetti. Una query visibile su entrambi i lati senza risposta visibile sul lato host punta al filtro in ingresso; una query visibile solo sul lato host punta all'instradamento o al resolver stesso. Ripeti con una query TCP se hai solo un'autorizzazione UDP, perché è proprio la lacuna che il primo test non può vedere.

Correggere questo completa uno scambio DNS di cui l'host ha davvero bisogno. Non trasforma l'host in un resolver pubblico, non autorizza flussi VPN inoltrati e non prova che DNS fosse la causa di qualche problema di tunnel non correlato.