Le richieste dell’applicazione falliscono dietro una VPN aziendale, ma il browser funziona

Apri il portale interno in un browser e si carica. Esegui l’applicazione che chiama lo stesso host e fallisce, con un messaggio che non nomina alcun livello. Il tunnel trasporta il browser, quindi il tunnel non è il primo sospetto. Quattro cose stanno tra la tua richiesta e il servizio, e ognuna lascia una firma diversa. Questo è l’ordine che seguo, partendo dalla richiesta che l’applicazione invia davvero e non dalla pagina delle impostazioni del client VPN.

Guarda la richiesta che l’applicazione invia davvero

Prima di toccare la configurazione, fai dire all’applicazione cosa fa. Un’acquisizione di una sola richiesta con il proxy esplicitamente disattivato e un semplice test di porta ti danno due linee di base con cui confrontare i passaggi successivi. Se la richiesta riesce con il proxy disattivato, hai già chiuso tre dei quattro livelli.

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

Esegui le ultime due verso la stessa destinazione e osserva dove divergono. Un browser che funziona più un curl che funziona più un’applicazione che non funziona riducono il problema a qualcosa che l’applicazione aggiunge: un proxy, un trasporto o una dimensione del messaggio.

L’applicazione ha ereditato un proxy che nessuno ha configurato

La maggior parte degli stack HTTP legge la configurazione del proxy dal sistema operativo per impostazione predefinita. Un client VPN aziendale spesso ne installa uno come parte del proprio profilo di accesso, quindi le richieste escono attraverso un proxy che lo sviluppatore non ha mai menzionato nel codice. In .NET l’handler predefinito legge dalle impostazioni IE/WinHTTP; Java legge -Dhttp.proxyHost; Node non ha alcun supporto proxy integrato finché una libreria non lo aggiunge. Il guasto raramente è un rifiuto pulito, ed è per questo che le persone iniziano a guardare il server.

Il test costa una richiesta: disattiva il proxy esplicitamente su un solo handler e confronta.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

Se funziona, la correzione appartiene alla configurazione dell’applicazione, non al tunnel. Ripeti l’audit per ogni runtime del progetto, perché ognuno legge una fonte diversa e forse solo uno è rotto.

La porta scelta non è quella che la policy consente

Un host instradato non è un servizio consentito. La policy aziendale di solito consente le porte web in uscita e scarta il resto, quindi un servizio sulla 8080 o sulla 1883 è irraggiungibile mentre la 443 funziona bene. Il browser qui non dimostra nulla: usa la 443 per definizione.

Pubblica lo stesso servizio dietro la 443 e raggiungilo per nome prima di chiedere un’eccezione. Se l’eccezione è davvero necessaria, limitarla a un intervallo di origine e a una destinazione e trattarla come parte della definizione del servizio, non come il raggiro personale di qualcuno.

TCP grezzo che il percorso reimposta

Le connessioni TCP grezze di lunga durata sono il livello che fallisce nel modo più confuso. Un percorso che consente il traffico web può comunque reimpostare o riscrivere TCP in uscita insolito, e il client segnala un errore di socket che si legge come un blackout. I servizi di messaggistica ed eventi di solito forniscono un trasporto WebSocket proprio per questo tipo di rete, e il cambio è un’opzione del client, non una modifica del tunnel.

Cambia trasporto, ritesta e non cambiare nient’altro nella stessa esecuzione. Quel test a una sola variabile ti dice se il reset è arrivato dal percorso o dal servizio.

Connessioni che si chiudono solo con payload grandi

Una richiesta che riesce e poi muore circa un secondo dopo, ma solo quando il corpo è grande, punta a un limite di dimensione da qualche parte nel mezzo. Un intermediario che conta i byte dei messaggi può far cadere la connessione a metà trasferimento, e il client segnala una chiusura anomala invece di un timeout.

Spezza il payload a livello applicativo. Tieni questo separato dal lavoro sull’MTU: abbassare la dimensione dei pacchetti del tunnel aiuta quando le normali sessioni TCP si bloccano a un numero di byte costante, e non fa nulla per un messaggio che un intermediario ritiene troppo grande.

Come distinguere i quattro in un solo passaggio

Tre osservazioni risolvono la maggior parte dei casi. Il guasto avviene subito o solo con un corpo grande? La stessa richiesta riesce con il proxy disattivato? Il risultato cambia quando cambi porta o trasporto? Scrivi le risposte prima della modifica successiva, perché una VPN aziendale più un proxy ereditato più un valore predefinito dell’applicazione ti danno tre cause plausibili insieme.

Mantieni una variabile per test e annota l’host di destinazione che hai usato. Senza quella linea di base, la persona successiva ripete tutti e quattro i passaggi dall’inizio.