La VPN da sito a sito funziona in un solo verso: due guasti diversi

Il sito A raggiunge B, B non raggiunge A, e il tunnel sembra a posto in entrambi i versi. Prima di toccare il tunnel, stabilite quale guasto avete davvero. Una nuova connessione avviata da B e rifiutata e una risposta a una connessione avviata da A che non arriva mai producono lamentele simili e diagnosi del tutto diverse. Uno è un problema di criteri o di rotta sul percorso; l’altro è un problema di percorso di ritorno o di stato per traffico già consentito.

Questa distinzione decide quali comandi vale la pena eseguire.

Due guasti che sembrano identici

Nel primo caso l’host di B invia un SYN ad A e non torna nulla. Nel secondo l’host di A apre una sessione con successo e la risposta scompare al ritorno. Entrambi gli utenti dicono che il collegamento è a senso unico, ed entrambi descrivono un pacchetto svanito, quindi la descrizione da sola non può separarli.

Chiedete quale lato ha avviato il tentativo fallito. Quel singolo fatto elimina metà delle cause possibili.

Poi verificate che il test abbia usato gli stessi host e lo stesso servizio per tutta la durata. Un ping da un lato e una connessione a una cartella condivisa dall’altro provano due cose diverse, e una diagnostica eseguita dal gateway può scegliere un indirizzo di tunnel che nessun traffico utente usa.

Caso uno: manca il percorso di ritorno

Un server remoto che risponde tramite un altro gateway predefinito può ricevere la richiesta e instradare la risposta altrove. I firewall con tracciamento dello stato scartano allora la risposta asimmetrica perché non corrisponde a un flusso stabilito, il che sembra esattamente un verso che non ha mai funzionato. La traduzione aggiunge un’altra versione: la destinazione vede un’origine tradotta e risponde a quella, quindi una regola scritta per l’indirizzo originale non corrisponde mai.

Verificate l’indirizzo che la destinazione osserva davvero dopo la traduzione, e la rotta di ritorno per quell’indirizzo invece che per la sottorete originale.

Caso due: i criteri non lo hanno mai consentito

Il caso opposto è più semplice e più frequente di quanto sembri: un ufficio deve consumare un servizio centrale e non deve mai avviare connessioni verso il centro. Quell’asimmetria è una decisione di accesso deliberata, e il tunnel funziona come progettato. Leggete i criteri di accesso prima di cambiare qualsiasi impostazione del tunnel. Il documento, non la cattura dei pacchetti, indica quale verso era previsto. Una cattura può mostrare solo ciò che è accaduto, non ciò che era autorizzato.

Se l’avvio bidirezionale è davvero necessario, aggiungete l’autorizzazione del servizio specifico tramite l’insieme di regole supportato dalla piattaforma. Rendere tutte le sottoreti reciprocamente fidate per correggere un’applicazione trasforma un requisito ristretto in un’autorizzazione ampia, e questo scambio raramente viene riesaminato in seguito.

Confrontate prima e dopo sugli stessi host

Osservate entrambe le estremità dello stesso tentativo, non due tentativi separati. Catturate sul gateway dell’host che avvia e sulla destinazione, poi confrontate cosa è entrato, cosa è uscito e quale indirizzo ha visto il lato remoto.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Se la cattura sulla destinazione mostra la richiesta con un indirizzo di origine inatteso, la risposta sta nella traduzione o nell’instradamento, non nei criteri di sicurezza del tunnel. Se la destinazione non mostra alcuna richiesta, il pacchetto non ha mai attraversato il percorso protetto.

Dopo una correzione, ripetete lo stesso test dallo stesso host e confermate che l’accesso non correlato è ancora negato. Uno stato del tunnel «established» non sostiene da solo nessuna delle due conclusioni.