Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Concepts des tables de politiques dans AWS Passerelle de transit
Cette rubrique décrit les concepts clés des tables de politique des passerelles de transit et du Policy-Based routage (PBR).
## Tableaux de politiques et règles de politique
Un tableau ** de règles ** contient un ensemble ordonné de règles. Chaque règle précise :
+ **Critères de correspondance ** : attributs de paquets utilisés pour classer le trafic (CIDR IP source, CIDR IP de destination, port source, port de destination et protocole).
+ **Table de routage cible ** : table de routage de la passerelle de transit utilisée pour transférer le trafic qui correspond aux critères de la règle.
Lorsque le trafic arrive sur une pièce jointe associée à une table de règles, la passerelle de transit évalue chaque règle dans l'ordre et applique la table de routage cible de la première règle correspondante. Si aucune règle ne correspond, le paquet est abandonné (refus implicite).
Une pièce jointe de passerelle de transit peut être associée à une table ** de règles ** ou à une table de ** routage**, mais pas aux deux. Par défaut, toutes les pièces jointes sont associées à la table de routage par défaut.
## Ordre d’évaluation des règles
Les règles d'un tableau de règles sont évaluées par ordre numérique ** croissant**, en commençant par la règle numéro 1. La première règle correspondant au trafic entrant est appliquée. Aucune règle ultérieure n'est évaluée après un match. Comme l'évaluation s'arrête au premier match, l'ordre des règles est important :
+ Définissez des règles plus spécifiques (plages IP étroites, ports spécifiques) à des numéros de règles inférieurs.
+ Placez des règles plus larges ou fourre-tout à des numéros de règles plus élevés.
Nous vous recommandons de laisser des espaces entre les numéros de règles (par exemple, 100, 110, 120) plutôt que d'utiliser des valeurs consécutives, afin de pouvoir insérer des règles ultérieurement sans les renuméroter.
## Entrées du tableau des politiques du système et de la clientèle
Les tableaux de règles prennent en charge deux types d'entrées : gérées par le ** client ** et ** gérées par le système. ** Il est important de comprendre les deux types pour prévoir comment votre trafic est évalué et acheminé.
**Customer-managed entrées**
Customer-managed les entrées sont des règles que vous définissez pour acheminer le trafic en fonction des attributs des paquets. Vous créez ces entrées à l'aide de l'`CreateTransitGatewayPolicyTableEntry`API ou de la console AWS de gestion.
Chaque entrée gérée par le client spécifie :
+ **Numéro de règle ** : détermine l'ordre d'évaluation. Les règles sont évaluées par ordre croissant. La règle de correspondance portant le plus petit numéro est appliquée.
+ **Conditions de correspondance ** : combinaison du CIDR source, du CIDR de destination, du protocole, du port source et du port de destination. Tous les champs sont facultatifs. Les champs omis sont définis par défaut sur Any (`*`).
+ **Table de routage cible ** : table de routage de la passerelle de transit vers laquelle le trafic correspondant est transféré.
Si aucune règle gérée par le client ne correspond et qu'aucune règle gérée par le système ne correspond, le trafic est interrompu (refus implicite).
**Exemple ** : vous avez deux VPC connectés à une passerelle de transit : un VPC de production et un VPC de développement. Vous souhaitez acheminer le trafic HTTP destiné `10.0.0.0/16` via une table de routage d'inspection de sécurité, tandis que tout autre trafic utilise une table de routage par défaut.
**Exemples d'entrées gérées par le client**
| Numéro de règle | Source : CIDR | CIDR de destination | Protocole | Port source | Port de l'est | Tableau des itinéraires cibles |
| --- | --- | --- | --- | --- | --- | --- |
| 10 | 0.0.0.0/0 | 10.0.0.0/16 | TCP | 1024-65535 | 80 | tgw-rtb-inspection |
| 20 | 0.0.0.0/0 | 0.0.0.0/0 | Tous | Tous | Tous | tgw-rtb-default |
Dans cette configuration, le trafic HTTP doit `10.0.0.0/16` correspondre à la règle 10 et est acheminé via la table de routage d'inspection. Tous les autres trafics respectent la règle 20 et utilisent la table de routage par défaut.
**System-managed entrées**
System-managed les entrées sont créées et gérées automatiquement AWS pour prendre en charge les fonctions de routage AWS internes, telles que le routage dynamique AWS Cloud WAN et l'isolation des segments de réseau. Vous ne pouvez pas créer, modifier ou supprimer des entrées gérées par le système. System-managed les entrées apparaissent dans votre tableau de règles lorsque vous utilisez des fonctionnalités telles que le AWS Cloud WAN qui nécessitent une isolation du trafic au niveau du segment sur les pièces jointes d'appairage de transit Gateway-to-Cloud WAN.
Comment les entrées gérées par le système affectent votre trafic :
+ **Priorité ** : les entrées gérées par le système sont toujours évaluées avant les entrées gérées par le client. Si une entrée gérée par le système correspond au trafic entrant, elle est appliquée quelles que soient les règles gérées par le client que vous avez configurées.
+ **Visibilité ** : les entrées gérées par le système sont visibles dans la réponse de l'`GetTransitGatewayPolicyTableEntries`API et dans la console, où leur numéro de règle s'affiche sous la forme. `*`
+ **Aucune action n'est requise ** : ces entrées sont entièrement gérées par vous AWS et ne nécessitent aucune configuration de votre part.
**Exemple ** : vous utilisez AWS Cloud WAN avec deux segments de routage, la production et le développement. AWS crée automatiquement des entrées gérées par le système dans le tableau des politiques associé à votre pièce jointe d'appairage WAN Transit Gateway-to-Cloud afin de garantir que le trafic reste dans le segment qui lui est attribué. Si vous ajoutez également des règles gérées par le client à la même table de règles, les règles de segmentation gérées par le système prennent effet en premier. Vos règles gérées par le client s'appliquent uniquement au trafic qui ne correspond pas à une entrée gérée par le système.
**Comparaison des types d'entrées**
| Créé par | Numéro de règle | Évalué | Peut être modifié |
| --- | --- | --- | --- |
| AWS (par exemple, pièces jointes d'appairage WAN entre passerelle et cloud) | \* | Tout d'abord, avant toutes les saisies de clients | Non |
| Vous | 1 à 50 000 | Après les entrées du système, dans l'ordre croissant des numéros de règles | Oui |
Les deux types d'entrées sont renvoyés ensemble `GetTransitGatewayPolicyTableEntries` et affichés ensemble dans la console AWS de gestion.
## Comment fonctionne l'évaluation des tables de politiques
Lorsque le trafic entre dans une pièce jointe de passerelle de transit associée à une table de règles, l'évaluation se déroule comme suit :
1. System-managed les candidatures sont évaluées en premier. Si une entrée gérée par le système correspond au trafic, elle est appliquée et l'évaluation s'arrête.
1. Customer-managed les entrées sont évaluées ensuite, dans l'ordre croissant des numéros de règles. La première règle de correspondance est appliquée et l'évaluation s'arrête.
1. Refus implicite : si aucune entrée ne correspond, le trafic est interrompu.
## Bonnes pratiques
+ **Laissez des espaces entre les numéros de règles. ** Utilisez des incréments de 10 ou 100 (par exemple, 10, 20, 30 ou 100, 200, 300) afin de pouvoir insérer de nouvelles règles ultérieurement sans renuméroter les entrées existantes.
+ **Priorisez les règles les plus spécifiques. ** Placez des conditions de match plus restreintes à des numéros de règles inférieurs afin qu'elles soient évaluées avant des règles fourre-tout plus larges. Une règle générale à un chiffre faible fera oublier des règles plus spécifiques à un chiffre plus élevé.
+ **Incluez toujours une règle fourre-tout. ** Comme le trafic est supprimé si aucune règle ne correspond, ajoutez une règle par défaut à un numéro de règle élevé si vous souhaitez que le trafic inégalé atteigne une table de routage au lieu d'être supprimé silencieusement.
+ **Configurez le protocole avant les plages de ports. ** La sélection du protocole détermine si les champs de plage de ports sont actifs. Les plages de ports ne sont prises en charge que pour TCP (`6`) et UDP (`17`). Pour ICMPv4 (`1`), GRE (`47`) ou Any (`*`), les plages de ports sont automatiquement définies sur Any (`*`).
+ **Tenez compte des entrées gérées par le système. ** Si votre tableau de règles inclut des entrées gérées par le système (par exemple, depuis AWS Cloud WAN), vos règles gérées par le client s'appliquent uniquement au trafic qui ne correspond pas à une entrée gérée par le système. Passez en revue toutes les entrées `GetTransitGatewayPolicyTableEntries` pour confirmer l'ordre d'évaluation que vous attendez.
+ **Vérifiez votre configuration à l'aide de l'API. ** Après avoir apporté des modifications, utilisez cette `GetTransitGatewayPolicyTableEntries` option pour afficher toutes les entrées des deux types d'entrées et confirmer que les numéros de règles et les conditions de correspondance sont corrects avant d'acheminer le trafic en direct.