Quale pacchetto deve intercettare una politica VPN a doppio WAN?

Le richieste di instradare la VPN sul secondo collegamento descrivono almeno due compiti diversi, e la politica che ne sistema uno non tocca l’altro. Nel primo compito il trasporto cifrato tra due estremi passa a un altro indirizzo WAN. Nel secondo il flusso applicativo decifrato di un utente connesso esce verso un altro hop successivo. Entrambi sono legittimi, entrambi usano l’instradamento, e ciascuno richiede una corrispondenza su un pacchetto che esiste nel punto in cui viene presa la decisione. Seguite i controlli qui sotto in ordine, perché il primo determina quale pacchetto devono nominare le regole successive.

Nominate le due conversazioni

Immaginate un lavoratore remoto collegato a un gateway di ufficio, che apre HTTPS verso un server applicativo interno. Ci sono due conversazioni indipendenti sul filo, e hanno indirizzi diversi a ciascuna estremità. La conversazione esterna va tra i due estremi della VPN: dall’indirizzo del gateway all’indirizzo del peer, con il protocollo e la porta che l’implementazione ha negoziato. La conversazione interna va dall’indirizzo assegnato al client all’indirizzo del server applicativo sulla porta 443.

La porta di destinazione dell’applicazione non è la porta di trasporto della VPN, e nessuna quantità di politica su TCP 443 sposterà il tunnel. Allo stesso modo, una regola che reindirizza l’indirizzo di trasporto del peer non dice nulla su dove vada la richiesta HTTP di quell’utente dopo la decifratura. Annotate entrambe le conversazioni con i loro indirizzi reali prima di toccare una regola, perché la maggior parte della confusione in questo campo nasce dal nominare una e configurare l’altra.

Trovate dove la vostra politica vede davvero il pacchetto

La corrispondenza va valutata nella catena e nello spazio dei nomi in cui il pacchetto è ancora nella forma che avete descritto. Una regola agganciata all’ingresso LAN vede il pacchetto interno, non cifrato, prima che venga instradato verso il tunnel. Una regola applicata al traffico generato localmente vede i pacchetti che il gateway stesso produce, e non copre automaticamente il traffico che il gateway si limita a inoltrare. L’uscita incapsulata è ancora un terzo caso, di solito gestito sull’interfaccia che porta il tunnel e non sul lato LAN.

Ecco perché lo stesso frammento di configurazione si comporta diversamente su due piattaforme: i punti di aggancio differiscono, e l’hook di politica di un fornitore può stare prima o dopo la fase di cifratura. Leggete il percorso del pacchetto per il prodotto specifico invece di presumere l’ordine dal diagramma di un altro fornitore.

Confermate il trasporto negoziato

Per IPsec incapsulato in UDP, RFC 3948 mette ESP dentro UDP e usa un marcatore non-ESP per mantenere IKE distinguibile sulla porta condivisa. L’ESP semplice è un protocollo IP, non una porta TCP o UDP, quindi una regola di firewall scritta su un numero di porta non lo intercetterà affatto. Questa distinzione decide se la vostra politica WAN necessita di una regola UDP, di una regola di protocollo o di entrambe.

I valori negoziati battono quelli ricordati. Leggete le porte e gli indirizzi attuali dell’associazione dal dispositivo invece di aggiungere TCP 4500 o una vecchia porta del fornitore per sicurezza, cosa che cattura traffico non correlato e nasconde il vero problema di classificazione.

Controllate il percorso di ritorno prima di impegnarvi

Il successo in uscita dimostra metà di un progetto. Un pacchetto che torna verso il pool di client remoti non è più visibile sotto l’indirizzo del client quando l’incapsulamento lo sostituisce: la destinazione esterna è l’indirizzo di trasporto del peer. Se il secondo collegamento raggiunge quel peer tramite un operatore diverso, la sua traduzione e il suo filtraggio possono discordare dalla prima, e l’associazione potrebbe dover essere ricostruita anziché migrata.

Lo stato della traduzione degli indirizzi di rete è la vittima abituale di un cambio di WAN. Annotate il collegamento scelto, l’indirizzo sorgente esterno atteso, la traduzione in uso e la raggiungibilità del peer di ritorno, poi mantenete il trasporto raggiungibile senza spedirlo nel tunnel che trasporta.

Verificate entrambi i livelli con due catture

Una cattura sull’interfaccia WAN e una dentro il tunnel risolvono la questione più in fretta di qualsiasi confronto di configurazione. Eseguitele dal gateway mentre un client approvato effettua una sola richiesta, e conservate entrambi i file.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

La prima cattura dovrebbe mostrare la conversazione esterna che lascia l’interfaccia che intendevate, con l’indirizzo sorgente atteso. La seconda dovrebbe mostrare la conversazione interna una volta sola, non duplicata, con l’indirizzo del client come sorgente e il server applicativo come destinazione. La ricerca di rotta conferma quale tabella il router userebbe per quella coppia sorgente e destinazione, ed è lì che di solito compare un errore di politica. Se una delle catture non compare, il punto di decisione è altrove rispetto a dove è stata agganciata la regola, e la correzione appartiene a quel punto e non a una corrispondenza più ampia.