Ang browser ng sangay sa likod ng tahasang proxy ay nagbubukas ng dalawang koneksyon, at nabibigo ang mga ito sa magkaibang dahilan. Ang una ay browser papunta sa listener ng proxy, na dinadala sa VPN ng sangay. Ang pangalawa ay proxy papunta sa website, gamit ang sariling resolver, ruta at patakaran sa labasan ng proxy. Ang mga support ticket na itinuturing silang isang daloy ay nagpapadala ng mga tao sa maling device nang maraming oras. I-configure ang bawat isa nang sadya at subukan ang mga ito sa ganoong pagkakasunod-sunod.

Hakbang 1: isulat ang dalawang daloy

Ang agarang destinasyon ng browser ay ang listener ng proxy, hindi ang bawat site na binibisita ng user sa huli. Ang nag-iisang pangungusap na iyon ay nilulutas ang karamihan ng kalituhan sa disenyong ito.

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

Iba’t ibang pinagmulan, iba’t ibang ruta, iba’t ibang pahintulot. Itago ang sketch sa talaan ng pagbabago, dahil ang bawat susunod na pagsusuri ay tumutukoy sa isa sa dalawang kalahati nito.

Hakbang 2: bigyan ang browser ng landas papunta sa listener

Itala ang hostname ng proxy, port ng listener, mga kinakailangan sa pagpapatunay at ang mga pinapayagang pinagmulan ng sangay. Ang listahang iyon ang pamantayan sa pagtanggap para sa unang daloy, at dapat nitong isama ang pribadong paglutas ng pangalan gayundin ang ruta ng tunnel.

Maglapat ng makitid na tuntunin sa network para sa inilaan na serbisyo sa halip na maglathala ng walang limitasyong proxy sa internet. Maaaring manatili ang proxy sa panloob na network kapag ang mga inilaang kliyente nito ay may sinusuportahang landas patungo rito.

Hakbang 3: i-configure ang browser, hindi lang ang talahanayan ng ruta

Gamitin ang setting ng proxy ng browser, isang PAC file o ang pinamamahalaang mekanismo ng pagtuklas ng organisasyon. Ang pagpapadala ng ordinaryong packet ng website patungo sa address ng proxy na may ruta ay hindi nagpapausap sa browser ng protocol ng proxy; iyon ay transparent na interception at kabilang sa ibang disenyo ng gateway.

Isulat kung aling mga application ang gumagalang sa setting. Ang mga mail client, updater at laro ay madalas hindi gumagalang, at patuloy nilang gagamitin ang payak na landas.

Hakbang 4: patunayan ang pasulong na koneksyon ng proxy

Kailangan ng proxy ang sarili nitong resolver at isang pinapayagang ruta patungo sa website, at ang anumang patakaran sa firewall o pagsasalin na kailangan ng hangganan nito sa internet. Ang browser na nakarating sa listener ay hindi nagpapatunay ng anuman sa mga iyon. Subukan ang pangalawang daloy mula sa proxy mismo, gamit ang parehong destinasyon at port na iniulat ng user.

Para sa HTTPS, nagbubukas ang CONNECT ng tunnel patungo sa hinihiling na destinasyon. Ang ordinaryong pagpapasa ay hindi nagbibigay sa proxy ng na-decrypt na pahina, at ang pag-off ng validation ng sertipiko para mag-improwise ng inspeksyon ay hindi solusyon.

Hakbang 5: pag-ibahin ang apat na pagkabigo

Ang hamon sa pagpapatunay ng proxy ay isang 407 mula sa listener. Ang tinanggihang CONNECT ay desisyon sa patakaran sa proxy, karaniwang may sariling status at log line. Ang nabigong pasulong na koneksyon ay mukhang timeout o reset na itinatala ng proxy laban sa destinasyon. Ang tugon ng website ay nangangahulugang gumana ang dalawang koneksyon at ang problema ay nasa pinagmulan.

Iulat ang hangganang naobserbahan mo, hindi ang buod na nabigo ang VPN.

Hakbang 6: itakda ang saklaw at planuhin ang alternatibo

Magpasya kung ano ang mangyayari kapag hindi available ang proxy o tunnel, at sabihin nang malinaw kung aling trapiko ang saklaw ng disenyong ito. Dinadala nito ang web access mula sa mga kliyenteng gumagalang sa setting ng proxy; hindi nito dinadala ang mail, arbitraryong protocol ng device o software na binabalewala ang configuration.

I-validate ang kinakailangang operasyon ng browser at isang kinakailangang pagtanggi sa ilalim ng aprubadong plano bago palawakin ang disenyo sa mas maraming kliyente.

Kaugnay na mga artikulo