Il controllo origine/destinazione è un cancello, non tutto il percorso VPN
Un'istanza di inoltro necessita di autorizzazione AWS, oltre a rotte Linux e regole del firewall. Verificate la validazione origine/destinazione sull'istanza che inoltra.
La VPN termina su un'istanza EC2, potete raggiungere l'indirizzo del tunnel di quell'istanza, e il traffico destinato ad attraversarla verso un altro host privato scompare. Sono due test diversi, e mescolarli fa perdere ore. Il primo chiede se riuscite a raggiungere l'istanza; il secondo le chiede di inoltrare traffico per una destinazione che non è la sua, il che richiede inoltro Linux, una politica del firewall, una rotta dall'altra parte e un'autorizzazione a livello AWS che non ha nulla a che vedere con il sistema operativo ospite. Nulla nella console richiama l'attenzione su questa differenza. Il sintomo sembra un guasto di routing, e di solito non lo è.
Separate i due test prima di cambiare qualcosa
Raggiungere il gateway dimostra il tunnel, la rotta verso il suo indirizzo e il gruppo di sicurezza che consente lo scambio. L'inoltro per un altro host non dimostra nulla di tutto ciò: usa un indirizzo di origine diverso, una destinazione diversa e un'istanza in un ruolo per cui non è necessariamente stata costruita. Scrivete i due test separatamente e annotate quale fallisce, perché la correzione di ciascuno vive in una console diversa. Un'istanza gateway costruita solo per terminare tunnel non ha motivo di inoltrare per altro, e i suoi valori predefiniti lo riflettono. Per questo il secondo test richiede una propria configurazione invece di un piccolo ritocco al primo.
Un ping che funziona verso il gateway e un ping che fallisce verso l'host oltre non sono un problema intermittente. È il comportamento atteso di un'istanza a cui non è stato detto che può inoltrare.
Scrivete il percorso prima di toccare un'impostazione
Annotate il prefisso del client, l'istanza o l'interfaccia di rete di inoltro, la sottorete di destinazione e la rotta di ritorno. Una voce della tabella di routing della VPC che punta a un'istanza non configura il sistema operativo dell'istanza per inoltrare, e un kernel ospite con l'inoltro abilitato non crea una rotta della VPC. Entrambe le estremità di quella relazione devono esistere, e vengono modificate in luoghi diversi da persone con accessi diversi.
Poi esaminate l'impostazione del controllo origine/destinazione sul componente di inoltro effettivo, non su ogni istanza della VPC. AWS documenta perché un'istanza che inoltra traffico per altri deve avere quel controllo disabilitato, e anche perché l'impostazione è una decisione per istanza e non un valore predefinito dell'intera VPC.
Quattro confini, e il controllo è solo uno di essi
Trattate il percorso come quattro domande e rispondete in ordine. La prima risposta che fallisce è dove sta il lavoro, e nessuna delle altre la compenserà.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
L'ordine conta perché verificare costa poco: le rotte si vedono in una pagina, il controllo è un solo attributo, e l'opinione della destinazione è di solito l'ultima cosa che qualcuno chiede.
La traduzione cambia quale origine vede la destinazione
Un progetto instradato conserva l'indirizzo di origine del client, quindi la destinazione necessita di una rotta di ritorno verso il prefisso del client. Un progetto tradotto presenta invece l'indirizzo del gateway, il che elimina quel requisito e lo sostituisce con una tabella di stati sul gateway. Decidete secondo l'architettura che intendete, invece di aggiungere la traduzione perché un esempio non correlato l'ha usata e sembrava funzionare.
Se traducete, limitate la regola al prefisso del client e alla destinazione prevista. Se conservate, confermate che l'altro lato conosca davvero la rotta invece di supporre che ne apprenderà una.
Provate dal client originale, poi conservate la modifica
Una richiesta generata sul gateway può riuscire mentre una richiesta inoltrata fallisce, perché è un'origine diversa e un caso di inoltro diverso. Dopo una correzione mirata, ripetete l'esatto test client-verso-risorsa che è fallito, dallo stesso client, e confermate che la risposta torna e non solo che la richiesta è arrivata.
Infine, mettete l'impostazione nella configurazione gestita del gateway così che un'istanza sostitutiva la riceva. Un test riuscito che dipende da un'eccezione manuale è un test che scade alla prossima ricostruzione, e la persona che l'ha scoperto non sarà lì per ricordare perché.