Split tunneling nasuprot korporativnoj politici: koje pravilo pobjeđuje

Označavanje jedne aplikacije u split-tunnel klijentu izgleda kao lokalna preferencija, a na upravljanom uređaju bliže je promjeni politike. Iznimka pomiče promet s odobrenog puta, koji može biti isti put kojim idu upravljani DNS, filtriranje i izvorna adresa koju usluga prepoznaje. Klijent se ne ponaša pogrešno kada poništi vašu izmjenu; implementacija radi svoj posao.

Prije nego se posvađate oko potvrdnog okvira, utvrdite koje svojstvo politika štiti.

Svojstvo iza pravila

Neke implementacije usmjeravaju sve kako bi sav promet prošao odobrenim pristupnikom. Drugima je važno razrješavanje naziva, pa upite drže na korporativnom razrješivaču, a ne na onom lokalne mreže. Treći trebaju stabilnu izvornu adresu kako bi interne usluge mogle odlučiti hoće li uopće odgovoriti.

Četvrta skupina provodi stanje krajnje točke: status šifriranja diska, razinu zakrpa, zdravlje agenta. Dijeljenje tunela to ne mijenja, dok zaobilaženje koje izbjegava vlastiti promet agenta može.

To su četiri različita zahtjeva i svaki kvari druga iznimka. Pročitajte zahtjev prije nego predložite promjenu, jer će vam osoba koja ga je napisala odmah reći koji vrijedi. Promjena koja zadovoljava pogrešan ne kupuje ništa.

Dvije tvrdnje vrijedi rano odbaciti. Potpuno tuneliranje ne daje administratorima svaku stranicu u čistom tekstu, jer šifriranje aplikacija i kontrole krajnjih točaka određuju što je vidljivo. Dijeljenje tunela također nije univerzalno nesigurno, jer upravljani DNS, pravila po aplikaciji i agenti krajnjih točaka mogu vrijediti bez obzira na rutu.

Provedite provjere po redu

Slijed u nastavku sužava iznimku na najmanju stvar koja je doista zakazala. Zaustavite se na prvoj provjeri koja ne vrijedi, jer kasniji popravak ne može nadoknaditi raniji propust.

Pitajte koji promet sada promašuje odobreni pristupnik, zatim potvrdite da razrješavanje naziva još stiže do korporativnog razrješivača. Provjerite poštuje li dotična aplikacija prekidač i je li neuspjeli pokušaj potrošila na izravnoj ruti. Zatim pogledajte dijeljene usluge: preglednik dokumenata ili broker za ažuriranja može iznimku odnijeti dalje nego što okvir sugerira. Na kraju zabilježite primjenjuje li se politika ponovno pri ponovnom spajanju, jer to ponašanje odlučuje hoće li lokalna promjena preživjeti.

Svaki je odgovor činjenica, a zahtjevu za iznimku potrebne su činjenice. Rasprava o tome je li VPN dosadan nije jedna od njih. Zapišite odgovore prije nego razgovor počne.

Zatražite usku iznimku

Prijavite aplikaciju, odredište i radnju koja je zakazala, tim redom. Zahtjev da jedan program za ažuriranje ostane na izravnom putu može se pregledati; zahtjev da se tunel zaobiđe za cijeli preglednik ne može.

Opišite što ste već pokušali i što su zapisi pokazali, i uputite to timu koji posjeduje profil, a ne osobi koja odgovara na korisničkoj podršci. Na upravljanom uređaju vlasnik profila obično može stvoriti podržanu iznimku koja preživljava ažuriranja, dok lokalna izmjena rute ne može.

Ako je odgovor ne, tretirajte to kao odluku o dizajnu, a ne kao prepreku koju treba obići. Sljedeći je pregled mjesto da se to ponovno otvori, s dokumentiranom neuspjelom radnjom i priloženim poslovnim razlogom. Zaobilaženje riskira više nego što je iznimka ikada vrijedila.

Učinite iznimku održivom

Nakon odobrene promjene potvrdite dijelove koji su prije radili, a ne samo dio koji je bio pokvaren. Interni nazivi trebaju se i dalje razrješavati preko korporativnog razrješivača, privatni resursi odgovarati, a prije neuspjeli zadatak sada dovršiti.

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

Prva naredba dokazuje da razrješivač još odgovara na interni sufiks, a druga da zahtjev stiže do interne usluge s trenutne rute. Pokrenite ih ponovno nakon ponovnog spajanja, jer slanje politike može tiho poništiti promjenu koja je tijekom testa izgledala stabilno. Dva retka izlaza spremljena uz tiket zatvaraju krug. Bez njih iznimka počiva na nečijem sjećanju na stranicu koja se jednom učitala.

Zabilježite iznimku, njezinu svrhu i komponente koje pokriva na istom mjestu kao i bilješke o implementaciji. Nedokumentirana iznimka postaje incident sljedećeg tromjesečja, a dokumentirana postaje dokaz da dizajn podnosi stvarni radni teret.