Filiāles pārlūks uz starpniekserveri: divi savienojumi, divi maršruti

Filiāles pārlūks aiz skaidra starpniekservera atver divus savienojumus, un tie neizdodas dažādu iemeslu dēļ. Pirmais ir no pārlūka uz starpniekservera klausītāju, kas tiek pārvadīts caur filiāles VPN. Otrais ir no starpniekservera uz vietni, izmantojot paša starpniekservera resolveri, maršrutu un izejas politiku. Atbalsta pieteikumi, kas tos uzskata par vienu plūsmu, stundām ilgi sūta cilvēkus pie nepareizās ierīces. Iestatiet katru apzināti un pārbaudiet tos šajā secībā.

1. solis: pierakstiet abas plūsmas

Pārlūka tiešais galamērķis ir starpniekservera klausītājs, nevis katra vietne, ko lietotājs beigu beigās apmeklē. Šis viens teikums atrisina lielāko daļu šī dizaina neskaidrību.

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

Dažādi avoti, dažādi maršruti, dažādas atļaujas. Saglabājiet skici izmaiņu reģistrā, jo katra turpmākā pārbaude atsaucas uz vienu no tās divām pusēm.

2. solis: dodiet pārlūkam ceļu uz klausītāju

Pierakstiet starpniekservera resursdatora nosaukumu, klausītāja portu, autentifikācijas prasības un atļautos filiāles avotus. Šis saraksts ir pirmās plūsmas pieņemšanas kritērijs, un tam jāietver gan iekšējā nosaukumu izšķiršana, gan tuneļa maršruts.

Piemērojiet šauru tīkla noteikumu paredzētajam pakalpojumam, nevis publicējiet neierobežotu starpniekserveri internetā. Starpniekserveris var palikt iekšējā tīklā, ja tā paredzētajiem klientiem ir atbalstīts ceļš uz to.

3. solis: konfigurējiet pārlūku, ne tikai maršrutu tabulu

Izmantojiet pārlūka starpniekservera iestatījumu, PAC failu vai organizācijas pārvaldīto atklāšanas mehānismu. Parastu vietnes pakešu sūtīšana ar maršrutu uz starpniekservera adresi neliek pārlūkam runāt starpniekservera protokolā; tā ir caurskatāma pārtveršana, un tā pieder citam vārtejas dizainam.

Pierakstiet, kuras programmas ievēro iestatījumu. Pasta klienti, atjauninātāji un spēles to bieži nedara, un tie turpinās izmantot vienkāršo ceļu.

4. solis: pierādiet starpniekservera izejošo savienojumu

Starpniekserverim ir vajadzīgs savs resolvers un atļauts maršruts uz vietni, kā arī jebkura ugunsmūra vai tulkošanas politika, ko prasa tā interneta robeža. Pārlūks, kas sasniedz klausītāju, neko no tā nepierāda. Pārbaudiet otro plūsmu no paša starpniekservera, ar to pašu galamērķi un portu, ko lietotājs ziņoja.

HTTPS gadījumā CONNECT atver tuneli uz pieprasīto galamērķi. Parasta pārsūtīšana nepiegādā starpniekserverim atšifrēto lapu, un sertifikātu validācijas izslēgšana, lai improvizētu pārbaudi, nav risinājums.

5. solis: atšķiriet četras kļūmes

Starpniekservera autentifikācijas izaicinājums ir 407 no klausītāja. Noraidīts CONNECT ir politikas lēmums starpniekserverī, parasti ar savu statusu un žurnāla rindu. Neizdevies izejošais savienojums izskatās kā taimauts vai atiestatīšana, ko starpniekserveris reģistrē attiecībā uz galamērķi. Vietnes atbilde nozīmē, ka abi savienojumi darbojās un problēma ir avotā.

Ziņojiet par novēroto robežu, nevis kopsavilkumu, ka VPN neizdevās.

6. solis: definējiet apjomu un plānojiet rezerves variantu

Izlemiet, kas notiek, kad starpniekserveris vai tunelis nav pieejams, un skaidri sakiet, kādu trafiku šis dizains aptver. Tas pārvadā tīmekļa piekļuvi no klientiem, kas ievēro starpniekservera iestatījumu; tas nepārvadā pastu, patvaļīgus ierīces protokolus vai programmatūru, kas ignorē konfigurāciju.

Validējiet nepieciešamo pārlūka darbību un vienu nepieciešamo atteikumu saskaņā ar apstiprinātu plānu, pirms paplašināt dizainu uz vairāk klientiem.