Browser di filiale verso il proxy: due connessioni, due rotte

Un browser di filiale dietro un proxy esplicito apre due connessioni, e falliscono per motivi diversi. La prima va dal browser al listener del proxy, trasportata dal VPN della filiale. La seconda va dal proxy al sito web, usando il resolver, la rotta e la politica di uscita del proxy stesso. I ticket di supporto che le trattano come un unico flusso mandano le persone sul dispositivo sbagliato per ore. Configurate ciascuna deliberatamente e provatele in quest’ordine.

Passo 1: scrivete i due flussi

La destinazione immediata del browser è il listener del proxy, non ogni sito che l’utente visita alla fine. Quella singola frase risolve gran parte della confusione in questo progetto.

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

Origini diverse, rotte diverse, permessi diversi. Tenete lo schizzo nel registro delle modifiche, perché ogni verifica successiva si riferisce a una delle sue due metà.

Passo 2: date al browser un percorso verso il listener

Annotate il nome host del proxy, la porta del listener, i requisiti di autenticazione e le origini di filiale consentite. Quell’elenco è il criterio di accettazione del primo flusso e deve includere la risoluzione dei nomi privata oltre alla rotta del tunnel.

Applicate una regola di rete ristretta per il servizio previsto invece di pubblicare un proxy senza restrizioni su Internet. Il proxy può restare su una rete interna quando i suoi client previsti hanno un percorso supportato verso di esso.

Passo 3: configurate il browser, non solo la tabella delle rotte

Usate l’impostazione del proxy del browser, un file PAC o il meccanismo di scoperta gestito dell’organizzazione. Inviare pacchetti normali di sito verso l’indirizzo del proxy con una rotta non fa parlare al browser il protocollo del proxy; è intercettazione trasparente e appartiene a un altro progetto di gateway.

Annotate quali applicazioni rispettano l’impostazione. I client di posta, gli aggiornatori e i giochi spesso non lo fanno, e continueranno a usare il percorso semplice.

Passo 4: dimostrate la connessione in uscita del proxy

Il proxy ha bisogno del proprio resolver e di una rotta consentita verso il sito web, oltre alla politica di firewall o di traduzione richiesta dal suo confine Internet. Un browser che raggiunge il listener non dimostra nulla di tutto questo. Provate il secondo flusso dal proxy stesso, con la stessa destinazione e la stessa porta segnalate dall’utente.

Per HTTPS, CONNECT apre un tunnel verso la destinazione richiesta. L’inoltro ordinario non consegna al proxy la pagina decifrata, e disattivare la convalida dei certificati per improvvisare un’ispezione non è una soluzione.

Passo 5: distinguete quattro guasti

Una richiesta di autenticazione del proxy è un 407 dal listener. Un CONNECT negato è una decisione di politica sul proxy, di solito con il proprio stato e la propria riga di log. Una connessione in uscita fallita sembra un timeout o un reset che il proxy registra rispetto alla destinazione. Una risposta del sito significa che entrambe le connessioni hanno funzionato e che il problema è all’origine.

Riportate il confine che avete osservato, non il riassunto che il VPN ha fallito.

Passo 6: delimitate l’ambito e pianificate il ripiego

Decidete cosa accade quando il proxy o il tunnel non sono disponibili, e dite chiaramente quale traffico copre questo progetto. Porta accesso web dai client che rispettano l’impostazione del proxy; non porta posta, protocolli arbitrari dei dispositivi o software che ignora la configurazione.

Validate l’operazione del browser richiesta e un rifiuto richiesto secondo un piano approvato prima di estendere il progetto a più client.