Navegador de sucursal cap al proxy: dues connexions, dues rutes

Un navegador de sucursal darrere d’un proxy explícit obre dues connexions, i fallen per motius diferents. La primera és del navegador al receptor del proxy, portada pel VPN de la sucursal. La segona és del proxy al lloc web, utilitzant el resolutor, la ruta i la política de sortida del mateix proxy. Els tiquets de suport que les tracten com un sol flux envien la gent a l’equip equivocat durant hores. Configureu cadascuna deliberadament i proveu-les en aquest ordre.

Pas 1: escriviu els dos fluxos

La destinació immediata del navegador és el receptor del proxy, no tots els llocs que l’usuari acaba visitant. Aquesta sola frase resol la major part de la confusió d’aquest disseny.

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

Orígens diferents, rutes diferents, permisos diferents. Guardeu l’esbós al registre de canvis, perquè cada comprovació posterior fa referència a una de les seves dues meitats.

Pas 2: doneu al navegador un camí fins al receptor

Anoteu el nom d’amfitrió del proxy, el port del receptor, els requisits d’autenticació i els orígens de sucursal permesos. Aquesta llista és el criteri d’acceptació del primer flux, i ha d’incloure la resolució de noms privada així com la ruta del túnel.

Apliqueu una regla de xarxa estreta per al servei previst en lloc de publicar un proxy sense restriccions a Internet. El proxy pot quedar-se en una xarxa interna quan els seus clients previstos tenen un camí compatible fins a ell.

Pas 3: configureu el navegador, no només la taula de rutes

Feu servir el paràmetre de proxy del navegador, un fitxer PAC o el mecanisme de descoberta gestionat de l’organització. Enviar paquets normals de lloc web cap a l’adreça del proxy amb una ruta no fa que el navegador parli el protocol del proxy; això és intercepció transparent i pertany a un altre disseny de porta d’enllaç.

Anoteu quines aplicacions respecten el paràmetre. Els clients de correu, els actualitzadors i els jocs sovint no ho fan, i continuaran utilitzant el camí normal.

Pas 4: demostreu la connexió de sortida del proxy

El proxy necessita el seu propi resolutor i una ruta permesa fins al lloc web, a més de qualsevol política de tallafocs o traducció que requereixi la seva frontera d’Internet. Un navegador que arriba al receptor no demostra res d’això. Proveu el segon flux des del mateix proxy, amb la mateixa destinació i el mateix port que va indicar l’usuari.

Per a HTTPS, CONNECT obre un túnel fins a la destinació sol·licitada. L’reenviament normal no lliura al proxy la pàgina desxifrada, i desactivar la validació de certificats per improvisar una inspecció no és cap solució.

Pas 5: distingiu quatre fallades

Un repte d’autenticació del proxy és un 407 del receptor. Un CONNECT denegat és una decisió de política al proxy, normalment amb el seu propi estat i línia de registre. Una connexió de sortida fallida sembla un temps d’espera o un restabliment que el proxy registra contra la destinació. Una resposta del lloc web significa que les dues connexions han funcionat i que el problema és a l’origen.

Informeu de la frontera que heu observat, no del resum que el VPN ha fallat.

Pas 6: delimiteu l’abast i planifiqueu el replegament

Decidiu què passa quan el proxy o el túnel no estan disponibles, i digueu clarament quin trànsit cobreix aquest disseny. Porta accés web des de clients que respecten el paràmetre de proxy; no porta correu, protocols arbitraris de dispositius ni programari que ignora la configuració.

Valideu l’operació del navegador requerida i una denegació requerida sota un pla aprovat abans d’estendre el disseny a més clients.