Tunnel diviso contro politica aziendale: quale regola vince

Spuntare un’app in un client a tunnel diviso sembra una preferenza locale, e su un dispositivo gestito è più vicino a un cambio di politica. L’eccezione sposta il traffico dal percorso approvato, che può essere lo stesso che trasporta DNS gestito, filtraggio e l’indirizzo di origine che un servizio riconosce. Il client non si comporta male quando annulla la modifica; la distribuzione sta facendo il suo lavoro.

Prima di discutere della casella, chiarisci quale proprietà la politica esiste per proteggere.

La proprietà dietro la regola

Alcune distribuzioni instradano tutto perché il traffico passi da un gateway approvato. Altre tengono alla risoluzione dei nomi e mantengono le query sul resolver aziendale invece che su quello della rete locale. Altre ancora hanno bisogno di un indirizzo di origine stabile perché i servizi interni possano decidere se rispondere.

Un quarto gruppo impone la postura dell’endpoint: stato della crittografia del disco, livello delle patch, salute dell’agente. Dividere il tunnel non lo cambia, mentre un bypass che evita il traffico dell’agente stesso può farlo.

Sono quattro requisiti diversi e ciascuno è infranto da un’eccezione diversa. Leggi il requisito prima di proporre la modifica, perché chi l’ha scritto può dirti subito quale si applica. Una modifica che soddisfa quello sbagliato non compra nulla.

Due affermazioni vale la pena scartarle presto. Il tunnel completo non dà agli amministratori ogni pagina in chiaro, perché la crittografia delle applicazioni e i controlli degli endpoint decidono ciò che è visibile. Nemmeno il tunnel diviso è universalmente insicuro, perché DNS gestito, politiche per app e agenti degli endpoint possono reggere a prescindere dal percorso.

Esegui i controlli in ordine

La sequenza seguente riduce un’eccezione alla cosa più piccola che ha davvero fallito. Fermati al primo controllo che non regge, perché una correzione successiva non compensa una lacuna precedente.

Chiedi quale traffico ora manca il gateway approvato, poi conferma che la risoluzione dei nomi raggiunge ancora il resolver aziendale. Verifica se l’app in questione rispetta un interruttore di emergenza o se ha speso il tentativo fallito su un percorso diretto. Poi guarda i servizi condivisi: un visualizzatore di documenti o un broker degli aggiornamenti può portare l’eccezione più lontano di quanto suggerisca la casella. Infine annota se la politica si riapplica alla riconnessione, perché quel comportamento decide se una modifica locale sopravvive.

Ogni risposta è un fatto, e i fatti sono ciò che serve a una richiesta di eccezione. Una discussione su quanto sia fastidiosa la VPN non è uno di quelli. Scrivi le risposte prima che inizi la conversazione.

Chiedi un’eccezione ristretta

Riporta l’applicazione, la destinazione e l’operazione fallita, in quest’ordine. Una richiesta di mantenere un aggiornatore sul percorso diretto è esaminabile; una richiesta di aggirare il tunnel per l’intero browser non lo è.

Descrivi ciò che hai già provato e ciò che hanno mostrato i log, e indirizzala al team che possiede il profilo invece che a chi risponde all’help desk. Su un dispositivo gestito il proprietario del profilo di solito può creare un’esclusione supportata che sopravvive agli aggiornamenti, mentre una modifica locale del percorso non può.

Se la risposta è no, trattala come una decisione di progetto e non come un ostacolo da aggirare. La prossima revisione è il luogo per riaprirla, con l’operazione fallita documentata e la ragione aziendale allegata. Aggirarla rischia più di quanto l’eccezione sia mai valsa.

Rendi l’eccezione sostenibile

Dopo una modifica approvata, conferma le parti che funzionavano prima, non solo quella che era rotta. I nomi interni dovrebbero ancora risolversi tramite il resolver aziendale, le risorse private rispondere, e l’attività prima fallita ora completarsi.

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

Il primo comando dimostra che il resolver risponde ancora per un suffisso interno, e il secondo che una richiesta raggiunge il servizio interno dal percorso attuale. Esegui di nuovo dopo una riconnessione, perché un push di politica può annullare in silenzio una modifica che sembrava stabile durante il test. Due righe di output salvate con il ticket chiudono il cerchio. Senza di esse l’eccezione poggia sul ricordo di qualcuno di una pagina caricata una volta.

Registra l’eccezione, il suo scopo e i componenti che copre nello stesso posto delle note di distribuzione. Un’eccezione non documentata diventa l’incidente del trimestre successivo, e una documentata diventa prova che il progetto regge un carico di lavoro reale.