Perché una VM Azure con appliance VPN perde il percorso di ritorno
Un’appliance VPN in una VM Azure ha bisogno che l’UDR, il flag di inoltro della scheda di rete e i criteri dell’ospite concordino. Seguite una richiesta di filiale attraverso tutti e tre.
Una VM Azure che esegue un’appliance VPN si trova dentro due sistemi decisionali indipendenti. Azure decide da dove un pacchetto esce da una subnet, usando tabelle di route e l’impostazione di inoltro della scheda di rete. Il sistema operativo dell’appliance decide se inoltrare il pacchetto decifrato. Un tunnel che sale perfettamente può comunque fallire sul secondo sistema, ed è lì che si fermano la maggior parte di queste distribuzioni.
Tre proprietari di un solo percorso
Prendete una rete di filiale 192.168.50.0/24 e una subnet del carico di lavoro 10.0.10.0/24, con l’appliance a 10.0.0.4 nella propria subnet. Una sola richiesta tocca tre configurazioni separate.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Ogni riga è di un team diverso nella maggior parte delle organizzazioni, ed è per questo che questo guasto di solito arriva come tre ticket invece di uno.
La route che punta all’appliance
Associate una tabella di route alla subnet del carico di lavoro e date al prefisso della filiale un salto successivo di tipo Virtual appliance con 10.0.0.4 come indirizzo. Usate l’indirizzo privato raggiungibile dell’appliance, mai il suo punto di ingresso VPN pubblico. Il salto successivo deve essere un indirizzo che la subnet del carico di lavoro può già raggiungere. Lasciate in pace il resto del routing del carico di lavoro, a meno che abbiate deciso deliberatamente di sostituire la route predefinita.
Tenete l’appliance nella propria subnet e assicuratevi che la route che invia il traffico di filiale all’appliance non catturi anche il percorso in uscita dell’appliance. Un tale ciclo sembra un tunnel sano senza risposte, ed è una cosa molto spiacevole da debuggare alle 2 di notte.
Il flag della scheda di rete che tutti dimenticano
Azure ha un’impostazione di inoltro IP per scheda di rete, ed è disattivata per impostazione predefinita. Esiste perché una scheda che inoltra riceve pacchetti indirizzati a qualcos’altro, e scartarli in silenzio è il valore predefinito sicuro per tutti gli altri.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true la attiva per un’interfaccia. Le indicazioni di Microsoft sull’ inoltro sulla scheda di rete richiedono l’impostazione su ogni scheda collegata che inoltra traffico, quindi un’appliance con una sola scheda ne ha comunque bisogno su quella scheda.
Il flag non è una route e non è una regola del firewall. Attivarlo concede un permesso e nient’altro.
Che cosa fa l’ospite con il pacchetto decifrato
Quando il tunnel termina, lo stack dell’appliance prende la decisione successiva. Su un ospite Linux, l’inoltro IPv4 è un’impostazione di runtime, e sysctl -w net.ipv4.ip_forward=1 dura fino al riavvio successivo. Salvatelo invece in un file sotto /etc/sysctl.d/ in modo permanente. Un’appliance di un fornitore ha il proprio equivalente, e le istruzioni Linux incollate in una piattaforma di fornitore di solito non fanno assolutamente nulla.
I criteri del firewall dell’ospite sono di nuovo separati, e così il gruppo di sicurezza di rete del carico di lavoro. Consentire UDP 500 e 4500 verso l’indirizzo pubblico della VM protegge il tunnel; non dice nulla sulla possibilità che una richiesta di filiale decifrata raggiunga una porta del carico di lavoro.
Seguite una richiesta e la sua risposta
Scegliete un flusso consentito e seguitelo da un capo all’altro. La filiale ha bisogno di una route per 10.0.10.0/24 attraverso la connessione di sito, l’appliance ha bisogno di un percorso di consegna verso la subnet del carico di lavoro, e la subnet del carico di lavoro ha bisogno di una route di ritorno verso la filiale.
Decidete presto se il progetto conserva l’indirizzo di origine della filiale o lo traduce. Il NAT cambia ciò che vede il carico di lavoro, quindi le sue regole di accesso dovrebbero descrivere il modello che avete scelto davvero e non un indirizzo di gateway ipotizzato.
Una stretta di mano riuscita dimostra un anello di quella catena. Il percorso è completo quando la risposta torna attraverso la stessa appliance e i criteri del carico di lavoro stesso lo consentono.