TCP funziona e UDP raggiunge un altro server sulla stessa porta

Un profilo funziona su TCP e fallisce su UDP con un avviso sul certificato. La lettura intuitiva è che il percorso UDP abbia rotto la fiducia, e la correzione intuitiva è accettare il certificato. Entrambe le ipotesi trascurano una possibilità che spiega del tutto il sintomo: i due trasporti hanno raggiunto macchine diverse. Una regola di inoltro è applicata per protocollo, e nulla obbliga le metà TCP e UDP di uno stesso numero di porta a puntare allo stesso host.

Un numero di porta, due regole indipendenti

L’inoltro è una consultazione di tabella indicizzata per protocollo, indirizzo di destinazione e porta. Un gateway con una regola per TCP 1194 e una regola per UDP 1194 esprime due decisioni indipendenti, e queste possono indicare host interni diversi. Il numero condiviso è una comodità per le persone, non una proprietà che la rete imponga. Trattate il numero di porta come un’etichetta e non come una definizione di servizio.

Guardate le regole effettive invece di quelle previste. Indirizzo di destinazione, porta tradotta e interfaccia di ingresso partecipano tutti, e una regola rimasta da una migrazione precedente è la ragione abituale per cui le due metà non concordano.

Scrivete entrambe le mappature prima di cambiare qualsiasi altra cosa. La coppia di righe è l’intera ipotesi.

Che cosa ha verificato davvero il client

Durante l’handshake il client controlla il certificato rispetto alla fiducia configurata e rispetto al nome che si aspetta. Un certificato inatteso è una verifica riuscita che ha fallito il controllo dell’identità, che è l’esito corretto quando la controparte non è quella che volevate raggiungere. Respingere il certificato dimostra che il client funziona, non che il trasporto sia rotto. Leggete il nome riportato prima della catena riportata, perché il nome è ciò che il client ha confrontato.

La distinzione conta perché i due guasti portano a correzioni diverse. Un problema di fiducia richiede una correzione della fiducia, mentre una controparte inattesa richiede una correzione dell’instradamento o dell’inoltro.

Annotate quale identità ha riportato il client. Quel nome è l’indizio più forte su quale macchina ha risposto.

Correlare il tentativo con un server

Registrate il profilo, l’indirizzo pubblico, il trasporto e la porta usati dal client. Poi confrontate l’ora del tentativo con il registro del server che volevate raggiungere. La sua assenza è un indizio e non una prova di uno scarto del firewall, perché i livelli di registrazione variano tra distribuzioni. Una marca temporale insieme a un indirizzo di origine restringe più di ciascuno dei due da solo.

Confrontate l’identità del certificato incontrata con l’identità attesa tramite un canale amministrativo. È quel confronto fuori banda che mantiene affidabile il controllo.

Controllate vecchie regole di inoltro, listener alternativi e qualsiasi percorso di bilanciamento del carico prima di concludere che i due trasporti condividono un backend. Ognuno di questi può reindirizzare un flusso senza toccare l’altro trasporto.

Non adattare la fiducia a una controparte sbagliata

Importare la CA inattesa fa sparire il sintomo e cambia di chi si fida il client. È uno stato peggiore di una connessione fallita, perché nasconde la discrepanza invece di risolverla. Lo stesso vale per disattivare la verifica solo per vedere se il tunnel sale.

Se la controparte risulta legittima ma non desiderata, l’azione corretta è ritirarla o puntare la regola all’host giusto. L’archivio delle fiducie non è il posto per riconciliare un errore d’inventario.

Conservate il testo del rifiuto. È l’unica registrazione di ciò che il client ha visto.

Dopo la correzione, provare un nuovo flusso

Correggete la mappatura, poi collegatevi con una nuova sessione client. La traduzione con stato può mantenere un flusso esistente puntato alla vecchia destinazione, quindi una connessione stabilita può sopravvivere al cambiamento e fuorviarvi. Avviatene una nuova e confermate dal registro del server previsto che ha gestito il tentativo.

Se entrambi i trasporti raggiungono dimostrabilmente lo stesso server e si comportano ancora diversamente, la differenza rimanente sono i listener e la configurazione di quel server. Il confronto dei trasporti significa qualcosa solo dopo che l’identità dell’endpoint è fissata.