Filialnettlesar til proxy: to tilkoplingar, to ruter

Ein filialnettlesar bak ein eksplisitt proxy opnar to tilkoplingar, og dei feilar av ulike grunnar. Den første er nettlesar til proxylyttar, bor gjennom filialens VPN. Den andre er proxy til nettstad, med proxyens eigen resolver, rute og utgåande policy. Støttebillettar som handsamar dei som éin straum sender folk til feil eining i timevis. Set opp kvar av dei med vilje og test dei i den rekkjefølgja.

Steg 1: skriv ned dei to straumane

Den umiddelbare destinasjonen til nettlesaren er proxylyttaren, ikkje kvar nettstad brukaren til slutt vitjar. Den eine setninga løyser det meste av forvirringa i dette designet.

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

Ulike kjelder, ulike ruter, ulike løyve. Oppbevar skissen i endringsloggen, fordi kvar seinare kontroll viser til ein av dei to halvdelane hans.

Steg 2: gje nettlesaren ein veg til lyttaren

Noter vertsnamnet til proxyen, porten til lyttaren, autentiseringskrava og dei tillatne filialkjeldene. Den lista er akseptkriteriet for den første straumen, og ho bør omfatte intern namneoppløysing så vel som tunnelruta.

Bruk ein smal nettverksregel for den tiltenkte tenesta i staden for å publisere ein ubegrensa proxy på internett. Proxyen kan bli på eit internt nettverk når dei tiltenkte klientane har ein støtta veg til han.

Steg 3: konfigurer nettlesaren, ikkje berre rutetabellen

Bruk proxyinnstillinga til nettlesaren, ei PAC-fil eller den administrerte oppdagingsmekanismen til organisasjonen. Å sende vanlege nettstadpakkar mot proxyadressa med ei rute får ikkje nettlesaren til å snakke proxyprotokollen; det er transparent avlytting og høyrer til eit anna gatewaydesign.

Skriv ned kva program som respekterer innstillinga. E-postklientar, oppdateringsprogram og spel gjer det ofte ikkje, og dei vil halde fram med å bruke den enkle vegen.

Steg 4: prov den vidare tilkoplinga til proxyen

Proxyen treng sin eigen resolver og ei tillaten rute til nettstaden, i tillegg til den brannmur- eller omsetjingspolitikken internettgrensa krev. Ein nettlesar som når lyttaren, provar ingenting av dette. Test den andre straumen frå proxyen sjølv, med same destinasjon og port som brukaren rapporterte.

For HTTPS opnar CONNECT ein tunnel til den førespurde destinasjonen. Vanleg vidaresending gjev ikkje proxyen den dekrypterte sida, og å slå av sertifikatvalidering for å improvisere inspeksjon er ikkje ei løysing.

Steg 5: skil fire feil

Ei proxyautentiseringsutfordring er ein 407 frå lyttaren. Ein avvist CONNECT er ei policyavgjerd på proxyen, vanlegvis med eigen status og logglinje. Ei mislukka vidare tilkopling ser ut som ein tidsavbrot eller tilbakestilling som proxyen loggar mot destinasjonen. Eit nettstadssvar tyder på at begge tilkoplingane verka, og at problemet er ved kjelda.

Rapporter grensa du observerte, ikkje samandraget om at VPN-en feila.

Steg 6: avgrens omfanget og planlegg reserve

Avgjer kva som skjer når proxyen eller tunnelen ikkje er tilgjengeleg, og sei tydeleg kva trafikk dette designet dekkjer. Det ber nettilgang frå klientar som respekterer proxyinnstillinga; det ber ikkje e-post, vilkårlege einingprotokollar eller programvare som ignorerer konfigurasjonen.

Valider den påkravde nettlesaroperasjonen og éin påkravd avvising under ein godkjend plan før du utvidar designet til fleire klientar.