Perché una risorsa VPN funziona e un’altra va in timeout

Un servizio privato si carica attraverso il tunnel e il successivo va in timeout, e la tentazione è ricostruire l’intero profilo del client. Il servizio che funziona è più utile come controllo che come motivo per ricominciare da zero. Dimostra che una destinazione, una porta e un percorso di autorizzazione sono stati soddisfatti, e nulla oltre.

Due servizi sullo stesso gateway possono essere raggiunti tramite famiglie di indirizzi diverse, sottoreti diverse e policy diverse.

Separate il flusso che funziona da quello che fallisce

Trattate ogni servizio come un flusso a sé e non come un sintomo della VPN. Un client illustrativo può aprire portal.corp.example su 172.20.4.15:443 e comunque non raggiungere un database su 172.20.9.40:5432, perché sono due destinazioni con due insiemi di regole. Annotate entrambe le righe prima di cambiare qualsiasi cosa, comprese la porta e il protocollo, perché una regola che consente TCP 443 su un host non dice nulla su TCP 5432 sullo stesso host.

La riga che fallisce è quella da indagare. La riga che funziona dice solo dove si trova la linea di base, e sarà il punto di confronto dopo ogni modifica.

Confrontate gli indirizzi prima dei nomi

Risolvete ogni nome completo con la policy che l’applicazione usa davvero, poi annotate la famiglia di indirizzi scelta. Un nome può restituire un indirizzo IPv6 mentre un altro restituisce IPv4, e una vecchia risposta in cache può inviare una richiesta a un indirizzo pubblico che non ha nulla a che fare con il servizio privato.

ip route get 172.20.4.15
ip route get 172.20.9.40
ip -6 route get 2001:db8:60::20

La ricerca risponde a una domanda ristretta: quale rotta sceglierebbe questo host per quella destinazione, con le tabelle e le regole di policy attuali. Una rotta per 172.20.4.0/24 non copre 172.20.9.0/24, e un secondo gestore di rete o una rotta locale con specificità migliore possono sovrascrivere silenziosamente il tunnel. Ripetete la ricerca nello spazio dei nomi o con il marchio che usa l’applicazione quando differiscono dalla vostra shell. Annotate anche l’interfaccia da cui esce il pacchetto, perché la tabella delle rotte può nominare un’interfaccia mentre l’instradamento per policy manda il flusso da un’altra.

Una rotta che corrisponde è una condizione necessaria, non un permesso. Dice che il pacchetto ha dove andare e nulla sul fatto che un firewall, un servizio di autorizzazione o l’host stesso lo accetteranno.

Il protocollo e la fase di risposta dicono dove si ferma

Una risposta ping non dimostra che una porta di database sia aperta, e una pagina HTTPS riuscita non autorizza una condivisione file sulla stessa macchina. Annotate cosa è tornato davvero invece di appiattire ogni errore in un’unica categoria. Un timeout, un reset, un errore di identità TLS e un rifiuto a livello applicativo puntano ciascuno a uno strato diverso.

La distinzione conta perché le correzioni divergono. Il silenzio di solito significa un problema di rotta, di firewall o di traduzione sul percorso. Un reset immediato suggerisce che qualcosa ha raggiunto l’host e ha rifiutato la porta. Un errore di certificato significa che la connessione è arrivata e il nome non corrispondeva, il che è un problema di configurazione e non di raggiungibilità. Un rifiuto dell’applicazione significa che la rete ha fatto il suo lavoro e l’identità è stata respinta dopo.

Quando una risorsa viene pubblicata attraverso un gateway, confrontate l’indirizzo sorgente visto dalla destinazione con la sorgente che il vostro client crede di usare. Una richiesta originata dal gateway stesso può riuscire mentre la stessa richiesta da un client fallisce, perché le due arrivano da indirizzi diversi e incontrano regole diverse.

Cambiate una variabile e rieseguite entrambe le richieste

L’identità è l’ultimo posto in cui si guarda e il primo in cui appare un rifiuto corretto. L’accesso alla VPN, il gruppo della directory e l’account dell’applicazione sono tre identità separate che possono divergere. L’accesso a un portale non implica mai l’accesso al database dietro di esso, e un nome in una directory non crea una riga in un’altra. Se il servizio è fuori dall’ambito previsto dell’utente, il rifiuto è il sistema che funziona.

Chiedete al proprietario della risorsa di confermare il diritto previsto invece di aggiungere una rotta ampia o aprire un gruppo come test. Ampliare la rete per dimostrare un punto è il modo in cui una diagnostica temporanea diventa un’esposizione permanente, e distrugge il controllo con cui avete iniziato. Un’unica discrepanza dimostrata per iterazione è sufficiente: una rotta mancante, una famiglia di indirizzi sbagliata, una porta bloccata o un’appartenenza a un gruppo mancante.

Dopo ogni modifica ripetete entrambe le richieste e tenete gli output fianco a fianco. L’indagine finisce quando il servizio che falliva funziona secondo la propria policy mentre il servizio che funziona e i rifiuti che ancora vi aspettate si comportano esattamente come prima.