Filialwebbläsare till proxy: två anslutningar, två vägar

En filialwebbläsare bakom en explicit proxy öppnar två anslutningar, och de misslyckas av olika skäl. Den första är webbläsare till proxylyssnare, buren genom filialens VPN. Den andra är proxy till webbplats, med proxyns egen resolver, väg och utgående policy. Supportärenden som behandlar dem som ett flöde skickar folk till fel enhet i timmar. Ställ in var och en medvetet och testa dem i den ordningen.

Steg 1: skriv ned de två flödena

Webbläsarens omedelbara mål är proxylyssnaren, inte varje webbplats användaren till slut besöker. Den enda meningen löser det mesta av förvirringen i den här designen.

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

Olika källor, olika vägar, olika behörigheter. Behåll skissen i ändringsloggen, eftersom varje senare kontroll hänvisar till en av dess två halvor.

Steg 2: ge webbläsaren en väg till lyssnaren

Notera proxyns värdnamn, lyssnarens port, autentiseringskraven och de tillåtna filialkällorna. Den listan är acceptanskriteriet för det första flödet och bör omfatta både intern namnmatchning och tunnelvägen.

Tillämpa en snäv nätverksregel för den avsedda tjänsten i stället för att publicera en obegränsad proxy på internet. Proxyn kan stanna i ett internt nätverk när dess avsedda klienter har en stödd väg till den.

Steg 3: konfigurera webbläsaren, inte bara rutttabellen

Använd webbläsarens proxyinställning, en PAC-fil eller organisationens hanterade upptäcktsmekanism. Att skicka vanliga webbplats paket mot proxyadressen med en väg får inte webbläsaren att tala proxyprotokollet; det är transparent avlyssning och hör till en annan gatewaydesign.

Skriv ned vilka program som respekterar inställningen. E-postklienter, uppdaterare och spel gör det ofta inte, och de fortsätter använda den enkla vägen.

Steg 4: bevisa proxyns vidare anslutning

Proxyn behöver sin egen resolver och en tillåten väg till webbplatsen, plus den brandväggs- eller översättningspolicy som dess internetgräns kräver. En webbläsare som når lyssnaren bevisar inget av det. Testa det andra flödet från proxyn själv, med samma mål och port som användaren rapporterade.

För HTTPS öppnar CONNECT en tunnel till det begärda målet. Vanlig vidarebefordran ger inte proxyn den dekrypterade sidan, och att stänga av certifikatvalidering för att improvisera inspektion är ingen lösning.

Steg 5: skilja fyra fel

En proxyautentiseringsutmaning är en 407 från lyssnaren. En avvisad CONNECT är ett policybeslut på proxyn, vanligtvis med egen status och logglinje. En misslyckad vidare anslutning ser ut som en timeout eller återställning som proxyn loggar mot målet. Ett webbplatssvar betyder att båda anslutningarna fungerade och att problemet ligger vid källan.

Rapportera gränsen du observerade, inte sammanfattningen att VPN misslyckades.

Steg 6: avgränsa omfattningen och planera reserven

Bestäm vad som händer när proxyn eller tunneln inte är tillgänglig, och säg tydligt vilken trafik den här designen täcker. Den bär webbåtkomst från klienter som respekterar proxyinställningen; den bär inte e-post, godtyckliga enhetsprotokoll eller programvara som ignorerar konfigurationen.

Validera den nödvändiga webbläsaroperationen och en nödvändig avvisning enligt en godkänd plan innan du utökar designen till fler klienter.