Il tuo tunnel diviso raggiunge l’app ma non il suo server DNS

Instradare la sottorete dell’app è la parte ovvia di un tunnel diviso, e non è tutto il lavoro. Il resolver spesso si trova su un indirizzo diverso da quello dell’app che serve, quindi un tunnel funzionante può comunque lasciare la risoluzione fuori. Un profilo che porta 10.80.0.0/16 e nient’altro invia la query per 10.90.0.53 attraverso l’interfaccia locale, dove non esiste alcuna zona privata. Aggiungi la rotta del resolver, poi guarda la seconda metà del problema: quale server sceglie davvero il client.

Il mito: una rotta copre tutto il servizio

Un tunnel diviso è un elenco di destinazioni che passano per la connessione, non la descrizione di un servizio. La sottorete dell’app e l’indirizzo del resolver sono due destinazioni, e un profilo può portare l’una senza l’altra. Quando succede, l’app è raggiungibile per indirizzo mentre il suo nome fallisce, il che sembra un guasto DNS più che un buco di instradamento.

Neanche la sottorete attorno al resolver è coperta automaticamente. Una rotta host verso un solo indirizzo basta per quel resolver e non apre i suoi vicini. È il senso di una rotta host: stretta per progetto, e facile da dimenticare quando il servizio successivo compare nella stessa sottorete.

Tre cose devono valere perché la risoluzione funzioni: il client instrada l’indirizzo del resolver attraverso il tunnel, il gateway accetta e inoltra quella richiesta, e il resolver accetta la sorgente che riceve. Anche la risposta deve tornare lungo il percorso concordato. Se ne manca una, il sintomo è identico, per questo vale la pena scrivere la tabella degli indirizzi prima di toccare una configurazione.

Determina quali indirizzi deve portare il profilo

Elenca le destinazioni in ordine: la rete dell’app, l’indirizzo del resolver e l’endpoint pubblico che termina il tunnel stesso. Il terzo non deve mai essere instradato nel tunnel, perché la connessione esterna ha bisogno di un percorso che esista prima del tunnel.

Includi sia UDP sia TCP per il DNS, dato che ci si aspetta che le implementazioni supportino TCP oltre a UDP, e un percorso TCP bloccato produce errori lenti e parziali invece che puliti. Se la zona privata è servita anche tramite IPv6, l’eccezione host equivalente usa un indirizzo e un prefisso IPv6 ed è una voce separata.

Annota cosa copre già il profilo prima di aggiungere qualsiasi cosa. Una rotta duplicata è innocua, ma una rotta esistente inattesa dice che il profilo è stato progettato per un piano di indirizzi diverso da quello che ti è stato dato.

Aggiungi la rotta host tramite il proprietario della connessione

Per un profilo Windows nativo gestito localmente, la rotta appartiene alla connessione e non alla tabella di routing globale della macchina. Visualizza prima l’aggiunta in anteprima, poi applicala con lo stesso ambito che usa il profilo.

Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf
Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes

Il primo comando visualizza la modifica in anteprima senza installare nulla, e il secondo elenca le rotte che il profilo porta attualmente. Il riferimento di Add-VpnConnectionRoute di Microsoft documenta gli ambiti per utente e per tutti gli utenti; un profilo per tutti gli utenti ha bisogno del proprio parametro di ambito, e un comando per utente contro un profilo per tutti gli utenti fallisce o finisce nel posto sbagliato.

Quando il profilo è gestito o proviene da un client di fornitore, la modifica appartiene a quel proprietario. Impilare una rotta di sistema permanente sopra una policy di connessione funziona finché la policy non viene riapplicata e la rotta sparisce, cosa che di solito accade durante una chiamata di supporto e non durante i test. Quel guasto è silenzioso: la rotta sparisce, il nome smette di risolversi e nessuno collega i due eventi. Metti la modifica nel registro proprio del proprietario, così la prossima riapplicazione la porta invece di cancellarla.

Dopo l’applicazione, riconnetti il profilo invece di dare per scontato che la rotta abbia effetto. Le modifiche di rotta su una connessione attiva non vengono sempre rilevate, e la riconnessione riproduce anche lo stato che i tuoi utenti avranno davvero.

Controlla quale resolver ha usato davvero il client

Una rotta controlla i pacchetti indirizzati al resolver. Non decide quali nomi vadano inviati lì, e quella selezione è un meccanismo separato. Su Windows, le regole effettive dello spazio dei nomi possono scegliere un resolver per dominio, mentre le impostazioni DNS del profilo forniscono un valore predefinito. Questi due livelli possono divergere senza produrre alcun errore, per questo una query diretta è solo metà della prova.

Get-DnsClientNrptPolicy
Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A

Il primo comando stampa la policy dello spazio dei nomi in vigore, e il secondo chiede direttamente al resolver privato il nome dell’app. Una risposta diretta dimostra che il percorso e il resolver funzionano; non dimostra che la query dell’app abbia scelto quel server. Confrontala con una query normale dello stesso nome e con la risposta che riceve l’app.

Tieni conto delle cache e del DNS sicuro a livello di browser, che può aggirare del tutto il resolver di sistema per i nomi digitati da un utente. Un suffisso di ricerca è un’altra falsa pista: espande un nome breve in uno pienamente qualificato e non ha nulla a che vedere con quale server risponde.

Chiudi riconnettendo e ripetendo la query normale, poi conferma che la navigazione ordinaria segue ancora la sua policy approvata. Sostituire il resolver privato con uno pubblico per far risolvere un nome non correlato non è una correzione, e sposta in silenzio le query private dove non sarebbero mai dovute andare.