502 / 504 GATEWAY_TIMEOUT errori durante l'esplorazione di determinati siti

Se il server Web non risponde ai pacchetti SYN di WSA, dopo un certo numero di tentativi, al client verrà inviato un errore di timeout del gateway 502.

Le cause tipiche sono:
 1. Problemi sul server Web o sulla rete del server Web.
 2. Un problema di rete sulla rete WSA impedisce ai pacchetti SYN di raggiungere Internet.
 3. Un firewall o un dispositivo simile sta ignorando i pacchetti SYN di WSA o il SYN/ACK del server Web
 4. Lo spoofing IP è abilitato sul server WSA, ma non è configurato correttamente (nessun reindirizzamento del percorso di ritorno)

Procedura di risoluzione dei problemi:

Il primo passaggio consiste nel verificare se il server WSA può eseguire il ping ICMP sul server Web. A tale scopo, è possibile utilizzare il seguente comando CLI:

WSA> ping www.example.com

Se il ping ha esito negativo, non significa che il server non sia attivo. Potrebbe significare che i pacchetti ICMP vengono bloccati da qualche parte nel percorso. Se il ping ha esito positivo, possiamo essere certi che il server WSA disponga di un livello base di connettività di layer 3 al server Web.

Un test telnet verificherà se il server WSA è in grado di stabilire una connessione TCP sulla porta 80 al server Web. Per eseguire un test telnet, vedere le istruzioni riportate più avanti in questo articolo.

Problemi di rete o blocco del firewall

Se il ping ha esito positivo, ma il sistema telnet non funziona, è possibile che un dispositivo di filtraggio, ad esempio un firewall, impedisca al traffico di attraversare la rete. Si consiglia di analizzare i registri del firewall e/o le acquisizioni dei pacchetti dal firewall per ulteriori dettagli.

Lo spoofing IP è abilitato, ma non è configurato correttamente

Se l'inoltro tramite WSA o il test telnet ha esito positivo, significa che WSA è in grado di comunicare direttamente con il server Web, ma se un client esegue l'inoltro tramite WSA con lo spoofing IP, si è verificato un problema.

Senza spoofing IP dei client:

• Il WSA invia un SYN al server Web utilizzando il proprio indirizzo IP come origine. Quando il pacchetto torna indietro, viene indirizzato direttamente al WSA.

Con spoofing IP dei client:

• Il server WSA invia il messaggio SYN, ma utilizza l'indirizzo IP del client come origine. Senza una configurazione di rete speciale, il pacchetto restituito verrà inviato al client anziché al WSA.
• Per utilizzare lo spoofing IP dei client, la rete deve essere configurata in modo molto specifico per facilitare il reindirizzamento corretto dei pacchetti. Se i pacchetti del percorso di ritorno del server Web vengono inviati al client anziché al server WSA, quest'ultimo non vedrà mai i server SYN/ACK e restituirà al client un errore di timeout del gateway 502.

 Se il WSA riceve un pacchetto di reimpostazione TCP nella connessione upstream al server Web, invierà un errore di timeout del gateway 504 al client.
 

Le cause tipiche sono:
 1. Cisco Layer 4 Traffic Monitor (L4TM) impedisce al proxy WSA di connettersi al server Web.
 2. Un firewall, un IDS, un IPS o un altro dispositivo di ispezione dei pacchetti sta bloccando il WSA. 
 
Procedura di risoluzione dei problemi:

Determinare innanzitutto se il router TCP RST proviene da L4TM o da un altro dispositivo.

Se L4TM blocca questo traffico, questo verrà visualizzato nei report della GUI in "Monitor -> L4 Traffic Monitor". In caso contrario, l'RST proviene da un dispositivo diverso.

Blocco L4TM:

Se L4TM è bloccato, si consiglia di non bloccare le porte su cui è in esecuzione anche il proxy WSA. Le cause di questo problema sono molteplici:

1. Il proxy WSA visualizza un messaggio di errore descrittivo in caso di problema, anziché limitarsi a reimpostare la connessione tramite TCP. Ciò contribuirà a limitare la confusione da parte degli utenti finali quando sono bloccati.
2. Il proxy WSA può analizzare e bloccare contenuti specifici, mentre L4TM blocca tutto il traffico che corrisponde a un indirizzo IP della blacklist.

Per configurare L4TM in modo che non venga bloccato sulle porte proxy, selezionare "GUI -> Security Services -> L4 Traffic Monitor".

Se si tratta di un sito Web notoriamente non valido, ma vi sono motivi per cui il traffico deve essere consentito, il sito può essere elencato come bianco in:
"GUI -> Web Security Manager -> L4 Traffic Monitor -> Allow List"

Blocco firewall/IDS/IPS:

Se un altro dispositivo della rete blocca la connessione del server Web al server WSA, si consiglia di analizzare quanto segue:

1. Registri blocchi firewall
2. Il pacchetto in entrata/in uscita viene acquisito durante il problema

I registri di blocco possono verificare rapidamente se il dispositivo sta bloccando il WSA. A volte un firewall, un IPS o un IDS blocca il traffico e NON lo registra in modo appropriato. In questo caso, l'unico modo per dimostrare da dove proviene l'RST TCP è ottenere le clip in entrata e in uscita dal dispositivo. Se si invia un RST dall'interfaccia in entrata e non si viaggiano pacchetti attraverso il lato in uscita, la causa è sicuramente il dispositivo di sicurezza.

Se il server WSA invia un comando HTTP GET ma non riceve mai una risposta, invierà al client un errore di timeout del gateway 504.

Le cause tipiche sono:

• Un firewall, IDS, IPS o un altro dispositivo di ispezione dei pacchetti consente la connessione TCP, ma impedisce al contenuto HTTP di raggiungere il server Web. In questo caso, il test telnet può aiutare a isolare il tipo di dati HTTP da bloccare.

I registri dei blocchi del firewall possono verificare rapidamente se e perché il dispositivo blocca il WSA. A volte un firewall, un IPS o un IDS blocca il traffico e NON lo registra in modo appropriato. In questo caso, l'unico modo per dimostrare da dove proviene l'RST TCP è ottenere le clip in entrata e in uscita dal dispositivo. Se si invia un RST dall'interfaccia in entrata e non si viaggiano pacchetti attraverso il lato in uscita, la causa è sicuramente il dispositivo di sicurezza.

 Dalla CLI di WSA, eseguire il comando telnet:

WSA> telnet

Selezionare l'interfaccia da cui si desidera utilizzare telnet.
1. Automatico
2. Gestione (192.168.15.200/24: wsa.hostname.com)
3. P1 (192.168.113.199/24: data.com)
[1]> 3

Immettere il nome host remoto o l'indirizzo IP.
[]> www.example.com

Immettere la porta remota.
[25]> 80

Prova 10.3.2.99...
Connesso a www.example.com.
Il carattere di escape è '^]'.

Nota: il messaggio "Connected" (Connesso) in rosso indica che il protocollo TCP è stato stabilito correttamente tra il server Web e il server WSA.

È possibile inviare manualmente una richiesta HTTP anche tramite questa sessione telnet. Di seguito è riportata una richiesta di esempio che può essere digitata dopo il messaggio "Connected" (Connesso):

—

SCARICA http://www.example.com HTTP/1.1
HOST: www.example.com
{Inserire}
—

Nota: assicurarsi di aggiungere il ritorno a capo aggiuntivo alla fine, altrimenti il server non risponderà alla richiesta.