Filiaalbrowser naar proxy: twee verbindingen, twee routes

Een filiaalbrowser achter een expliciete proxy opent twee verbindingen, en ze falen om verschillende redenen. De eerste is browser naar proxylistener, gedragen via de site-VPN. De tweede is proxy naar website, met de eigen resolver, route en uitgaande policy van de proxy. Supporttickets die ze als één stroom behandelen, sturen mensen urenlang naar het verkeerde apparaat. Stel ze elk bewust in en test ze in die volgorde.

Stap 1: schrijf de twee stromen op

De onmiddellijke bestemming van de browser is de proxylistener, niet elke site die de gebruiker uiteindelijk bezoekt. Die ene zin lost het grootste deel van de verwarring in dit ontwerp op.

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

Verschillende bronnen, verschillende routes, verschillende rechten. Bewaar de schets in het wijzigingsrecord, want elke latere controle verwijst naar een van de twee helften.

Stap 2: geef de browser een pad naar de listener

Noteer de hostnaam van de proxy, de listenerpoort, de authenticatievereisten en de toegestane filiaalbronnen. Die lijst is het acceptatiecriterium voor de eerste stroom, en moet zowel interne naamresolutie als de tunnelroute bevatten.

Pas een smalle netwerkregel toe voor de beoogde dienst in plaats van een onbeperkte proxy op internet te publiceren. De proxy kan op een intern netwerk blijven wanneer de beoogde clients een ondersteund pad ernaartoe hebben.

Stap 3: configureer de browser, niet alleen de routetabel

Gebruik de proxyinstelling van de browser, een PAC-bestand of het beheerde ontdekkingsmechanisme van de organisatie. Gewone websitepakketten met een route naar het proxyadres sturen maakt niet dat de browser het proxyprotocol spreekt; dat is transparante interceptie en hoort bij een ander gatewayontwerp.

Noteer welke toepassingen de instelling respecteren. Mailclients, updaters en games doen dat vaak niet, en ze blijven het eenvoudige pad gebruiken.

Stap 4: bewijs de doorgaande verbinding van de proxy

De proxy heeft zijn eigen resolver en een toegestane route naar de website nodig, plus het firewall- of vertaalbeleid dat zijn internetgrens vereist. Een browser die de listener bereikt, bewijst daar niets van. Test de tweede stroom vanaf de proxy zelf, met dezelfde bestemming en poort die de gebruiker meldde.

Voor HTTPS opent CONNECT een tunnel naar de gevraagde bestemming. Gewone doorsturing geeft de proxy niet de ontsleutelde pagina, en het uitschakelen van certificaatvalidatie om inspectie te improviseren is geen oplossing.

Stap 5: onderscheid vier storingen

Een proxyauthenticatie-uitdaging is een 407 van de listener. Een geweigerde CONNECT is een beleidsbeslissing op de proxy, meestal met een eigen status en logregel. Een mislukte doorgaande verbinding ziet eruit als een time-out of reset die de proxy tegen de bestemming logt. Een antwoord van de website betekent dat beide verbindingen werkten en dat het probleem bij de oorsprong ligt.

Meld de grens die je hebt waargenomen, niet de samenvatting dat de VPN faalde.

Stap 6: bepaal de scope en plan de terugval

Bepaal wat er gebeurt wanneer de proxy of de tunnel niet beschikbaar is, en zeg duidelijk welk verkeer dit ontwerp dekt. Het draagt webtoegang van clients die de proxyinstelling respecteren; het draagt geen mail, willekeurige apparaatprotocollen of software die de configuratie negeert.

Valideer de vereiste browserbewerking en één vereiste weigering volgens een goedgekeurd plan voordat je het ontwerp naar meer clients uitbreidt.