Filialnettleser til proxy: to tilkoblinger, to ruter

En filialnettleser bak en eksplisitt proxy åpner to tilkoblinger, og de feiler av ulike grunner. Den første er nettleser til proxylytter, båret gjennom filialens VPN. Den andre er proxy til nettsted, med proxyens egen resolver, rute og utgående policy. Supportbilletter som behandler dem som én strøm sender folk til feil enhet i timevis. Sett opp hver av dem bevisst og test dem i den rekkefølgen.

Trinn 1: skriv ned de to strømmene

Nettleserens umiddelbare destinasjon er proxylytteren, ikke hvert nettsted brukeren til slutt besøker. Den ene setningen løser det meste av forvirringen i dette designet.

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

Ulike kilder, ulike ruter, ulike tillatelser. Oppbevar skissen i endringsloggen, fordi hver senere kontroll viser til en av dens to halvdeler.

Trinn 2: gi nettleseren en vei til lytteren

Noter proxyens vertsnavn, lytterens port, autentiseringskravene og de tillatte filialkildene. Den listen er akseptkriteriet for den første strømmen, og den bør omfatte intern navneoppløsning så vel som tunnelruten.

Bruk en smal nettverksregel for den tiltenkte tjenesten i stedet for å publisere en ubegrenset proxy på internett. Proxyen kan bli på et internt nettverk når de tiltenkte klientene har en støttet vei til den.

Trinn 3: konfigurer nettleseren, ikke bare rutetabellen

Bruk nettleserens proxyinnstilling, en PAC-fil eller organisasjonens administrerte oppdagelsesmekanisme. Å sende vanlige nettstedspakker mot proxyadressen med en rute får ikke nettleseren til å snakke proxyprotokollen; det er transparent avlytting og hører til et annet gatewaydesign.

Skriv ned hvilke programmer som respekterer innstillingen. E-postklienter, oppdateringsprogrammer og spill gjør det ofte ikke, og de vil fortsette å bruke den enkle veien.

Trinn 4: bevis proxyens videre tilkobling

Proxyen trenger sin egen resolver og en tillatt rute til nettstedet, i tillegg til den brannmur- eller oversettelsespolitikken internettgrensen krever. En nettleser som når lytteren, beviser ingenting av dette. Test den andre strømmen fra proxyen selv, med samme destinasjon og port som brukeren rapporterte.

For HTTPS åpner CONNECT en tunnel til den forespurte destinasjonen. Vanlig videresending gir ikke proxyen den dekrypterte siden, og å slå av sertifikatvalidering for å improvisere inspeksjon er ikke en løsning.

Trinn 5: skill fire feil

En proxyautentiseringsutfordring er en 407 fra lytteren. En avvist CONNECT er en policybeslutning på proxyen, vanligvis med egen status og logglinje. En mislykket videre tilkobling ser ut som en tidsavbrudd eller tilbakestilling som proxyen logger mot destinasjonen. Et nettstedssvar betyr at begge tilkoblingene virket, og at problemet er ved kilden.

Rapporter grensen du observerte, ikke sammendraget om at VPN-en feilet.

Trinn 6: avgrens omfanget og planlegg reserve

Bestem hva som skjer når proxyen eller tunnelen ikke er tilgjengelig, og si tydelig hvilken trafikk dette designet dekker. Det bærer nettilgang fra klienter som respekterer proxyinnstillingen; det bærer ikke e-post, vilkårlige enhetsprotokoller eller programvare som ignorerer konfigurasjonen.

Valider den påkrevde nettleseroperasjonen og én påkrevd avvisning under en godkjent plan før du utvider designet til flere klienter.