Filiala retumilo al prokurilo: du konektoj, du vojoj

Filiala retumilo malantaŭ eksplicita prokurilo malfermas du konektojn, kaj ili malsukcesas pro diversaj kaŭzoj. La unua estas de la retumilo al la prokurila aŭskultanto, transportata tra la filia VPN. La dua estas de la prokurilo al la retejo, uzante la propran solvilon, vojon kaj eliran politikon de la prokurilo. Subtenaj biletoj, kiuj traktas ilin kiel unu fluon, sendas homojn al la malĝusta aparato dum horoj. Agordu ĉiun intence kaj testu ilin en tiu ordo.

Paŝo 1: skribu la du fluojn

La tuja celo de la retumilo estas la prokurila aŭskultanto, ne ĉiu retejo, kiun la uzanto finfine vizitas. Tiu unu frazo solvas la plejparton de la konfuzo en ĉi tiu dezajno.

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

Diversaj fontoj, diversaj vojoj, diversaj permesoj. Konservu la skizon en la ŝanĝprotokolo, ĉar ĉiu posta kontrolo rilatas al unu el ĝiaj du duonoj.

Paŝo 2: donu al la retumilo vojon al la aŭskultanto

Notu la prokurilan gastigantan nomon, la aŭskultantan pordon, la aŭtentikigajn postulojn kaj la permesitajn filiajn fontojn. Tiu listo estas la akceptkriterioj por la unua fluo, kaj ĝi devus inkluzivi internan nomosolvon same kiel la tunelan vojon.

Apliku mallarĝan retan regulon por la celata servo anstataŭ publikigi senliman prokurilon al la interreto. La prokurilo povas resti en interna reto, kiam ĝiaj celataj klientoj havas subtenatan vojon al ĝi.

Paŝo 3: agordu la retumilon, ne nur la vojtablon

Uzu la prokurilan agordon de la retumilo, PAC-dosieron aŭ la administritan malkovran mekanismon de la organizo. Sendi ordinarajn retejajn pakaĵojn al la prokurila adreso kun vojo ne igas la retumilon paroli la prokurilan protokolon; tio estas travidebla interkapto kaj apartenas al alia pordega dezajno.

Notu, kiuj aplikaĵoj respektas la agordon. Retpoŝtaj klientoj, ĝisdatigiloj kaj ludoj ofte ne respektas ĝin, kaj ili daŭre uzos la ordinaran vojon.

Paŝo 4: pruvu la pluan konekton de la prokurilo

La prokurilo bezonas sian propran solvilon kaj permesitan vojon al la retejo, plus ajnan fajroŝliman aŭ tradukan politikon, kiun postulas ĝia interreta limo. Retumilo, kiu atingas la aŭskultanton, pruvas nenion el tio. Testu la duan fluon el la prokurilo mem, kun la sama celo kaj pordo, kiujn la uzanto raportis.

Por HTTPS, CONNECT malfermas tunelon al la petita celo. Ordinara plusendado ne donas al la prokurilo la malĉifritan paĝon, kaj malŝalti atestilan validigon por improvizi inspekton ne estas solvo.

Paŝo 5: distingi kvar malsukcesojn

Prokurila aŭtentikiga defio estas 407 de la aŭskultanto. Rifuzita CONNECT estas politika decido en la prokurilo, kutime kun propra stato kaj protokola linio. Malsukcesa plua konekto aspektas kiel tempolimo aŭ restarigo, kiun la prokurilo registras kontraŭ la celo. Reteja respondo signifas, ke ambaŭ konektoj funkciis kaj la problemo estas ĉe la origino.

Raportu la limon, kiun vi observis, ne la resumon, ke la VPN malsukcesis.

Paŝo 6: difinu la amplekson kaj planu la rezervan vojon

Decidu, kio okazas, kiam la prokurilo aŭ la tunelo ne disponeblas, kaj diru klare, kiun trafikon ĉi tiu dezajno kovras. Ĝi portas retan aliron de klientoj, kiuj respektas la prokurilan agordon; ĝi ne portas retpoŝton, arbitrajn aparatajn protokolojn aŭ programaron, kiu ignoras la agordon.

Validigu la postulatan retumilan operacion kaj unu postulatan rifuzon laŭ aprobita plano antaŭ ol etendi la dezajnon al pliaj klientoj.