Perché un endpoint privato risponde ancora con un indirizzo pubblico

Il portatile si connette, il tunnel si dichiara attivo e l'account di archiviazione rifiuta ancora ogni richiesta. L'endpoint privato esiste, la rotta verso la sua subnet esiste, e il nome o risponde con un indirizzo pubblico o non si risolve. Niente è sbagliato nel tunnel: al client non è mai stato detto quale server dovesse rispondere per quel nome. Seguite la query verso l'esterno e il divario diventa evidente.

Iniziate dal resolver del client

Chiedete al client quale server interroga mentre il tunnel è attivo. Un profilo point-to-site fornisce quell'indirizzo, e un profilo che non fornisce nulla lascia che il sistema operativo ripieghi sui valori predefiniti della scheda di rete.

I resolver pubblici non hanno alcuna visione di una zona privata, quindi rispondono da Internet, che è esattamente il loro compito. Il primo controllo è quindi l'indirizzo del resolver in uso, non il tunnel e non l'endpoint.

Leggete cos'è davvero la risposta

Risolvete il nome del servizio e leggete l'indirizzo che torna. Una risposta pubblica significa che la query ha raggiunto un server che non può vedere la zona. Nessuna risposta significa che il nome esiste solo privatamente e che nulla di raggiungibile dal client lo detiene.

Questi due esiti producono errori applicativi simili e appartengono a proprietari diversi. Uno è un problema di scelta del resolver, l'altro è un collegamento di zona mancante.

Una voce hosts dimostra il percorso, poi mente

Mettere l'indirizzo dell'endpoint nel file hosts locale è il modo più rapido per dimostrare che il tunnel e il firewall del servizio funzionano già. Se la richiesta riesce con quella voce, è rotta solo la risoluzione dei nomi. È anche una modifica per macchina che copre esattamente un nome.

Non aiuta il secondo account, il secondo endpoint o un collega, e si rompe senza avviso quando l'endpoint viene ricreato su un nuovo indirizzo.

Peggio, fa comportare la vostra macchina diversamente da tutte le altre, ed è così che un guasto del resolver sopravvive a una settimana di indagini. Usatela per confermare il percorso, poi toglietela e correggete la causa.

Collegate la zona e distribuite un resolver

Due condizioni devono valere contemporaneamente. La zona privata deve essere collegata alla rete virtuale in cui vive l'endpoint, e il client deve inviare le sue query a un server che possa leggere quella zona. Un endpoint in ingresso di DNS Private Resolver fornisce un indirizzo simile all'interno della rete e risponde alle query che arrivano dal tunnel. Mettete quell'indirizzo nel profilo VPN e aggiungete il suffisso privato che il client deve applicare.

Un resolver locale già esistente può ottenere lo stesso risultato tramite un forwarder condizionale indirizzato alla zona.

Le regole di rete sul resolver contano quanto l'instradamento. Se la regola in ingresso esclude l'intervallo dei client VPN, le query scadono invece di restituire una risposta errata. È quella scadenza che riporta le persone a una tabella di routing dove nulla è sbagliato.

Controllate nome, porta e identità nell'ordine

Lavorate nell'ordine: risolvete il nome, confermate che la risposta è privata, aprite la porta, poi fate una richiesta autenticata. Ogni fase ha il suo proprietario e la sua firma di guasto.

Una risposta privata seguita da una scadenza indica una rotta o un firewall. Una risposta pubblica indica il resolver. Una connessione completata che restituisce un errore di identità appartiene al servizio.

Un altro guasto appartiene a questo elenco. Un firewall del servizio che consente un indirizzo client smette di corrispondere quando il pool assegna quell'indirizzo a un'altra sessione dopo la riconnessione. Leggete l'indirizzo del chiamante registrato dal servizio, non quello che il client crede di avere. I due sono in disaccordo più spesso di quanto le persone si aspettino. La guida di Azure DNS Private Resolver copre il collegamento della zona e la disposizione dell'inoltro.