Takblaaier na die proxy: twee verbindings, twee roetes
Die blaaier praat met die proxy-luisteraar, en die proxy praat met die webwerf. Stel albei verbindings op en toets hulle as twee afsonderlike foute.
’n Takblaaier agter ’n eksplisiete proxy maak twee verbindings oop, en hulle misluk om verskillende redes. Die eerste is blaaier na proxy-luisteraar, gedra deur die tak-VPN. Die tweede is proxy na webwerf, met die proxy se eie resolver, roete en uitgangsbeleid. Ondersteuningskaartjies wat hulle as een vloei behandel, stuur mense vir ure na die verkeerde toestel. Stel elkeen doelbewus op en toets hulle in daardie volgorde.
Stap 1: skryf die twee vloeie neer
Die blaaier se onmiddellike bestemming is die proxy-luisteraar, nie elke werf wat die gebruiker uiteindelik besoek nie. Daardie een sin los die meeste verwarring in hierdie ontwerp op.
branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> websiteVerskillende bronne, verskillende roetes, verskillende toestemmings. Hou die skets in die veranderingsrekord, want elke latere kontrole verwys na een van sy twee helftes.
Stap 2: gee die blaaier ’n pad na die luisteraar
Teken die proxy-gasheernaam, die luisteraarpoort, die verifikasievereistes en die toegelate takbronne aan. Daardie lys is die aanvaardingskriteria vir die eerste vloei, en dit moet private naamresolusie sowel as die tonnelroete insluit.
Pas ’n nou netwerkreeël op die beoogde diens toe eerder as om ’n onbeperkte proxy op die internet te publiseer. Die proxy kan op ’n interne netwerk bly wanneer sy beoogde kliënte ’n ondersteunde pad daarheen het.
Stap 3: stel die blaaier op, nie net die roetetabel nie
Gebruik die blaaier se proxy-instelling, ’n PAC-lêer of die organisasie se bestuurde ontdekkingsmeganisme. Om gewone webwerf-pakkette met ’n roete na die proxy-adres te stuur, maak nie dat die blaaier die proxy-protokol praat nie; dit is deursigtige onderskepping en hoort by ’n ander poortontwerp.
Skryf neer watter toepassings die instelling eerbiedig. E-poskliënte, opdaterings en speletjies doen dit dikwels nie, en hulle sal aanhou om die gewone pad te gebruik.
Stap 4: bewys die proxy se uitgaande verbinding
Die proxy benodig sy eie resolver en ’n toegelate roete na die webwerf, plus watter vuurmuur- of vertaalbeleid sy internetgrens ook al vereis. ’n Blaaier wat die luisteraar bereik, bewys niks daarvan nie. Toets die tweede vloei vanaf die proxy self, met dieselfde bestemming en poort wat die gebruiker gerapporteer het.
Vir HTTPS maak CONNECT ’n tonnel na die versoekte bestemming oop. Gewone aanstuur gee nie die ontsyferde bladsy aan die proxy nie, en om sertifikaatvalidering af te skakel om inspeksie te improviseer, is nie ’n oplossing nie.
Stap 5: onderskei vier foute
’n Proxy-verifikasie-uitdaging is ’n 407 van die luisteraar. ’n Geweierde CONNECT is ’n beleidsbesluit op die proxy, gewoonlik met sy eie status en logreël. ’n Mislukte uitgaande verbinding lyk soos ’n tydsverloop of herstel wat die proxy teen die bestemming log. ’n Webwerf-reaksie beteken albei verbindings het gewerk en die probleem is by die oorsprong.
Rapporteer die grens wat jy gesien het, nie die opsomming dat die VPN gefaal het nie.
Stap 6: bepaal die omvang en beplan die terugval
Besluit wat gebeur wanneer die proxy of die tonnel onbeskikbaar is, en sê duidelik watter verkeer hierdie ontwerp dek. Dit dra webtoegang van kliënte wat die proxy-instelling eerbiedig; dit dra nie e-pos, willekeurige toestelprotokolle of sagteware wat die konfigurasie ignoreer nie.
Valideer die vereiste blaaier-bewerking en een vereiste weiering onder ’n goedgekeurde plan voordat jy die ontwerp na meer kliënte uitbrei.