Azure P2S VPN non riesce a risolvere il nome di un endpoint privato

Connetti il tunnel point-to-site, fai ping all'indirizzo privato, apri l'app e ottieni invece un 403 o un errore di certificato. Entrambi i sintomi puntano al DNS, ma sono guasti diversi: uno significa che il client ha risolto l'indirizzo pubblico, l'altro che ha risolto l'indirizzo privato e poi ha offerto un nome che il certificato non copre. Segui i controlli qui sotto in ordine e fermati al primo fallimento, perché una voce hosts o una risposta in cache possono far passare ogni controllo successivo per il motivo sbagliato. Tengo questo ordine in un file di testo accanto ai miei profili VPN, perché la correzione non cambia nulla del tunnel e cambia tutto di ciò che il client sa.

Parti dall'indirizzo che il client riceve davvero

Interroga direttamente il resolver invece di fidarti dell'applicazione. Su Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net mostra quale vista ha ricevuto il client. Una risposta pubblica significa che nulla più a valle raggiungerà l'endpoint; l'indirizzo privato dell'endpoint significa che il DNS è finito e che il controllo successivo è la connessione stessa.

Un endpoint privato non rinomina il servizio. L'account o l'app conserva il suo solito nome completo, e l'endpoint cambia solo l'indirizzo su cui quel nome si risolve per i client all'interno della rete virtuale. Per questo lo stesso nome host si risolve privatamente da una VM nella rete e pubblicamente da un portatile a cui non è mai stata data la vista privata.

Controlla la zona, il suo collegamento e il record prima del tunnel

Tre condizioni devono valere insieme: la zona privata esiste, è collegata alla rete virtuale da cui entrano in Azure il gateway VPN e i client, e contiene un record A per l'endpoint che punta all'indirizzo privato. Collega la zona a una rete non correlata e il gateway continuerà a risolvere il record pubblico mentre tutto il tunnel sembra sano.

I nomi delle zone appartengono ai servizi, non ai collegamenti privati in generale. App Service di solito usa privatelink.azurewebsites.net, archiviazione e SQL hanno i propri spazi dei nomi, e prendere in prestito la zona di un altro servizio produce una zona che esiste e non risponde nulla di utile.

Dai al client un resolver che possa davvero raggiungere

168.63.129.16 risponde dalle macchine virtuali di Azure e non è un server DNS per un portatile dall'altra parte di un tunnel point-to-site. Il client ha bisogno di un resolver raggiungibile attraverso il tunnel: un endpoint in ingresso di Azure DNS Private Resolver, un forwarder all'interno della rete virtuale, o voci di server DNS trasportate nel profilo del client VPN così che il client interroghi direttamente la rete virtuale.

Un resolver configurato ma irraggiungibile si comporta esattamente come nessun resolver, e il sintomo è un timeout invece di una risposta sbagliata, per questo viene letto erroneamente come problema di firewall. Provalo con una query che il tunnel dovrebbe trasportare, non con un nome pubblico che sarebbe passato comunque dal collegamento locale.

Se inoltri invece di spingere impostazioni, inoltra lo spazio dei nomi di cui è proprietaria la zona privata, privatelink.azurewebsites.net invece di tutto azurewebsites.net. Un forwarder condizionale che inghiotte l'intero suffisso padre manda ad Azure ogni ricerca del servizio, comprese quelle che dovrebbero restare locali.

Usa il nome per cui è stato emesso il certificato

Quando l'indirizzo è corretto, emerge il secondo guasto. Archiviazione e App Service pubblicano un alias privatelink, e quell'alias non è necessariamente il nome nel certificato. Un caricamento AzCopy indirizzato a privatelink.blob.core.windows.net ha fallito la convalida; lo stesso caricamento a <account>.blob.core.windows.net/<container> si è risolto all'indirizzo privato ed è passato, quindi è rimasto sul percorso privato senza alcuna deroga.

La regola vale nel browser e anche per App Service: connettiti con il nome host che il certificato copre e lascia che DNS fornisca l'indirizzo privato. Non ricorrere a un aggiramento della convalida, perché trasforma un errore di denominazione in una regressione di sicurezza. Un ping riuscito dimostra il percorso e non dice nulla del nome dentro la stretta di mano, per questo restano controlli separati.

Un ordine in quattro passi che isola ogni livello

1. Conferma che il client VPN abbia un indirizzo dal pool point-to-site e una rotta verso l'indirizzo privato dell'endpoint.
2. Risolvi il nome esatto che usa l'applicazione e confronta la risposta con l'indirizzo dell'endpoint.
3. Apri una connessione TCP verso l'endpoint sulla porta del servizio, poi leggi il nome del certificato presentato su quella connessione.
4. Solo ora prova l'autorizzazione, perché un percorso funzionante e un certificato valido non danno ancora accesso alla risorsa.

Una connessione rifiutata mentre l'indirizzo è corretto indica il gruppo di sicurezza di rete o lo stato di connessione dell'endpoint privato, non il DNS, quindi controllali prima di modificare di nuovo le impostazioni del resolver. Una mancata corrispondenza del nome TLS ti riporta al nome host nell'URL e al subject del certificato. Tieni insieme l'output della risoluzione, il nome del certificato e l'URL esatto; quei tre valori spiegano la maggior parte di questi casi senza toccare il gateway.

Usa una VM dentro la rete virtuale come controllo. Se il nome si risolve privatamente lì e pubblicamente dal tunnel, la zona e il record sono corretti e l'unica differenza è il percorso del resolver del client, che si conferma più in fretta di un'altra passata sulla configurazione dell'endpoint.

Anche i client fanno cache. Un record che ha risposto pubblicamente dieci minuti fa continua a rispondere dopo che hai corretto la zona, quindi svuota la cache prima di ritestare. Su Windows, ipconfig /flushdns svuota la cache del client; le regole dei criteri di risoluzione dei nomi persistono, decidono quale suffisso va a quale server e possono continuare a mandare lo spazio dei nomi al resolver che hai appena sostituito.

Dove va una voce hosts

Aggiungere l'indirizzo dell'endpoint a un file hosts è una buona diagnostica e un cattivo progetto. Dimostra che la mappatura nome-indirizzo è il pezzo mancante e ti lascia provare tutto ciò che viene dopo, ma è invisibile ai tuoi utenti, si rompe quando l'indirizzo dell'endpoint cambia e nasconde la zona che dovrebbe rispondere.

Una voce di prova rimasta è peggio di una cache obsoleta, perché può far sembrare rotto il percorso riparato o riparato il percorso rotto a seconda della direzione dell'errore. Rimuovila prima della passata finale e risolvi solo con il resolver di produzione.

I nomi brevi hanno bisogno di un suffisso di ricerca e i nomi completi no, quindi prova prima il nome completo, poi decidi se il flusso di lavoro ha bisogno di un suffisso spinto dal profilo client. Microsoft documenta i nomi di zona e le forme dei record per servizio nelle sue linee guida DNS per gli endpoint privati; leggi la voce del tuo servizio invece di copiare una zona da un altro.