Pubblicare un servizio interno su un VPN site-to-site ASA

Pubblicare un servizio che vive dietro un VPN site-to-site è un unico compito con cinque punti di guasto, e falliscono in un ordine fisso. Il tunnel sale, la traduzione combacia, la filiale risponde e la risposta torna per lo stesso percorso. Quando uno di questi è sbagliato, il browser mostra la stessa cosa: una connessione che si blocca o viene reimpostata. Percorri l’elenco dall’alto verso il basso e fermati al primo controllo che fallisce.

Controllo 1: il tunnel protegge l’indirizzo di origine

Parti da un tunnel che già trasporta traffico, poi conferma che l’indirizzo che intendi pubblicare si trova nell’intervallo protetto. Su un ASA quell’intervallo deriva dall’ACL di crittografia o dalle route di un VTI, e deve coprire l’indirizzo reale dell’origine, non la sottorete che la filiale usa per la gestione. Un selettore che manca l’origine ti lascia un tunnel attivo e un flusso che non vi entra mai.

Confermalo con i contatori del tunnel e la tabella delle route prima di toccare la traduzione. Se l’origine non è raggiungibile dall’hub attraverso il tunnel, niente più avanti in questo elenco può ripararlo.

Fermati qui se l’intervallo protetto e l’indirizzo di origine non concordano.

Controllo 2: decidi quale origine vedrà la filiale

La filiale vede l’indirizzo originale del client oppure uno tradotto, e questa scelta decide il percorso di ritorno. Conservare l’indirizzo del client si legge più pulito nei log dell’origine, ma allora la filiale deve rimandare le risposte per i client pubblici attraverso il tunnel; una normale route predefinita internet le manda dall’altra parte e la connessione muore in una direzione. Tradurre l’origine in un indirizzo che la filiale instrada già sul tunnel elimina questo requisito.

La traduzione cambia anche cosa l’origine può registrare e cosa possono corrispondere le regole basate sull’origine. Se l’applicazione deve conoscere la persona dietro una richiesta, il posto è un proxy inverso autenticato, non una decisione NAT.

Controllo 3: scrivi la traduzione sulle interfacce reali

Un ASA valuta le regole di traduzione in ordine e segnala quale ha corrisposto, quindi la coppia di interfacce dentro la regola non è cosmetica. Una regola scritta per un percorso da fuori a dentro non corrisponderà a un flusso la cui entrata e uscita differiscono da quelle ipotizzate.

Il percorso che stai costruendo ha quattro tratti, e tutti e quattro devono concordare:

Tratta gli intervalli di quella tabella come segnaposto. L’importante è che la tupla dopo la traduzione sia un indirizzo che la filiale accetta attraverso il tunnel, e che la mappatura inversa esista nello stato NAT perché la risposta venga ripristinata in uscita.

Controllo 4: limita la regola di accesso alla porta pubblicata

Pubblica la porta, non l’host. Una regola che consente l’origine su ogni servizio trasforma un’applicazione pubblicata in un percorso verso tutto ciò che l’origine esegue, compresa l’interfaccia di gestione che hai tenuto fuori da internet di proposito. Consenti la porta pubblicata dall’origine tradotta all’origine, e lascia i servizi amministrativi sul loro percorso solo-VPN.

Controlla l’ordine delle regole nello stesso momento. Un permesso ampio sopra la tua regola specifica rende invisibile la regola specifica.

Controllo 5: traccia una richiesta e la sua risposta

Non iniziare da un browser, perché un browser nasconde quale tratto è fallito. Traccia il flusso sull’hub e leggi il risultato prima di cambiare qualcosa.

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

La traccia nomina la traduzione che ha corrisposto, la regola di accesso che ha permesso o negato il flusso e se il pacchetto è stato instradato nel tunnel. Se mostra il flusso uscire da un’interfaccia che non ti aspettavi, la coppia di interfacce nella regola NAT è sbagliata. Se mostra un diniego, l’ordine delle regole è sbagliato. Se arriva al tunnel ma l’origine non risponde mai, il problema è il percorso di ritorno della filiale.

Poi invia una richiesta reale dall’esterno e conferma che la risposta torna per lo stesso tunnel. Registra la voce pubblicata, la traduzione, la coppia di indirizzi protetta e la route di ritorno come registro di pubblicazione.