Annunci BGP del VGW rispetto alla tabella di routing della VPC: cosa cambia cosa

Un prefisso mancante nella tabella di routing di una sottorete della VPC e un prefisso mancante sul router del cliente sono due guasti diversi, e solo uno dei due si ripara all'interno delle tabelle di routing di AWS. Il gateway privato virtuale annuncia i blocchi CIDR associati alla sua VPC; la tabella di routing della sottorete decide dove un carico di lavoro invia la risposta. Trattare il secondo come un modo per cambiare il primo è la svolta sbagliata più comune in questa diagnosi. Eseguire i controlli seguenti in ordine e tenere separate le due direzioni.

Nomina l'associazione prima di leggere qualsiasi tabella

Una VPN site-to-site termina su un gateway privato virtuale o su un gateway di transito, e gli ID delle risorse decidono quale modello di routing si applica. Leggili per primi: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. La risposta ti dice se la prossima tabella da ispezionare è una tabella di routing della VPC o una tabella di routing del gateway di transito.

Se la VPN è collegata a un gateway di transito, smetti di trattare la tabella di routing della VPC come piano di controllo. Lì la tabella della VPC punta all'associazione del gateway, e associazione e propagazione avvengono nella tabella di routing del gateway di transito. Mescolare le due viste produce conclusioni sicure sull'oggetto sbagliato.

La direzione da AWS all'ufficio è un annuncio

Per un'associazione VGW, il gateway annuncia i blocchi CIDR associati alla sua VPC al gateway del cliente tramite BGP. Aggiungere una singola rotta di sottorete, o indirizzare una rotta verso una VPC in peering o verso un'appliance, non aggiunge un altro CIDR associato e non compare in quell'annuncio. Se all'ufficio manca un prefisso, confronta l'elenco delle rotte ricevute con le associazioni della VPC prima di modificare qualsiasi tabella di routing.

La regola semplice ha eccezioni, quindi tienila nel suo ambito. Una configurazione VPN CloudHub può riannunciare i prefissi dei siti tra i gateway dei clienti, e un gateway di transito segue le proprie regole di propagazione. L'affermazione che un VGW annuncia solo la propria VPC è un valore predefinito utile, non una legge che copre ogni topologia che incontrerai.

La direzione dall'ufficio ad AWS è propagazione più selezione

Nella direzione inversa il VGW apprende il prefisso dell'ufficio, ma questo da solo non sposta un carico di lavoro. La tabella di routing della sottorete deve avere la propagazione abilitata per l'associazione oppure portare una rotta statica verso la stessa destinazione. Quando entrambe esistono per un prefisso, vince la rotta statica, e la corrispondenza del prefisso più lungo viene eseguita prima di entrambe.

Leggi l'origine invece di presumerla: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Una voce con origine EnableVgwRoutePropagation è arrivata da BGP; una voce con origine CreateRoute è stata digitata da una persona e continuerà a vincere finché qualcuno non la elimina.

Un runbook che tiene separate le due direzioni

Annota quattro fatti sul lato AWS prima di cambiare qualsiasi cosa: il tipo di associazione, i CIDR associati della VPC, l'origine della rotta di sottorete per il prefisso in questione, e lo stato del tunnel e di BGP. La stessa chiamata describe restituisce VgwTelemetry con un conteggio delle rotte accettate per tunnel, che ti dice se AWS ha accettato delle rotte. Poi confronta con ciò che il dispositivo del cliente ha effettivamente installato. Un prefisso presente in BGP ma assente dalla tabella di inoltro è un problema di importazione locale o di percorso migliore, non un problema della tabella di routing di AWS.

Se alla tabella della sottorete manca del tutto il prefisso, abilita la propagazione o aggiungi una rotta statica, poi rileggi la stessa query dopo l'intervallo di propagazione invece di presumere che la modifica sia stata immediata. Se il prefisso esiste e il traffico continua a fallire, lascia in pace il piano di controllo e passa al percorso dei dati.

Cosa non cambiare mentre sei lì

Non attivare o disattivare la propagazione su tabelle di routing non correlate per correggere un prefisso mancante, e non aggiungere una rotta predefinita per coprire un singolo CIDR assente. Entrambe le modifiche ampliano l'ambito dell'impatto e rendono più difficile la diagnosi successiva. Limita la modifica alla tabella che serve la sottorete del carico di lavoro in questione.

Il percorso dei dati è separato da tutto questo. I gruppi di sicurezza sono stateful, le ACL di rete no, e un firewall dell'host o un percorso di ritorno asimmetrico possono scartare traffico che il routing ha consegnato correttamente. Un aggregato annunciato non autorizza nemmeno ogni servizio al suo interno, quindi limita l'accesso al confine della policy invece di affidarti alla comparsa casuale di un indirizzo in un annuncio BGP.

Salva il prima e il dopo di ogni query sulla tabella di routing nel registro delle modifiche. Se la modifica peggiora le cose, ripristina le rotte precedenti e conferma con la stessa query, perché un rollback che non puoi verificare è solo una supposizione.