VM GCP con più NIC: perché le risposte escono dall’interfaccia sbagliata

Collegare una seconda interfaccia a una VM di Compute Engine le dà un altro collegamento di rete, non un percorso di ritorno simmetrico. L’ospite sceglie ancora un’interfaccia e un indirizzo di origine dalle proprie rotte e regole. Google Cloud applica poi l’instradamento VPC e la policy del firewall attorno all’interfaccia da cui è uscito il pacchetto. Quando queste due decisioni non concordano, le richieste arrivano su una NIC e le risposte escono dall’altra, e la filiale vede una conversazione semiaperta.

Percorrete il percorso in cinque passi e la discrepanza emergerà prima che scriviate una regola di policy.

Passo 1: mappate le NIC del cloud ai dispositivi dell’ospite

Il cloud nomina le interfacce nic0, nic1 e così via, e l’ospite vede nomi di dispositivo che non devono coincidere. Risolvete la corrispondenza dai metadati dell’istanza o dall’indirizzo proprio dell’interfaccia prima di ogni altra cosa. La rotta predefinita abituale fornita da DHCP è associata a nic0, ed è per questo che il percorso verso internet vince così spesso per caso. Scrivere policy su un nome di dispositivo ipotizzato è il modo in cui una regola corretta finisce sull’interfaccia sbagliata.

Annotate indirizzi, nomi di dispositivo e la VPC a cui appartiene ciascuno. Quella mappa a tre colonne è l’input di ogni passo successivo.

Passo 2: nominate le due decisioni di instradamento

La prima decisione appartiene all’ospite: quale interfaccia e quale indirizzo di origine per questo pacchetto. La seconda appartiene al cloud: ciò che le rotte della VPC e la policy del firewall consentono attorno a quell’interfaccia.

Una rotta visibile nella VPC orientata alla VPN non diventa una rotta dell’ospite che seleziona quella NIC. La rotta del cloud descrive ciò che la rete può consegnare, mentre la rotta dell’ospite decide ciò che fa il pacchetto.

Passo 3: scegliete una policy di percorso di ritorno

Per un insieme piccolo e stabile di prefissi di filiale, le rotte di destinazione esplicite nell’ospite sono l’espressione più semplice: le risposte a quei prefissi escono dall’interfaccia orientata alla VPN. Quando più servizi usano di proposito indirizzi di origine locali diversi, le regole basate sull’origine che scelgono una tabella per interfaccia mantengono ogni risposta nel contesto giusto. La documentazione sulle interfacce multiple descrive la denominazione delle NIC e il comportamento della rotta predefinita su cui questi progetti si basano.

Ogni tabella richiede rotte connesse valide e salti successivi, oltre alle destinazioni che le verranno chieste. Una regola che punta a una tabella incompleta non è un progetto di percorso di ritorno. Usate il gateway documentato per quella NIC invece di inventare un gateway Ethernet dall’aspetto della sottorete.

Passo 4: controllate i filtri propri dell’ospite

Controllate dove ascolta il server e quale origine locale porta la risposta. Un listener su tutti gli indirizzi non annulla la policy di instradamento, quindi legarsi a tutti gli indirizzi non cambia nulla riguardo all’interfaccia da cui esce la risposta.

Su Linux, riesaminate la validazione del percorso inverso rispetto al progetto previsto. Disattivarla globalmente come prima mossa scambia un bug di instradamento con un’esposizione allo spoofing, e nasconde l’asimmetria che cercavate.

Passo 5: provate un flusso per percorso

Verificate separatamente una richiesta di filiale consentita e una richiesta internet non correlata, ciascuna con la sua origine e destinazione reali. Catturate su entrambe le interfacce quando potete, perché la prova utile è quale interfaccia ha trasportato la risposta. Poi confermate che la policy lato cloud abbia rispettato il percorso che avete progettato. Una richiesta riuscita dimostra un flusso, non un progetto simmetrico.

Tenete i due test separati nelle vostre note, poiché esercitano rotte diverse e regole firewall diverse.

Ciò che una seconda NIC non vi dà

Una seconda interfaccia aggiunge un collegamento di rete e un altro indirizzo. Non aggiunge instradamento simmetrico automatico e non aggira la policy del firewall. Trattarla come una correzione di instradamento è il motivo per cui i progetti multi-NIC accumulano regole che poi nessuno sa spiegare.

Se la VM deve inoltrare il traffico di altre macchine, pianificate quel ruolo di router in modo esplicito, compresa l’impostazione cloud che consente l’inoltro e i filtri dell’ospite che la accompagnano.