Filialbrowser til proxy: to forbindelser, to ruter

En filialbrowser bag en eksplicit proxy åbner to forbindelser, og de fejler af forskellige årsager. Den første er browser til proxylytter, båret gennem filialens VPN. Den anden er proxy til websted, ved hjælp af proxyens egen resolver, rute og udgående politik. Supportbilletter, der behandler dem som én strøm, sender folk til den forkerte enhed i timer. Sæt hver af dem op bevidst, og test dem i den rækkefølge.

Trin 1: skriv de to strømme ned

Browserens umiddelbare destination er proxylytteren, ikke hvert websted, brugeren til sidst besøger. Den ene sætning løser størstedelen af forvirringen i dette design.

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

Forskellige kilder, forskellige ruter, forskellige tilladelser. Gem skitsen i ændringsregistret, fordi hvert senere tjek henviser til en af dens to halvdele.

Trin 2: giv browseren en vej til lytteren

Noter proxyens værtsnavn, lytterens port, godkendelseskravene og de tilladte filialkilder. Den liste er acceptkriteriet for den første strøm, og den bør omfatte intern navneopløsning såvel som tunnelruten.

Anvend en snæver netværksregel for den tilsigtede tjeneste i stedet for at offentliggøre en ubegrænset proxy på internettet. Proxyen kan blive på et internt netværk, når dens tilsigtede klienter har en understøttet vej til den.

Trin 3: konfigurer browseren, ikke kun rutetabellen

Brug browserens proxyindstilling, en PAC-fil eller organisationens administrerede opdagelsesmekanisme. At sende almindelige webstedspakker mod proxyadressen med en rute får ikke browseren til at tale proxyprotokollen; det er transparent aflytning og hører til et andet gatewaydesign.

Skriv ned, hvilke programmer der respekterer indstillingen. Mailklienter, opdateringsprogrammer og spil gør det ofte ikke, og de vil fortsætte med at bruge den almindelige vej.

Trin 4: bevis proxyens videre forbindelse

Proxyen har brug for sin egen resolver og en tilladt rute til webstedet, plus den firewall- eller oversættelsespolitik, dens internetgrænse kræver. En browser, der når lytteren, beviser intet af det. Test den anden strøm fra proxyen selv med samme destination og port, som brugeren rapporterede.

For HTTPS åbner CONNECT en tunnel til den ønskede destination. Videresendelse giver ikke proxyen den dekrypterede side, og at deaktivere certifikatvalidering for at improvisere inspektion er ikke en løsning.

Trin 5: skelne fire fejl

En proxygodkendelsesudfordring er en 407 fra lytteren. En afvist CONNECT er en politisk beslutning på proxyen, normalt med sin egen status og loglinje. En mislykket videre forbindelse ligner en timeout eller reset, som proxyen logger mod destinationen. Et webstedssvar betyder, at begge forbindelser virkede, og at problemet er ved kilden.

Rapporter den grænse, du observerede, ikke resuméet om, at VPN’en fejlede.

Trin 6: afgræns det og planlæg fallback

Beslut, hvad der sker, når proxyen eller tunnelen ikke er tilgængelig, og sig klart, hvilken trafik dette design dækker. Det bærer webadgang fra klienter, der respekterer proxyindstillingen; det bærer ikke mail, vilkårlige enhedsprotokoller eller software, der ignorerer konfigurationen.

Validér den krævede browserhandling og en krævet afvisning under en godkendt plan, før du udvider designet til flere klienter.