Shfletuesi i degës te proxy-i: dy lidhje, dy rrugë

Një shfletues dege pas një proxy-i të qartë hap dy lidhje, dhe ato dështojnë për arsye të ndryshme. E para është nga shfletuesi te dëgjuesi i proxy-t, e transportuar përmes VPN-së së degës. E dyta është nga proxy-i te faqja, duke përdorur resolverin, rrugën dhe politikën e daljes të vetë proxy-t. Ticket-at e suportit që i trajtojnë si një rrjedhë të vetme dërgojnë njerëzit te pajisja e gabuar për orë të tëra. Konfiguroni secilën me qëllim dhe testojini në atë rend.

Hapi 1: shkruani dy rrjedhat

Destinacioni i menjëhershëm i shfletuesit është dëgjuesi i proxy-t, jo çdo faqe që përdoruesi viziton përfundimisht. Kjo fjali e vetme zgjidh pjesën më të madhe të konfuzionit në këtë dizajn.

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

Burime të ndryshme, rrugë të ndryshme, leje të ndryshme. Mbani skicën në regjistrin e ndryshimeve, sepse çdo kontroll i mëvonshëm i referohet njërës nga dy gjysmat e tij.

Hapi 2: jepini shfletuesit një rrugë drejt dëgjuesit

Regjistroni emrin e hostit të proxy-t, portin e dëgjuesit, kërkesat e vërtetimit dhe burimet e lejuara të degës. Ai listë janë kriteret e pranimit për rrjedhën e parë, dhe duhet të përfshijë zgjidhjen private të emrave si dhe rrugën e tunelit.

Aplikoni një rregull të ngushtë rrjeti për shërbimin e synuar në vend që të publikoni një proxy të pakufizuar në internet. Proxy-i mund të qëndrojë në një rrjet të brendshëm kur klientët e tij të synuar kanë një rrugë të mbështetur drejt tij.

Hapi 3: konfiguroni shfletuesin, jo vetëm tabelën e rrugëve

Përdorni cilësimin e proxy-t të shfletuesit, një skedar PAC ose mekanizmin e zbulimit të menaxhuar të organizatës. Dërgimi i paketave të zakonshme të faqes drejt adresës së proxy-t me një rrugë nuk e bën shfletuesin të flasë protokollin e proxy-t; kjo është interceptim transparent dhe i përket një dizajni tjetër portë.

Shkruani cilat aplikacione e respektojnë cilësimin. Klientët e postës, përditësuesit dhe lojërat shpesh nuk e bëjnë këtë, dhe do të vazhdojnë të përdorin rrugën e thjeshtë.

Hapi 4: provoni lidhjen e mëtejshme të proxy-t

Proxy-t i duhet resolveri i vet dhe një rrugë e lejuar drejt faqes, plus çdo politikë firewall-i ose përkthimi që kërkon kufiri i tij i internetit. Një shfletues që arrin dëgjuesin nuk provon asgjë nga kjo. Testoni rrjedhën e dytë nga vetë proxy-i, me të njëjtin destinacion dhe port që raportoi përdoruesi.

Për HTTPS, CONNECT hap një tunel drejt destinacionit të kërkuar. Përcjellja e zakonshme nuk i jep proxy-t faqen e dekriptuar, dhe çaktivizimi i vërtetimit të certifikatës për të improvizuar një inspektim nuk është zgjidhje.

Hapi 5: dalloni katër dështime

Një sfidë vërtetimi e proxy-t është një 407 nga dëgjuesi. Një CONNECT i refuzuar është një vendim politike në proxy, zakonisht me statusin dhe rreshtin e vet të regjistrit. Një lidhje e mëtejshme e dështuar duket si një skadim kohe ose rivendosje që proxy-i regjistron kundrejt destinacionit. Një përgjigje e faqes do të thotë që të dyja lidhjet funksionuan dhe problemi është në origjinë.

Raportoni kufirin që vëzhguat, jo përmbledhjen se VPN dështoi.

Hapi 6: përcaktoni shtrirjen dhe planifikoni alternativën

Vendosni çfarë ndodh kur proxy-i ose tuneli nuk është i disponueshëm, dhe thoni qartë cilin trafik mbulon ky dizajn. Ai mbart aksesin në web nga klientët që respektojnë cilësimin e proxy-t; nuk mbart postë, protokolle arbitrare pajisjesh ose software që injoron konfigurimin.

Vërtetoni operacionin e kërkuar të shfletuesit dhe një refuzim të kërkuar sipas një plani të miratuar përpara se ta zgjeroni dizajnin te më shumë klientë.