Browserul sucursalei către proxy: două conexiuni, două rute

Un browser de sucursală în spatele unui proxy explicit deschide două conexiuni, iar acestea eșuează din motive diferite. Prima este de la browser la ascultătorul proxy, transportată prin VPN-ul sucursalei. A doua este de la proxy la site, folosind resolverul, ruta și politica de ieșire ale proxy-ului. Tichetele de suport care le tratează ca un singur flux trimit oamenii la dispozitivul greșit ore în șir. Configurați fiecare în mod deliberat și testați-le în această ordine.

Pasul 1: scrieți cele două fluxuri

Destinația imediată a browserului este ascultătorul proxy, nu fiecare site pe care utilizatorul îl vizitează în cele din urmă. Această singură frază rezolvă cea mai mare parte a confuziei din acest design.

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

Surse diferite, rute diferite, permisiuni diferite. Păstrați schița în registrul de modificări, deoarece fiecare verificare ulterioară se referă la una dintre cele două jumătăți ale sale.

Pasul 2: dați browserului o cale către ascultător

Înregistrați numele de gazdă al proxy-ului, portul ascultătorului, cerințele de autentificare și sursele de sucursală permise. Acea listă reprezintă criteriile de acceptare pentru primul flux și ar trebui să includă rezolvarea privată a numelor, precum și ruta tunelului.

Aplicați o regulă de rețea îngustă pentru serviciul dorit, în loc să publicați un proxy nerestricționat pe internet. Proxy-ul poate rămâne într-o rețea internă atunci când clienții săi vizați au o cale acceptată către el.

Pasul 3: configurați browserul, nu doar tabelul de rute

Folosiți setarea de proxy a browserului, un fișier PAC sau mecanismul de descoperire administrat al organizației. Trimiterea pachetelor obișnuite de site către adresa proxy cu o rută nu face browserul să vorbească protocolul proxy; aceasta este interceptare transparentă și aparține unui alt design de gateway.

Notați ce aplicații respectă setarea. Clienții de e-mail, actualizatoarele și jocurile adesea nu o respectă și vor continua să folosească calea simplă.

Pasul 4: demonstrați conexiunea de ieșire a proxy-ului

Proxy-ul are nevoie de propriul resolver și de o rută permisă către site, plus orice politică de firewall sau de traducere cerută de granița sa de internet. Un browser care ajunge la ascultător nu demonstrează nimic din toate acestea. Testați al doilea flux chiar de la proxy, cu aceeași destinație și port pe care le-a raportat utilizatorul.

Pentru HTTPS, CONNECT deschide un tunel către destinația solicitată. Transmiterea obișnuită nu îi oferă proxy-ului pagina decriptată, iar dezactivarea validării certificatelor pentru a improviza o inspecție nu este o soluție.

Pasul 5: distingeți patru defecte

O provocare de autentificare a proxy-ului este un 407 de la ascultător. Un CONNECT refuzat este o decizie de politică pe proxy, de obicei cu propriul status și propria linie de jurnal. O conexiune de ieșire eșuată arată ca un timeout sau o resetare pe care proxy-ul o înregistrează față de destinație. Un răspuns al site-ului înseamnă că ambele conexiuni au funcționat, iar problema este la origine.

Raportați granița pe care ați observat-o, nu rezumatul că VPN-ul a eșuat.

Pasul 6: delimitați domeniul și planificați soluția de rezervă

Decideți ce se întâmplă când proxy-ul sau tunelul nu sunt disponibile și spuneți clar ce trafic acoperă acest design. Transportă acces web de la clienții care respectă setarea de proxy; nu transportă e-mail, protocoale arbitrare de dispozitiv sau software care ignoră configurația.

Validați operația de browser necesară și o singură respingere necesară conform unui plan aprobat înainte de a extinde designul la mai mulți clienți.