VPN S2S Azure connessa ma senza traffico: leggete il log IKE

Il portale dice Connected, il tunnel ha un contatore di attività e un trace dalla vostra macchina virtuale muore al secondo hop. Lo stato della connessione descrive la negoziazione IKE e IPsec, non se un singolo pacchetto sopravvive al livello di criteri su uno dei due lati. Due guasti spiegano la maggior parte di questi ticket, e nessuno dei due si risolve cambiando una route di Azure. Entrambi sono già scritti nel log prodotto dal gateway, ed è per questo che comincio da lì e non dalla tabella delle route.

Che cosa certifica davvero Connected

Una connessione site-to-site connessa significa che le fasi 1 e 2 sono completate e che le associazioni di sicurezza sono attive. È un’affermazione sulla negoziazione: entrambi i peer hanno concordato una proposta, scambiato chiavi e installato la coppia di SA. Non dice nulla sulla corrispondenza fra i selettori di traffico e le sottoreti che considerate protette, né sul fatto che il lato remoto instraderà il pacchetto da qualche parte dopo averlo decifrato. Un tunnel può restare attivo per settimane scartando ogni flusso interessante, ed è esattamente questo schema che spinge a ricostruire un gateway sano.

I due guasti da controllare per primi sono un peer che propone AH invece di ESP, e una rete virtuale numerata in uno spazio che il gateway non tratterà come interno.

Aprire il log esportato prima di toccare le route

Nel portale, aprire il gateway di rete virtuale ed eseguire l’operazione VPN troubleshoot sulla connessione, poi scaricare il pacchetto che produce e scompattarlo. All’interno c’è un log IKE con gli scambi di fase 1 e fase 2, con marche temporali e leggibile come testo semplice. Cercatevi la riga transform invece di leggere dall’alto in basso, perché la voce interessante di solito si trova qualche centinaio di righe più sotto. Se non avete accesso al portale, gli stessi dati diagnostici compaiono nella destinazione dei log del gateway quando le impostazioni di diagnostica sono abilitate.

Due voci portano la maggior parte del valore. La prima suona più o meno expected ESP with combined authentication and cipher, received AH. La seconda è un errore di payload non valido durante lo scambio IKE, che di solito significa un campo della proposta malformato o non supportato.

Entrambe descrivono ciò che ha offerto il dispositivo locale, quindi entrambe sono impostazioni lato peer. Rigenerare il lato Azure della connessione non cambia la proposta inviata dal firewall, e farlo comunque è l’ora più spesso sprecata in questo flusso di lavoro. Sul peer, impostate la fase 2 su ESP con autenticazione e cifratura combinate e lasciate che negozi l’algoritmo, poi verificate se una casella del fornitore chiamata qualcosa come combined mode stia selezionando in silenzio una proposta AH sotto.

Confermate lo spazio di indirizzi della rete virtuale

Il gateway si aspetta che la rete virtuale stia in intervalli privati. Una rete numerata in un blocco pubblico, per esempio una che inizia con 111.x, può alzare il tunnel mentre Azure rifiuta di trattare quello spazio come interno, così la connessione sembra sana e nessun flusso viene accettato. Confermate lo spazio di indirizzi prima di passare un pomeriggio sui selettori. Se la numerazione è un requisito rigido di un’assegnazione più vecchia, la correzione è un cambio di piano di indirizzamento e non un altro gateway.

Annotate la sovrapposizione con gli intervalli locali mentre siete nel pannello dello spazio di indirizzi, perché i prefissi sovrapposti producono un guasto diverso che dal client sembra simile.

Verificate i prefissi in entrambe le direzioni

La risorsa gateway di rete locale contiene i prefissi locali, e devono corrispondere alle sottoreti che il dispositivo remoto protegge davvero. Un riepilogo che include indirizzi che il dispositivo scarta lascerà passare alcuni flussi e fallirà su altri, e questo si legge come un guasto di routing intermittente invece che come un disallineamento di configurazione. Controllate anche il lato remoto: un’estremità che elenca una /16 mentre l’altra elenca tre /24 al suo interno è il classico guasto parziale. Nessuno dei due elenchi è autorevole da solo, quindi confrontateli fianco a fianco invece di fidarvi di quello che riuscite a vedere.

Una modifica di prefisso non sempre viene recepita da sola, quindi pianificate di risalvare o ricreare l’oggetto connessione e poi confermate che i nuovi prefissi compaiano su entrambi i lati.

Provate un percorso, non un ping

Il trace che distingue un tunnel funzionante da una route funzionante è così: il primo hop è il gateway locale, poi alcuni hop che non rispondono, poi l’host remoto risponde. Se il trace non raggiunge mai l’host, provate la porta TCP che l’applicazione usa davvero, perché ICMP viene filtrato abbastanza spesso che un ping fallito dimostra ben poco. Eseguite lo stesso trace da un host remoto verso una macchina virtuale in Azure. L’asimmetria fra i due risultati è il modo più rapido per trovare una route di ritorno mancante o una regola che consente una sola direzione.

Scrivete la proposta del peer, entrambi gli spazi di indirizzi e l’ora di creazione della connessione nel ticket, così il prossimo ingegnere sa quali valori sono stati ricostruiti e quali mai toccati.

Se il log torna vuoto, il gateway potrebbe non terminare affatto la vostra connessione. Confermate che l’indirizzo del peer sul gateway di rete locale corrisponda al dispositivo da cui leggete il log, perché due gateway in un solo abbonamento si confondono facilmente durante una ricostruzione. Quell’errore costa una giornata e non lascia traccia in nessun log.